WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Welcome to the official blog of the core development team for the WordPress open source project.

Here, we make WordPress core. Follow our progress with general updates, status reports, and the occasional code debate.

We’d love for you to help out.

Looking to file a bug?

It’s easy to create a ticket on our bug tracker.

Want to contribute?

Get started quickly. We have some tickets marked as good first bugs for new contributors. There’s more on our reports page, like patches needing testing.

We also have a detailed handbook for contributors, complete with tutorials.

Weekly meetings

We use IRC for real-time communication. As contributors live all over the world, there are discussions happening at all hours of the day.

We have a project meeting every Wednesday at 21:00 UTC in the #wordpress-dev channel on chat.freenode.net. (Quick start: There’s a web interface.)

You can find meeting agendas on this blog. You’re welcome to join us or listen in.

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Dominik Schilling (ocean90) 2:17 pm on April 16, 2014 Permalink | Log in to leave a Comment
    Tags: , ,   

    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

    TinyMCE/Editor

    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

    Sorting

    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

    Widgets

    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

    Alerts/Notifications/Flags

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

    Icon CSS Class Code
    dashicons-plus-alt f502

    Misc/CPT

    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 | Log in to leave a Comment
    Tags: , , , 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 | Log in to leave a Comment
    Tags: , ,   

    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.

    Ongoing

    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!

  • Andrew Nacin 12:14 pm on April 15, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    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 | Log in to leave a Comment
    Tags:   

    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.

    Customizer

    • 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

    TinyMCE

    • Update TinyMCE to 4.0.21.1. [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

    Media

    • 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

    Internals

    Externals

    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 | Log in to leave a Comment
    Tags: , , , , ,   

    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.

    Galleries

    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.

    Captions

    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.

     
  • Ryan McCue 7:08 am on April 14, 2014 Permalink | Log in to leave a Comment
    Tags:   

    JSON REST API: Meeting Time Change 

    As announced on the team o2, the meeting time for the API team is changing to Tuesday, 0:00 UTC, in #wordpress-dev.

    This week we’re discussing OAuth (which, P.S., is now available for testing), 1.0 and custom post type data privacy.

    Hopefully I’ll see you there!

     
  • Ryan McCue 2:12 am on April 14, 2014 Permalink | Log in to leave a Comment
    Tags: , , , symlinks   

    Symlinked Plugins in WordPress 3.9 

    One of the cool little features included with 3.9 is the ability to symlink plugin directories. While it has been possible to symlink plugins in the past, functions such as plugins_url() return the wrong URL, which causes breakage in most plugins.

    In #16953, r27158 and the followup r27999, we corrected this with the help of a new function: wp_register_plugin_realpath(). This function is called automatically during the plugin loading phase, and registers which plugin directories are symlinked, and where they’re symlinked to. This functionality is then used by plugin_basename() (the core of plugins_url(), along with other
    functions) to reverse symlinks and find the correct plugin directory.

    This enhancement means that you can symlink individual plugin directories, or even the whole plugins directory itself.

    For anyone who’d like to use this, keep in mind that there are a few caveats:

    • Single-file plugins are not handled by this code. Any plugins you’d like to symlink must be in subdirectories of the main plugins folder. This restriction is due to the way these paths are registered.

      You can still symlink single-file plugins, however any use of plugin_basename() will be as broken as it was before 3.9. This is not a huge issue, as the main use of this is in plugins_url(), which is not frequently used in single-file plugins.

    • Must-use plugins cannot be symlinked. For the same reasons as single-file plugins, mu-plugins are not handled.

      For anyone using the common pattern of subdirectories within mu-plugins with a common loader file, you can use wp_register_plugin_realpath() directly to ensure that your subdirectories are handled.

      The following example code demonstrates how to use the function:

      <?php
      $plugins = array(
      	'my-mu-plugin/my-mu-plugin.php',
      );
      foreach ( $plugins as $plugin ) {
      	$path = dirname( __FILE__ ) . '/' . $plugin;
      
      	// Add this line to ensure mu-plugins subdirectories can be symlinked
      	wp_register_plugin_realpath( $path );
      
      	include $path;
      }
      

      Hopefully this change is as helpful for you as it was for me! One of the great advantages to this is that plugin developers can keep their plugin separate from their WordPress installation. This is a boon for developers with multiple installs who want to test compatibility; keep in mind that you can symlink the entire plugins directory if you're testing multiple!

      If you have any questions about this, please leave a comment on this post and we'll be happy to help you out!

     
    • PeterRKnight 2:29 am on April 14, 2014 Permalink | Log in to Reply

      This is super handy

    • Mike Schinkel 4:25 am on April 14, 2014 Permalink | Log in to Reply

      Kudos Ryan for pushing that feature through.

    • Julien 6:50 am on April 14, 2014 Permalink | Log in to Reply

      That’s great news! Thanks!

    • Fab1en 7:36 am on April 14, 2014 Permalink | Log in to Reply

      Thanks for this Ryan !
      I was using a custom plugin that tweaked `plugin_basename` to make it work with symlinked plugins. Thanks to you, I will not need this plugin anymore !

    • klihelp 12:37 pm on April 14, 2014 Permalink | Log in to Reply

      Thanks for the post.

      >> This is a boon for developers with multiple installs who want to test compatibility
      Tell me more about this.
      Could I read as a multiple WP installs uses the same plugin directory, so you don’t have multiple copies of the plugins?

      • Fab1en 3:42 pm on April 15, 2014 Permalink | Log in to Reply

        yes, that is what you can read ! Just add a symlink to a shared plugins directory in each WP install wp-content folder, and your installs will share the same plugins copy.

    • hinnerk 3:06 pm on April 14, 2014 Permalink | Log in to Reply

      Thanks a lot! Great enhancement! Makes my developer live much easier!

    • Frank 3:18 pm on April 14, 2014 Permalink | Log in to Reply

      Really useful, reduce the custom work.

    • Brian Layman 3:44 pm on April 14, 2014 Permalink | Log in to Reply

      This is a neat little thing. We’d experimented with symlinking the files back in b5media days with our 350ish sites, but there were enough little oddities to make it not the right choice for a poor man’s MU option.

    • Primoz Cigler 5:33 pm on April 14, 2014 Permalink | Log in to Reply

      Very important and useful update. But I have a question: is something like this possible with the themes as well? Would make perfect sense for the same reason, if you are a theme developer: “One of the great advantages to this is that theme developers could keep their theme separate from their WordPress installation. This is a boon for developers with multiple installs who want to test compatibility; keep in mind that you could symlink the entire themes directory if you’re testing multiple!”

      • Ryan McCue 2:12 am on April 17, 2014 Permalink | Log in to Reply

        But I have a question: is something like this possible with the themes as well?

        I can’t think of any issues with allowing this; file a ticket on Trac! :)

    • Primoz Cigler 5:34 pm on April 14, 2014 Permalink | Log in to Reply

      This is very important and useful update. But I wonder if something similar would be possible with the themes too? For the same obvious reasons as for plugins.

    • hinnerk 7:25 am on April 15, 2014 Permalink | Log in to Reply

      I had to add Options +FollowSymLinks to my .htaccess in order to remove a 403 Forbidden on all pages (using symlinks in plugins directory).

    • hinnerk 7:27 am on April 15, 2014 Permalink | Log in to Reply

      I had to add Options +FollowSymLinks to my .htaccess to remove a 403 Forbidden on all pages (using symlinks in /wp-content/plugins/).

    • Todd Lahman 8:45 am on April 15, 2014 Permalink | Log in to Reply

      This is totally awesome!

    • elimc 7:00 pm on April 16, 2014 Permalink | Log in to Reply

      I’m a bit confused about what this future does. Does this allow me to define a constant on my local server that links to the plugin directory on remote sites, thereby, preventing the need to duplicate the same plugins on both the local and remote server?

      • Ryan McCue 2:13 am on April 17, 2014 Permalink | Log in to Reply

        This doesn’t allow you to share plugin files across HTTP, no. It does allow you to have certain plugins live outside of your WordPress content directory, which means you can share the same code between multiple installations on the same server.

  • Konstantin Kovshenin 11:20 am on April 11, 2014 Permalink | Log in to leave a Comment
    Tags: , , ,   

    Plupload 2.x in WordPress 3.9 

    Plupload is the library that powers most of the file upload interfaces in WordPress, and in 3.9 we’ve updated the bundled library to version 2.1.1 (#25663). Here are some of things that have changed, which may affect WordPress plugins and themes.

    If you’re using direct references to Plupload’s runtime .js files, such as plupload.html5.js, note that these files are now gone. The following script handles were removed: plupload-html5, plupload-flash, plupload-silverlight and plupload-html4. If you need to enqueue the Plupload library, just use the plupload handle.

    If you’re constructing your own Plupload settings array vs. using wp_plupload_default_settings() and/or the _wpPluploadSettings object, note that some of the arguments have changed, most notably:

    • flash_swf_url should point to the new Moxie.swf file (See update)
    • Similarly, silverlight_xap_url should use the new Moxie.xap (See update)
    • The multiple_queues argument is no longer used
    • The max_file_size key has been moved to the filters array
    • The filters array now supports multiple keys, and the list of file types array has been moved to its mime_types key

    To illustrate that with code:

    $settings = array(
        // ...
        'flash_swf_url' => includes_url( 'js/plupload/plupload.flash.swf' ), // Unchanged
        'silverlight_xap_url' => includes_url( 'js/plupload/plupload.silverlight.xap' ), // Unchanged
        'filters' => array( 
            'max_file_size' => $max_upload_size . 'b', 
        ),
    );
    

    Plupload version 2.1.1 has also added some exciting new options and methods, which you can find in the updated documentation.

    As a result of this update in WordPress 3.9 we were able to add drag and drop upload support directly to our TinyMCE editor (#19845), and we’ve also added a new boolean flag to wp_editor(), which you can use to enable drag and drop upload support in your own instance of the editor (#27465):

    wp_editor( '', 'my-editor', array(
        // ...
        'drag_drop_upload' => true,
    ) );
    

    If you run into any problems with this update in 3.9, please leave a comment on this post and we’ll be happy to help you out!

    Update: I opened #27763 to address some of the compatibility issues around the update. We might be renaming the swf/xap files for backwards compatibility.

    Update, April 13: The original swf/xap filenames were restored.

     
  • Scott Kingsley Clark 4:24 am on April 11, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Metadata API/UI Meeting 04/11 

    As discussed in the previous meetings, we’re pushing the time back one hour from 19:00 UTC to the new time at 18:00 UTC on Fridays. We’ll be in #wordpress-core-plugins tomorrow, April 11th, 2014 as usual.

    We will be talking about the progress on form and field registration and move into some new modeling oriented based on objects (post types) instead of forms as previously discussed.

    See you all there!

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel