Core Team Meetup Recap: Multisite

These are the notes from a breakout discussion on multisite at the core meetup with me, @markjaquith, and @nacin. As with all of these discussion summaries, please remember that they’re just discussions. I’m posting the notes for transparency purposes, not to say that these are the only things discussed or decided. I’m working from notes, and sometimes you don’t get everything down when you’re taking notes (next year I’ll record these things instead).

Multisite!

Who can lead this joint? Since the merge and Donncha moving on to other things, we had Ron for a cycle, Pete for a cycle, then no one. It would be good to have someone act as component owner.

Multisite needs parity with the single site experience. Includes UI, UX, copy/strings, install flexibility (subdomain etc), installation ease (add a site).

First we need to improve the manage/use experience, then fix install stuff and get it into the dashboard to turn on multisite.

We need a useful global dashboard.

We need to have flexibility in where sites and networks live — should be able to live wherever you want on one network. Subdomains/subdirectories/mapping/whatever you want, mixed subdomain/subdirectory, custom domains, global permalink consumer/router.

Need to fix different workflows: adding users to network, adding users to site, invitations. User signup, creation, assignment, invitation all need new flow

We need parity between plugins and themes. Enable vs activation is confusing, need to improve language, indicators. Need ability to network enable but disable for individual sites. Need to standardize network enable/activate etc for plugins/themes. Network activated plugins don’t show in individual site’s plugin list, which is confusing.

UX Action Items:

UX ACTION ITEM — Include network activated plugins in the plugins menu and give message that it is automatically on for the whole network (if admin/have rights to see plugins screen).

UX ACTION ITEM — Autocomplete usernames or site names for network admin and for superadmin everywhere.

UX ACTION ITEM — Get multisite tag/indicator on plugins in directory, add multisite specific/required indicator.

Under the Hood Action Items:

ACTION ITEM — Get rid of MS-FILES.

ACTION ITEM — Enable install in subdirectory so you can use externals.

Use wp_enqueue_scripts, not wp_print_styles, to enqueue scripts and styles for the frontend

If you are enqueueing scripts and styles, you will want to use one of these three hooks:

1. wp_enqueue_scripts (for the frontend)
2. login_enqueue_scripts (for the login screen)
3. admin_enqueue_scripts (for the admin dashboard)

Don’t let the names fool you — they are for both scripts and styles. We’ll probably add equivalent *_enqueue_styles hooks in 3.4 just to make it more obvious, but these hooks have all existed for some time now.

A possible incompatibility with WordPress 3.3 could arise if you are using the wp_print_styles hook to enqueue styles — your styles may end up in the admin.

The fix: Use wp_enqueue_scripts instead. Yes, it’s that easy.

Edit: Yes, the same goes for registering styles. Registering or enqueueing (styles or scripts) should occur on *_enqueue_scripts.

(Background: #19510)

Help and screen API changes in 3.3

WordPress 3.3 introduces a new API for working with administration screen help content. add_contextual_help( $screen, $content ) is deprecated.

There are now tabs inside the help tab:

The way to add these are to attach a function to an existing hook such as the load-{$pagenow} hook, then using the add_help_tab() method of the current screen object.

For example:

add_action( 'admin_menu', 'nacin_add_special_theme_page' );
function nacin_add_special_theme_page() {
    $theme_page = add_theme_page( ... );
    if ( $theme_page )
        add_action( 'load-' . $theme_page, 'nacin_add_help_tabs_to_theme_page' );
}
function nacin_add_help_tabs_to_theme_page() {
    $screen = get_current_screen();
    $screen->add_help_tab( array(
        'id'      => 'additional-plugin-help', // This should be unique for the screen.
        'title'   => 'Special Instructions',
        'content' => '<p>This is the content for the tab.</p>',
        // Use 'callback' instead of 'content' for a function callback that renders the tab content.
    ) );
}

If you want to add a tab to an existing core screen, you’ll probably want to use the admin_head-{$pagenow} instead (to add them to the bottom), since core help tabs are not added until after load-{$pagenow}.

Help Sidebars

You can set the content of the right sidebar using $screen->set_help_sidebar( $content ) on the same hook where you used $screen->add_help_tab().

Removing Help Tabs

You can use $screen->remove_help_tab( $id ). Additionally, $screen->remove_help_tabs() will remove all tabs for a page.

Using the new WP_Screen object to adapt to screen contexts

The get_current_screen() function returns an object that includes the screen’s ID, base, post type, and taxonomy, among other data points. While get_current_screen() (and $current_screen, though the use of the global isn’t necessary) existed since 3.0, it now contains more accurate screen context (and the methods we covered above).

You can use $screen->id, $screen->base, etc., to ascertain which page you are on. This is helpful as seen above, to make sure that the help tab is only added to edit-tags.php if the taxonomy is post_tag. Of course, this is also helpful on the admin_enqueue_scripts hook (to figure out which scripts or styles to enqueue on a page) as it provides more context than a simple $pagenow or $hook_suffix.

More about what IDs and bases look like:

• For edit.php (list for posts, pages, and post types), the ID is ‘edit-{$post_type}’ and the base is ‘edit’. The $post_type value is additionally set.
• For post.php and post-new.php, the ID is {$post_type} and the base is ‘post’. For post-new.php, $screen->action is ‘add’.
• For edit-tags.php, the ID is ‘edit-{$taxonomy}’ and the base is ‘edit-tags’. The $taxonomy and $post_type values are additionally set.
• For all other core pages, the ID and base are generally the same and equivalent to the $pagenow value (minus ‘.php’).
• For plugin pages, the ID is the value returned by add_menu_page(), add_submenu_page(), or the like, or get_plugin_page_hookname().

Note on add_contextual_help() and the contextual_help and contextual_help_list filters

The function and these filters continue to work, but their use is deprecated, and they are not ideal for use. They only work on a single chunk of text, rather than multiple tabs. So if the function is called or if the filters return any data, a separate ‘Overview’ tab will be added for compatibility sake.

15 10 6 tickets between us and launch. Still need a beta 4 and an RC. The tickets:

Needs Dev / Bug Wrangler Feedback

• #19338 Welcome Panel and no JS don’t mix well — Not sure how we missed putting in a no-js version, but we did. Need one. @dkoopersmith was owner of feature, @azaozz has done lots of the no-js stuff in wp, and @joncave made the ticket and wrote a patch. Huddle and work it out. (@jane)
• #17975 _default_wp_die_handler css referencing logic is fragile and doesn’t always work (@jane)

Has Patch / Needs Testing

• #19020 Content Updates for Help Tabs — Tedious. Will finish before before string freeze at RC. Mostly same strings, just moved around a bit. @chexee, @jane and whoever wants to help with some copy paste drudgery patching. (@jane)
• #19191 Improve admin menu tab navigation — Gotta be keyboard accessible! @dkoopersmith or @azaozz need to check out patch by John Kleinschmidt on ticket. (@jane)
• #19127 Welcome Panel should be displayed for the first administrator — Panel itself is done, but needs code underneath. @nacin is on this today. (@jane)
• #19326 jQuery 1.7.1 — They just released this update. There were some issues with 1.7. (@jane)
• #19292 Not found errors due to sanitization in sanitize_title_with_dashes — Mark’s patch being reviewed. (@jane)
• #19125 CPT as a submenu item does not get the correct classes when adding new (@jane)
• #18693 New feature pointers — These are in, but in some browsers aren’t positioning correctly (fixed, [19416]). Also need a little RTL love, see #19335. (@jane) (@nacin)

Patch Needs Refresh

• #18880 Back compat for the admin_user_info_links filter (@jane)

Needs Patch

• #19088 Accessibility for the admin bar — Screen readers, tabbing, etc. (@jane)
• #18742 New post-update screen — screen itself is done (translators, might want to get a head start, lots of new strings), but needs code to tell when to show it/to whom. Maybe some RTL love also. @nacin doing the when-to-show code. (@jane)
• #19320 wp_tiny_mce() cannot call wp_editor(), and other issues — @nacin and @azaozz duking it out on the ticket. (@jane)
• #19335 Make feature pointers nice for our RTL users (@jane)
• #18467 Standardize Language on Core Update — @nacin working on it. (@jane)

Activity since beta 1:

• The blue theme is looking much better thanks to @ocean90.
• @azaozz fixed IE7 and RTL support.
• Flyout menu styling is more spiffy and less glitchy.
• Pointers are pretty much done thanks to @dkoopersmith.
• WP_Screen and contextual help improvements from @nacin.
• Various bug and styling fixes from everyone.
• The “blog front menu” in the admin bar returned to a small snack menu from the full menu we trialed in beta 1.
• Bug scrubs started up again today to finish cleaning up the 3.3 milestone.
• Almost 50 commits since beta 1.

We’re getting 3.3 ready for beta. Here’s the gist of how things stand:

• We’re doing daily (almost) bug scrubs in #wordpress-dev to drive down the ticket count.
• Nacin is finishing up WP_Screen and the media button merge.
• Koopersmith is finishing up tabbed help and flyout menu styling.
• Pointers need some styling fixes to be called done enough for 3.3. Pointers will probably be for core only use in 3.3.
• Admin bar needs final walk through and tweaks.
• Welcome box and about this version page need final feedback and tweaks.
• Some of the responsive admin work will be pushed to 3.4 so we have more time to get large screens looking the way we want. Ozz and Jaquith are on it.
• Jane will check all UI/UX feedback tickets and leave comments.
• All task (blessed) tickets should be updated with a comment on current status by the end of the day.
• I will stroke my beard in a diabolical manner while everyone else works.
• Okay, besides that I will be scrubbing bugs, working on more unit tests, and getting coffee for the JS guys.

I’ve ported over all of the core Trac modifications to the BuddyPress and bbPress Tracs. In the process, core Trac has been given a fresh coat of paint, and the old Trac logo has been retired.

Also in the process, I’ve fixed a few bugs:

• Bad link to the Security FAQ, #17479
• Ticket fields are too wide in Firefox, #16582
• Keywords cannot be removed on some browsers (well, Android) thanks to missing href attribute

Thanks JJJ, MT, and Barry for their assistance.

A glossary for contributors

As part of the core contributor handbook, there’s going to be a glossary. Here’s what I’ve put together so far.

Something missing? Leave a comment. Feel free to also weigh in on new and existing definitions, examples, and the like.

a11y: Accessibility, or the act of ensuring that user interfaces are accessible for persons of all abilities and disabilities.

back compat: Backwards compatibility — a desire to ensure that plugins and themes do not break under new releases — is a driving philosophy of WordPress. While it is a commonly accepted software development practice to break compatibility in major releases, WordPress strives to avoid this at all costs. Any backwards incompatible change is carefully considered by the entire core development team and announced, with affected plugins often contacted. It should be noted that external libraries such as jQuery do have backwards incompatible changes between major releases, which is often going to be a greater concern for developers.

backport: A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch.

A few weeks ago a change was deployed to the plugins directory. If you click “Other Versions” on the sidebar when viewing a plugin, there’s a new section called “Browse the Code” with three links to:

• the development log on Plugins Trac
• the plugin’s directory in Subversion
• the stable tag in Subversion (or trunk)

Hopefully this makes it easier to find the right URL for plugin checkouts, and to browse the code.

Check it out here.

Because so many people are traveling to SXSW today, it was decided in IRC yesterday to skip this week’s dev chat. We’ll start the post-mortem on 3.1 here on the blog and pick up again next week.