Make WordPress Core

Tagged: 3.9 Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 5:52 am on May 6, 2014 Permalink
    Tags: 3.9,   

    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.

  • Mike Schroder 5:33 am on April 24, 2014 Permalink
    Tags: 3.9,   

    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 wp.mce.media.PlaylistView. [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.

  • Andrew Nacin 5:25 am on April 21, 2014 Permalink
    Tags: 3.9, ,   

    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

    • Andrew Nacin 5:28 am on April 21, 2014 Permalink | Log in to Reply

      If you’re able to look through tickets in your domain ahead of the meeting that would make it go pretty quick, and we can cover them really at any point during the day (I’ll be around all day), I just wanted to make sure the ball gets rolling.

    • Weston Ruter 11:39 am on April 21, 2014 Permalink | Log in to Reply

      Alas, I’ll be in the air at this time. Not sure I’ll have WiFi. I think widget customizer is in good shape for 3.9.1 with critical #27897 being committed and with minor #27878 having a patch.

    • greghall1 9:02 pm on April 25, 2014 Permalink | Log in to Reply

      Hi Andrew,
      Not sure if this is where I should post this info.
      I upgraded two of my WP sites to 3.9 and have lost the thumbnails where I have manually arranged my galleries (this is how I set up the whole of both sites in my Hydra themed greghall.ca & monkeypencollective.com). I cannot add media as I am worried it will destroy my current and desired galleries throughout.
      Greg Hall

  • Weston Ruter 8:10 pm on April 17, 2014 Permalink
    Tags: 3.9, appearance, ,   

    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-&gt;is_preview() ) {
        $cached = wp_cache_get( 'foo-widget' );
        if ( ! empty( $cached ) ) {
            echo $cached;
    extract( $args );
    echo $before_widget;
    // ...
    echo $after_widget;
    if ( ! $this-&gt;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!

  • Dominik Schilling (ocean90) 2:17 pm on April 16, 2014 Permalink
    Tags: 3.9, , ,   

    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 http://melchoyce.github.io/dashicons/.

  • Andrew Nacin 1:40 pm on April 16, 2014 Permalink
    Tags: 3.9, , , external libraries   

    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.

  • Jeremy Felt 6:31 am on April 16, 2014 Permalink
    Tags: 3.9, ,   

    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!

    • Ryan McCue 6:37 am on April 16, 2014 Permalink | Log in to Reply

      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.

      It’s worth emphasising: these constants refer to your network, not the site; get_site_by_path, however, refers to the site. (This is an artifact of the blog/site naming convention that’s being replaced with site/network.)

    • bvl 11:03 am on April 16, 2014 Permalink | Log in to Reply

      Great news, although I am a little disappointed that https://core.trac.wordpress.org/ticket/19722 still isn’t fixed, maybe in the next release?

    • rclilly 9:08 pm on April 16, 2014 Permalink | Log in to Reply

      Jeremy, Thanks for all work you’ve into improving multisite!

    • David 6:24 pm on April 17, 2014 Permalink | Log in to Reply

      I upgraded my multisite to 3.9 and this issue has occured….http://wordpress.stackexchange.com/questions/141578/3-9-breaks-multisite.
      Seems to be a bug of some sort as others are having the same issues. Looks to be a redirect issue of some sort.

    • lborgman 11:44 am on April 19, 2014 Permalink | Log in to Reply

      Many thanks for all the work with multisite!

      Here is however another issue that people coming here for information might be interested in:

      Solved: WP Multisite Stuck in Redirect Loop After 3.9 Upgrade http://www.webhostinghero.com/wp-multisite-stuck-in-redirect-loop/

      • Ipstenu (Mika Epstein) 3:09 am on April 20, 2014 Permalink | Log in to Reply

        That’s a poor choice of fixes, when a simple .htaccess redirect to force NON www will work fine (I don’t recommend using www on a Multisite as the default in general, and WP actually suggests you not do so at all when you’re installing, so I wouldn’t think that a fix that says to use it is the best call). Not to mention that how-to didn’t change the rest of the DB, which it should for consistency across the board. If you’re not using www in your site, a much easier fix is this:

        	RewriteEngine On
        	RewriteBase /
        	RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
        	RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

        Just added that to my site and it’s better. However I made a trac for this, since www should not be treated as a subdomain. It’s special.


  • Andrew Nacin 12:14 pm on April 15, 2014 Permalink
    Tags: 3.9,   

    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)

  • Mike Schroder 9:32 am on April 15, 2014 Permalink
    Tags: 3.9,   

    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 WordPress.org 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 wp.media.events, 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



    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!

    • Stagger Lee 5:03 pm on April 15, 2014 Permalink | Log in to Reply

      I am using WP Beta tester plugin, latest nightly and video playlist is still missing. Audio playlist is there. Is it normal for this beta moment ?

      • Mike Schroder 6:44 pm on April 15, 2014 Permalink | Log in to Reply

        Have you uploaded any videos? The “Create Video Playlist” option should appear on the left in the “Add Media” modal after you have videos uploaded to compile into a playlist.

    • Stagger Lee 8:23 pm on April 15, 2014 Permalink | Log in to Reply

      Yes i see now, thank you. Tried to upload it with FTP client first. (C/P, localhost) Still a bit confusing for beginners.

      Do you plan to make same styled playlists for Youtube videos ? I know there are plugins for it, but it is core code, style is fine and URL option is already there.

  • Konstantin Obenland 1:55 am on April 15, 2014 Permalink
    Tags: 3.9, , , , ,   

    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.

    • andrei1709 5:08 am on April 15, 2014 Permalink | Log in to Reply

      Awesome! Thank you very much for this update :)

    • Manuel Schmalstieg 12:07 pm on April 15, 2014 Permalink | Log in to Reply

      Glad to see that the HTML5 mode removes the BR tags from the gallery markup. That’s great news for responsive theme development!

    • Morten Rand-Hendriksen 3:12 pm on April 15, 2014 Permalink | Log in to Reply

      This is great and long overdue. I always say WordPress is at the forefront of web standards and the two thing that have been lagging behind are the galleries and comments. This is a major milestone that will change the way we think about built in features.

    • glueckpress 9:15 am on April 16, 2014 Permalink | Log in to Reply

      (goes updating themes)

    • Justin Kopepasah 6:43 am on April 17, 2014 Permalink | Log in to Reply

      This is great news. I was happy when the filter was introduced and now I am elated to see the ability to implement HTML5 galleries completely. Definitely adding this to my latest theme.

    • car57 6:52 pm on May 14, 2014 Permalink | Log in to Reply

      I am not a developer, so would you be so kind as to explain what is meant by:

      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’ ) );

      I have a functions.php file for a child theme. I don’t know what code to insert to have “a callback to the after_setup_theme action”


      • Knut Sparhell 12:39 am on May 15, 2014 Permalink | Log in to Reply

        A callback is a function (or class method) that is added to an action by add_action(). In this case add_action( 'after_setup_theme', 'my_theme_setup' );. Inside my_theme_setup() function you can add the theme support. It could also be added in other actions, like ‘init’ or ‘wp_loaded’, but not before ‘after_setup_theme’ has fired. If you just add the support in the outer scope of functions.php it may be executed too early in the load process. The internal data structures to receive this theme addition may not have been initialised before ‘after_setup_theme’.

        The outer scope of functions.php (and plugins) should only add actions and filters, nothing else. All things you want to do should be inside a “callback” (a function or a class method, to be precise).

        See http://code.tutsplus.com/articles/the-beginners-guide-to-wordpress-actions-and-filters–wp-27373

    • car57 7:56 pm on May 14, 2014 Permalink | Log in to Reply

      no matter how i add php to functions.php, this script is never run. Still getting old-style dl with inline css. Sigh.

    • paulinelephew 12:02 pm on July 23, 2014 Permalink | Log in to Reply

      Hi there,

      I am using the Argo theme and I have no caption displaying with galleries.
      I have tried about everything (including contacting the theme support a zillion times and they won’t get back to me).

      I inserted the lines below in function.php and nothing happens:

      add_action( ‘after_setup_theme’, ‘argo_setup’ );
      add_theme_support( ‘html5’, array( ‘gallery’, ‘caption’ ) );

      the website is http://www.terredalizes.fr

      If anyone can help it is greatly appreciated!



compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar