Release Candidate for 3.9.1

I’ve packaged up WordPress 3.9 RC1 and intend to ship it Wednesday morning. For a complete list of the 33 issues, please see this report. Some highlights:

  • Widgets: Theme preview empties sidebar on active theme. #27897.
  • Multisite: Fixes regressions with uppercase characters in network paths; and with www as a subdomain. #27866, #27927.
  • Header images: Fix weird behavior (or hiding) of various buttons: #28046, #27848, #27936.
  • Performance: Fix potentially slow query on the new/edit post page. #27985.
  • Various playlist, media, and editor fixes, including drag-and-drop text (#27880) and positioning of images when adding a caption (#27922).
  • Some minor internationalization and RTL issues, like #27924 #27893 #27845.

Note this does not address a number of other issues, which are slated for a 3.9.2 release. Notably, many of these will require updates to TinyMCE, or require additional study or testing.

Download it here (zip) or grab the latest nightly (here or using the WordPress Beta Tester plugin). Testing strongly encouraged; feedback welcome.

#3-9, #3-9-1

Last Week in WordPress Core

Hello there! This is Last Week in WordPress Core for the week of April 15-April 23. Happy release week, everyone! WordPress 3.9 “Smith” was released last Wednesday! Due to that, fewer commits this week. With a 3.9.1 maintenance release expected this week, changes up to tonight are included below.


  • Ensure widgets stay with themes during a theme switch. See [28124]. [28161] #27897
  • Run WP_Editors::enqueue_scripts() on admin_print_footer_scripts priority 1 (later), instead of admin_footer. Fixes incompatibility with the customizer. [28187] #27853
  • Remove create_function() from the customizer class to improve HHVM compatibility. [28143] #27805

Theme Installer

  • Restore .zip theme installation by casting wp_count_attachments() before iterating it to avoid a notice when items exist without a mime type. [28139] #27802
  • Prevent customizer header image list from listing user images twice when no theme-specified images exist. [28152] #27839
  • Improved URL routing. [28141] [28147] #27055
  • Proper redirection and action links post-install in multisite. [28163] #27869


  • Update the TinyMCE tests to [28138] #27744
  • Fix icons in IE7. [28142] #27829
  • Restore wordpress_adv_hidden editor parameter to enable force-showing the kitchen sink. [28181] #27963
  • Shrink the font size for the selected item in “Format” dropdown so that it fits in more locales. [28180] #27903
  • Fix the active state of the Link button when an image wrapped in a link is selected. [28185] #27847
  • Don’t trigger the drag-and-drop uploader when selected test is being dragged from one window to another. [28189] #27880
  • Correct positioning when adding a caption to an image that is in a paragraph with other text. [28190] #27922
  • Update the “paste” plugin to the latest development version to fix: [28192] #27909 #27771
    • Correct pasting of Excel tables.
    • Leave TOC Anchors intact during paste.


  • Improve styling and fix RTL for playlists. [28172] [28174] #27923; [28173] #27924
  • Alter the layout of the checkboxes in the modal view for Audio/Video Details to allow translations more room to breathe. [28184] #27893
  • Graceful failures for TinyMCE views of video/audio playlists. [28144] #27821
  • Add a compatibility layer in wp-playlist.js to avoid VM errors from MediaElement’s plugin bridge in the TinyMCE views to whitelist file types for native playback. [28171] #27892
  • Refinements for asynchronous rendering in [28182] #27899
  • Keep <tracks> from being filtered out when switching between visual and text editors. [28183] #27915
  • Hide extra tracks field in media modal when adding subtitles. [28169] #27915


  • Avoid a PHP warning during theme background-update checks when there are multiple theme directories registered. [28137] #27815
  • Properly gray out text fields when they are disabled or when they have the disabled class. [28179] #27906
  • Avoid counting all attachments when entering the post|page edit screens. [28191] #27985

Thanks to @avryl, @azaozz, @bobbingwide, @celloexpressions, @dimadin, @feedmeastraycat, @gcorne, @helen, @jjeaton, @johnbillion, @kworthington, @lancewillett, @mcsf, @melchoyce, @nacin, @netweb, @ocean90, @SergeyBiryukov, @smashcut, @westonruter and @wonderboymusic for their help this week!

For the complete list of commits to trunk, check out the log on Trac. We started talking about 4.0 plans this week in the weekly dev meeting. Come chat next Wednesday to continue the discussion, and note if you encounter issues with the new release on trac.

#3-9, #week-in-core

Let’s have a meeting in #wordpress dev on…

Let’s have a meeting in #wordpress-dev on April 21, 2014 18:00 UTC, to discuss WordPress 3.9.1 and triage those tickets. As preparation for the meeting:

Reception has been overwhelmingly positive and, anecdotally at least, we’ve seen more issues as they relate to deliberately changed aspects (TinyMCE/editing) versus generic plugin breakage. I think we’re in pretty good shape based on the bug reports that have come in, but with automatic updates at our disposal, there’s no reason to wait three or four weeks before shipping 3.9.1.

I think we should try to fix the big, obvious stuff by Tuesday and release 3.9.1 as early as Wednesday. Some of the reported issues are pretty core to TinyMCE 4.0 and the various rewrites it triggered (like image editing), which means many of them won’t be handled by 3.9.1. That’s quite OK, especially since some of these may require some upstream fixes in TinyMCE, and since there can always be a 3.9.2 in the weeks ahead.

What I do want to do is have no “unknowns” — we should know exactly what regressed or otherwise is broken, under what circumstances, how major or minor it is, how high or low of a priority it should be, etc. That includes unit tests (if applicable) or at least clear test cases.

cc @azaozz @helen @wonderboymusic @gcorne @avryl @mcsf @ehg @jeremyfelt @ocean90 @westonruter

#3-9, #3-9-1, #agenda

Live Widget Previews: Widget Management in the Customizer in WordPress 3.9

The WordPress 3.9 release includes widget management in the Customizer: previewing changes to widget areas before publishing them live for the world to see. This feature was birthed out of the Widget Customizer plugin which started development in the 3.8 release cycle, it was formally proposed for merging into core at the start of the 3.9 release cycle, and then it was merged and followed by many changes. I wanted to follow-up here to talk through the changes to Widget Customizer since it was initially proposed (read this post for a full overview of the feature). Here is what has changed since then:

No more opt-in for theme support

The Widget Customizer plugin implemented a mechanism for doing fast live widget previews. By default, all changes made to settings in the customizer cause the preview window to do a full page refresh. This causes a lag between when you make a change and when the change appears. The customizer also supports an alternate non-refresh mechanism for previewing changes in the customizer (the postMessage transport) which you often see themes implement for live-previewing the blog name or the header color.

Implementing such immediate live-previews requires all of the logic for previewing the change to be implemented in JavaScript, in addition to the underlying PHP logic for rendering the change when the setting is saved. This is not possible for widgets, since they all use PHP to handle the sanitization of the form inputs and for rendering arbitrary content that a widget may contain. (You’ll notice that when you make a change to a widget in the customizer, it actually does an Ajax request to submit the widget form for sanitization every time.) Well, to get around having the customizer preview refresh for every widget change, we implemented an Ajax renderer for the widgets, and then used the postMessage transport to initiate this widget render request, and then the rendered widget response would get swapped out in the DOM.

Long story short, we decided to remove this feature to use postMessage for faster live previews. We have created #27355 to re-add this feature, but to generalize it so that any customizer control can take advantage of doing these partial preview refreshes. So for now, you’ll have to wait a moment for the preview to refresh when you make a change to a widget area, but now you don’t change your themes or widgets to add explicit support for Widget Customizer.

No more Update button (usually)

Widget forms on the admin page have a familiar Save button. In previous versions of Widget Customizer, we adapted the Save button to be an Update button, since it wouldn’t actually save the widget but would just update the preview with the widget’s latest state. Having to click this Update button to see the preview update, however, was a poor user experience and was unnecessary. Therefore, we implemented a means of submitting the form to update the widget’s state in the preview whenever a field in the control is updated: the Update button was hidden and the spinner appears when a change is being synced to the preview.

The logic which does this live submission of the widget form as you interact with it, depends on the fields in the widget form to be the same fields which get returned when the widget form is sanitized. This is so that the fields can be aligned for being updated with their sanitized values. We couldn’t go the route of the widget forms on the widgets admin page, which actually get fully replaced with the newly-sanitized form, because this would interfere with the user quickly inputting into these fields.

So if a widget form dynamically adds or changes which input fields are included, the live-as-you-type-them updates will stop and the Update button will re-appear. When you click this button, the form will replace itself with the sanitized version just like on the widgets admin page. We also introduced new jQuery events to help handle these form changes…

New widget-added and widget-updated jQuery events

In the widgets admin page, when you add a new widget to a widget area, a widget template element gets cloned and then inserted into the selected widget area. This widget template is cloned in a way that any event handlers initially added to the widget template do not persist on any newly-added widgets. Any widgets previously-added to the widget areas would have these event handlers attached, as well as any dynamically-created fields (e.g. jQuery Chosen), but again, newly-added widgets fail to retain these. The same problem exists, however, whenever you update a widget: since the newly-sanitized widget form replaces the old one, any dynamic elements get lost. (This is why event delegation is often required.)

The same challenges here for the widgets admin page are also challenges for widgets in the customizer. And so in #19675 and #27491, we’ve introduced widget-added and widget-updated jQuery events which pass along the widget container as the second argument for the event handler. So to initialize and re-initialize a widget’s dynamic UI, you can now use these events in something like this:

jQuery( function ( $ ) {

	function init( widget_el, is_cloned ) {

		// Clean up from the clone which lost all events and data
		if ( is_cloned ) {
			widget_el.find( '.chosen-container' ).remove();

		widget_el.find( 'select.dynamic-field-chosen-select' ).chosen( { width: '100%' } );

	 * @param {jQuery.Event} e
	 * @param {jQuery} widget_el
	function on_form_update( e, widget_el ) {
		if ( 'dynamic_fields_test' === widget_el.find( 'input[name=&quot;id_base&quot;]' ).val() ) {
			init( widget_el, 'widget-added' === e.type );

	$( document ).on( 'widget-updated', on_form_update );
	$( document ).on( 'widget-added', on_form_update );

	$( '.widget:has(.dynamic-field-chosen-select)' ).each( function () {
		init( $( this ) );
	} );

} );

This is admittedly still not ideal, but it is much better than hacking the jQuery Ajax events to detect when a form update happens. In the future, I’m keen to see the widgets be revamped to use Backbone extensively.

Configuring widgets during a theme switch

We had a surprise late in the release (#27767) when it was reported that when you activate a new theme via the customizer, any changes made to the widget areas get lost when the theme is activated. This issue has been fixed, so now you can preview a theme and fully configure all of the widget areas before going live.

Beware of widgets and caching

We had another challenge in #27538 where widget changes previewed in the customizer would leak outside the preview and on the live site if the widget cached the output for performance. The core widgets Recent Posts and Recent Comments both cache their outputs in the object cache, and if a persistent object cache plugin is enabled (e.g. Memcached or APC) then the cache would get poisoned with the previewed widget, even though the widget’s changes weren’t saved. The same behavior would be experienced for widgets that use transients to cache the rendered output.

To help widgets do the right thing in regards to caching, we introduced a WP_Widget::is_preview() method which widgets should always check before they interact with the cache. For example, a widget’s widget()method which caches its output should do something like this:

if ( ! $this->is_preview() ) {
    $cached = wp_cache_get( 'foo-widget' );
    if ( ! empty( $cached ) ) {
        echo $cached;

extract( $args );
echo $before_widget;
// ...
echo $after_widget;

if ( ! $this->is_preview() ) {
    $cached = ob_get_flush();
    wp_cache_set( 'foo-widget', $cached );

Look forward to more improvements to widgets and the customizer in future releases!

#3-9, #appearance, #dev-notes, #widgets

Dashicons in WordPress 3.9

WordPress 3.8 has introduced an icon font for the WordPress admin, named Dashicons. Dashicons includes 167 icons until now.
WordPress 3.9 includes 30 new fresh and clean icons. Thanks to all contributors to ticket #26936, especially @melchoyce and @empireoflight.

Media Icons

All media file type icons got a huge facelift, see #26936. There are also two new icons for the playlists feature.

Icon CSS Class Code
dashicons-media-archive f501
dashicons-media-audio f500
dashicons-media-code f499
dashicons-media-default f498
dashicons-media-document f497
dashicons-media-interactive f496
dashicons-media-spreadsheet f495
dashicons-media-text f491
dashicons-media-video f490
dashicons-playlist-audio f492
dashicons-playlist-video f493


With the update to TinyMCE 4.0 you can now use four new icons for editor related UI.

Icon CSS Class Code
dashicons-editor-contract f506
dashicons-editor-break f464
dashicons-editor-code f475
dashicons-editor-paragraph f476


Use dashicons-external for external uses or randomize a list with dashicons-randomize.

Icon CSS Class Code
dashicons-external f504
dashicons-randomize f503

WPorg specific: Jobs, Profiles, WordCamps

We all WordCamps.

Icon CSS Class Code
dashicons-universal-access f483
dashicons-universal-access-alt f507
dashicons-tickets f486
dashicons-nametag f484
dashicons-clipboard f481
dashicons-heart f487
dashicons-megaphone f488
dashicons-schedule f489


Have you already tried the live widget previews? You should. The following icons are created for this feature.

Icon CSS Class Code
dashicons-archive f478
dashicons-tagcloud f479
dashicons-text f480


The minus icon has an alternative icon, plus now too. Welcome.

Icon CSS Class Code
dashicons-plus-alt f502


End of .

Icon CSS Class Code
dashicons-microphone f482

To get a complete overview of all icons please visit

#3-9, #dashicons, #dev-notes, #ui

jQuery UI and wpdialogs in WordPress 3.9

WordPress 3.9 does not use the “wpdialogs” TinyMCE plugin as part of the TinyMCE 4.0 update ( #16284, #24067), which comes with a new dialog manager. (For more, see this post and their migration guide.) This was a jQuery UI wrapper we had introduced back in WP 3.1. If you were using this in your own scripts, please be sure you are setting “wpdialogs” as a script dependency.

If you were using jQuery UI for anything on the post screen, please be sure you are setting this as a script dependency.

In both cases you may need to enqueue the “wp-jquery-ui-dialog” stylesheet, if you are using the WP UI dialog design.

#3-9, #dev-notes, #editor, #external-libraries

Multisite Changes in 3.9

Much of the bootstrap code for Multisite in ms-settings.php has been refactored in #27003 with the intent to improve how we handle the detection of domains and paths for sites and networks in core. Several other smaller enhancements and bugs have been completed in this and in other tickets.

How networks and sites are found

In the most common multisite scenario, the network finding process is the same. The constants DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE in your wp-config.php define the network to be loaded by WordPress. In the large majority of installations there is only one network.

The default process for finding the requested site now goes through a new function, get_site_by_path(). See the new functions section below for more details.

If you use a sunrise file—likely through a domain mapping or multi-network plugin—and the $current_site and $current_blog globals are configured there through a custom network and site detection process, the finding portions of ms-settings.php will continue to be skipped entirely. Nothing changes.

In some (very) rare scenarios, multiple networks may be configured in WordPress without a sunrise file. It is here where both the site and network finding process has been altered to use new functions rather than the stream of bootstrap code.

Deprecated Functions

There are two deprecated functions that may appear in your sunrise or in plugins to watch out for. Both of these were intended for private use by core, but came in handy as helpers to hack around various bits and pieces of the load process.

wpmu_current_site() is deprecated. It was previously used to find the network and site information for a request. All functionality has been removed from this in favor of replacement functions. In its current form, it returns the $current_site global.

get_current_site_name() is deprecated. It was previously used to set the site_name property on a given $current_site object. In its current form, it returns the passed $current_site object. This will likely not break anything, but any code relying on retrieving a site name using this function should be modified to use get_current_site() instead.

New Functions

Three new functions have been added to ms-load.php in 3.9 development. All of these have the focus of making sites and networks easier to find. These are meant to be public replacements for the previously private and somewhat inaccessible logic that existed in the bootstrap.

wp_get_network() retrieves an object containing the network’s information from the database when passed a network ID.

get_site_by_path() retrieves a site object when passed a domain and path. Two new filters are available here.

get_network_by_path() retrieves a network object when passed a domain and path. Two new filters are available here as well.

New Filters

Inside the new site and network finding functions are a few filters that go a long way in providing for a less hacky sunrise.php file in the future. These can be used to shape the multisite bootstrap process without entirely replacing the logic.

site_by_path_segments_count fires in get_site_by_path() and sets the number of possible path segments a site may have when we’re searching for it.

pre_get_site_by_path fires in get_site_by_path() and allows you to short-circuit core’s default logic for finding a site.

network_by_path_segments_count fires in get_network_by_path() and sets the number of possible path segments a network may have when we’re searching for it.

pre_get_network_by_path fires in get_network_by_path() and allows you to short-circuit core’s default logic for finding a network.


It’s exciting to see some of the progress we’re making around multisite. We’d like to see what can be solved or broken with the new filters. More future improvements will be made around this and we want to make sure the base is right.

Also take a look at the multisite focused tickets closed as fixed for 3.9. There are several other improvements and bug fixes that are worth taking a look at.

See #25348 for autocompleting users when adding a new site. See #20601 for proper 404 handling of non member author archives. See #24178 for past confusion with a plugin that is activated on the network and locally.

Thanks all!

#3-9, #dev-notes, #multisite

Let’s have a meeting today

Let’s have a meeting today, Tuesday April 15, 2014, 18:00 UTC, to make sure we have everything in place for a release. (#wordpress-dev)

#3-9, #agenda

Last Week in WordPress Core

Hello there! This is Last Week in WordPress Core for the week of April 8-April 14. Similar to last week, commits are included up to RC2, which was released today. In addition, maintenance releases 3.8.3 and 3.7.3 are available, and automatic updates are rolling out.


  • Widgets: Properly handle widget settings when activating a previewed theme. [28124] #27767
  • Widgets: Account for a sidebar with no container to which classes can be added. [28100] #27780
  • Custom Headers: Fix image ordering. [28102] #27791
  • Custom Headers: Fix cropping when working with large images. [28101] #27790
  • Add color scheme support for widget choosers. [28122] #27793

Theme Installer

  • Improve route handling and make ?theme= work. [28123] #27708
  • Revert to proxying through PHP for API requests to ensure we have valid installation nonces. [28126] #27798


  • Update TinyMCE to [28066] #27744
  • Update TinyMCE paste plugin to the latest development version. Improves Pasting from Word to remove inline comments and change tracking. [28089] #27771
  • Ensure vertical resizing and menubar show/hide are set to default for each TinyMCE instance. [28059] #27724
  • Stabilize MediaElement within TinyMCE, and avoid adding undo steps when the body of a wpView changes. [28084] #27389
  • Improve fallback compatibility for wpViews with IE7 and 8. [28062] [28063] #27546


  • In the Image Details modal, remember the last state of the advanced toggle. [28125] #27366
  • Add hooks for wpeditimage TinyMCE plugin and Image Details modal. Includes, which is intended to be a global media event bus. [28095] #27698
  • Apply new add_image_size() cropping preferences to all sizes when image is saved in editor. [28072] #19393
  • Fix tabbing out of the title field on Media->Edit Media screen. [28069] [28070] #27750


  • Updates: Add a TTL to core update checks to allow us to narrow the 12-hour update window. [28129] #27772
  • User Query: Don’t blindly re-append new meta queries for capabilities. [28087] #21119
  • Avoid stomping of bulk postdata inside the bulk_edit_posts() loop. Reverts [27990], which did not fix it for authors and comment/ping status. [28113] #27792
  • RTL fixes for Login screen ([28096] #27784), Themes screen ([28104] #27779), TinyMCE ([28094] #27773), and feature pointers ([28107] #27778).


For the complete list of commits to trunk, check out the log on Trac. Release is scheduled for this Wednesday, so, the best way to help is to test! Please let us know if you run into problems in the Alpha/Beta forums or on trac.

Thanks to @azaozz, @dd32, @DrewAPicture, @ehg, @GaryJ, @gcorne, @helen, @jesin, @johnbillion, @kerikae, @kpdesign, @mattheu, @matveb, @melchoyce, @morganestes, @nacin, @ocean90, @Otto42, @pavelevap, @redsweater, @ryelle, @scottlee, @SergeyBiryukov, @siobhan, @westonruter, @wonderboymusic, and @yoavf for their help this week!

#3-9, #week-in-core

HTML5 Galleries & Captions in WordPress 3.9

WordPress 3.6 introduced HTML5 versions of popular template tags, starting out with comments, the comment form, and the search form. With the 3.9 release we add galleries and captions to that list. Now, when adding HTML5 support for those features, WordPress will use <figure> and <figcaption> elements, instead of the generic definition list markup.

To declare that your theme supports these new HTML5 features, add the following call to your theme’s functions.php file, preferably in a callback to the after_setup_theme action:

add_theme_support( 'html5', array( 'gallery', 'caption' ) );

For forward compatibility reasons, the second argument with the specific parts can’t be omitted when registering support. Otherwise a theme would automatically declare its support for HTML5 features that might be added in the future, possibly breaking its visually because of it.

For both galleries and captions not only the markup changes when a theme declares its support for them, there are also peripheral changes that come with it.


By default, galleries will not include inline styles anymore when in HTML5 mode. This caters to the trend of disabling default gallery styles through the use_default_gallery_style filter, a filter that even the last two default themes used. With that, theme developers can always start with a clean slate when creating their own set of gallery styles.

We also took the opportunity to remove the line breaks between rows of images. Not only did they encourage an inferior way of positioning elements, more importantly they were non-semantic html elements that are meant for presentational use, and they made it harder to style galleries.


Up until now, captions received an additional 10 pixels of width, to keep text flowing around the caption, from bumping into the image. As @nacin put it, this has vexxed theme developers for years, and even resulted in the addition of a filter in WordPress 3.7 to manipulate the caption width.

We were not able to completely remove the inline style in HTML5 mode, it’s still necessary to force captions to wrap, but we’re no longer the adding 10px of width. We also removed caption styles in the editor, bringing it on par with how non-captioned images are displayed:

Twenty Thirteen and Twenty Fourteen have been updated to support both features, while retaining backwards compatibility with older WordPress versions. There is a remote possibility however, that child themes that use element selectors to overwrite gallery or caption styles can lose those customizations. Please test your child themes with the current development versions of the last two default themes.

If there are any questions about the current implementation, feel free to leave a comment below.

#3-9, #dev-notes, #editor, #gallery, #html5, #themes