Last Week in WordPress Core

Hi Everyone! This is the first Last Week in WordPress Core for WordPress 4.0! Last week, a minor update, 3.9.1 was released, and autoupdates started shortly afterwards. Development on 4.0 is ongoing, and you can see notes and meeting details posted by @helen on this blog as well.


  • In, when handling checkboxes, check for a value of false in addition to casting value to boolean. !! false evaluates to true. [28371] #23954
  • Allow users to set overrides for MediaElement instances by always passing _wpmejsSettings instead of just _wpmejsSettings.pluginPath. [28370] #25243
  • When pausing “all” players attached to MCE views, don’t reach into global scope and pause every player. Only pause the players bound to MCE views. [28364] #27971
  • In wp_read_image_metadata(), the values from exif_read_data() should only override values from iptcparse() that are empty. [28367] #23706
  • Support loop for [audio] and [video] shortcodes that specify files that are played using MediaElement’s Flash plugin bridge. [28363] #27368
  • MediaElement players need clear: both to play nice with adjacent floated elements. [28361] #27385


  • Custom Navigation Widget: Force users to choose a nav menu in the custom nav menu widget, for a better customizer UX. Before, they had to make a dummy change to get it to render. Now they are made to choose a nav menu from the dropdown, which feels more natural. [28197] #27878
  • Recent Posts Widget: Use ob_end_flush() instead of ob_flush(). ob_end_flush() flushes the output buffer and turns output buffering off, same as ob_get_flush(). [28195] #28009

Themes and Templates:

  • Prevent paged-* from being added to body classes and prevent Page %s from being added to page title on 404 error pages on default themes. [28249] #16468
  • Bundled Themes:Prevent Page %s from being added to page title on 404 error pages in bundled themes. [28250] #16468.
  • Bundled Themes: Use correct logic in IE conditional comments in header template. [28341] #28151
  • Set the proper value for wp_title() when is_author() and is_post_type_archive() are both true. post_type should always win due to the precedence indicated in get_queried_object(). [28251] #25398
  • Update the default (WP-defined) styles for MediaElement players to be more in-line with our flat aesthetic. Use the new official colors. [28365] #27516

Custom Headers:

  • Allow to skip cropping header images if image width is smaller than or equal to theme width. [28219] #27936
  • Avoid hiding ‘Remove’ buttons unrelated to custom headers. [27882] #27848
  • Keep header image from being removed when background image is removed. [28269] #28046
  • Avoid warnings in the process_default_headers() method. #27850
  • Fix logic when a theme doesn’t set default-text-color. [28294] #28042


  • Move home option to the top of populate_options() to make it easier to find next to siteurls for manual changes. [28260] #28141
  • Scrutinizer Cleanup: @wonderboymusic has started the process of cleaning up core with Scrutinizer. Check out the full list of fixes so far on #27882.
  • Hack/HHVM Compatibility: More from @wonderboymusic. See #27881 and #22400.
  • Dev Tools: Introduce default wp-cli.yml for core development. [28221] #28036
  • Add .dfxp and .srt files to mime-type whitelist in wp_get_mime_types(). They are both captioning formats supported by MediaElement. [28259] #27643
  • Add .xps and .oxps extensions to list of supported document types. More about the types on Wikipedia. [28372] #15697
  • When $type is atom in get_the_category_rss(), use get_bloginfo_rss( 'url' ) when setting the scheme attribute for the <category> node. [28258] #24444
  • In WP_Date_Query::get_sql_for_subquery(), don’t parse duplicate parameters – only parse one of w and week or month and monthnum. [28252] #25835
  • Add a filter for wp_list_comments() arguments. [28285] #19581
  • In get_the_author_posts(), if there is no current $post, return 0 and bail. [28362] #27998
  • In WP_Terms_List_Table::single_row(), call sanitize_term() on the passed term ($tag). [28360] #16864



  • First pass at wpview logic for the shortcode. URLs pasted on their own line are parsed as well. The toolbar will appear with the “remove” button when the view is clicked. Edit has not been implemented yet, nor have safety measures for non-iframe embeds. [28358] #28195
  • Audio, video, and playlist shortcodes: [28342] #22400, #27881
    • Convert all instances of variable variables to array properties
    • Stop using extract()
    • Rename $atts to $html_atts where collision with new $atts (shortcode atts holder) var might occur
  • Shortcode JS: Avoid errors when an escaped shortcode includes a newline between brackets. [28223] #27907


  • Fix case sensitivity regressions in 3.9. [28276] #27866
  • Treat “www” as a special subdomain, reversing 3.9 regression. [28280] #27927

Thanks to @andrezrv, @arnee, @avryl, @azaozz, @boonebgorges, @celloexpressions, @Clorith, @danielbachhuber, @dimadin, @ebinnionm, @ehg, @ericlewis, @feedmeastraycat, @GaVrA, @gcorne, @greenshady, @helen, @hlashbrooke, @imath, @jartes, @jdgrimes, @jeremyfelt, @johnbillion, @jorbin, @jupiterwise, @mattwiebe, @MikeHansenMe, @m_i_n, @obenland, @ocean90, @pavelevap, @psoluch, @rob1n, @rzen, @sergej.mueller, @SergeyBiryukov, @t4k1s, @Tmeister, @westonruter, and @wonderboymusic for their help!

For the complete list of commits to trunk, check out the log on Trac. We’ve been chatting about 4.0 plans, and things are shaping up. Come chat this Wednesday to continue the discussion, and please note if you encounter issues with 3.9.1 on Trac.

#4-0, #week-in-core

Finding and Fixing JavaScript errors with JSHint

The JavaScript Coding Standards have been updated, so it’s time to move on to tackling our JSHint errors!

JSHint is a tool to check for errors in JavaScript code. As was discussed last week, we’re kicking off a small effort to work through our core JavaScript files. To get through the errors revealed by JSHint as quickly as possible, we’re following the model established by the Inline Docs team and posting a list of files with issues so that people can “claim” the files they’d like to fix!

At the bottom is a list of every file in core that is displaying JSHint errors. Files with a checkmark have been patched and should now be passing lint. Files marked with (@username #xxxxx) are already claimed, and being worked on.

Please read and understand the process we’ll be following to address these issues! Many thanks to @azaozz, @nacin and @jorbin for helping identify the safest way to approach fixing these errors, and to @rzen for posting the Inline Docs article on which we based this guide.

How to contribute:

  1. Leave a comment on this post with the file* you’re about to edit (check the list first to make sure it hasn’t already been claimed).
  2. Update your local WordPress SVN to the latest version of WordPress trunk (currently 3.8-alpha).
  3. Create a new ticket on Trac for the file.
    JSHint-related trac ticket settings
    • Format the title as “jshint shouldn’t throw errors – path/to/file.js”.
    • Assign the ticket to the “Build Tools” component.
    • Make sure your email is stored in Trac’s preferences

    If you are logged in, you can click this link to automatically open a ticket with the right settings.

  4. Edit the file, and make a patch. Please make sure you create the patch from the root directory of your WordPress SVN checkout. If you are working on a large file, consider making multiple patches for each type of change.
  5. Upload your patch to the Trac ticket you created, and add the keyword “has-patch”.

*Note: We strongly encourage you to work on one file at a time. These shouldn’t take very long, but if you call a bunch at once and get tied up, we won’t be able to get through these as quickly as possible. To quote @rzen from the inline docs effort, “your edits should be made and patched swiftly so that they aren’t invalidated by (or don’t invalidate) another patch.”

Keeping Discussions Focused:

Any discussion about the specifics of a patch itself should happen on Trac. Discussion about the overall effort should take place during our standing weekly meeting, on Wednesdays at 1900 UTC in #wordpress-dev*.

Files needing patches:

Checked files are now passing JSHint

  • wp-admin/js/common.js (@jorbin, #25912)
  • wp-admin/js/custom-background.js (@jorbin, #25915)
  • wp-admin/js/custom-header.js (@jorbin, #25916)
  • wp-admin/js/customize-controls.js (@jorbin, #25917)
  • wp-admin/js/dashboard.js (@tommcfarlin, #25943) (@nacin)
  • wp-admin/js/edit-comments.js (@adamsilverstein, #25979)
  • wp-admin/js/editor.js (@dougwollison, #25947) (@nacin)
  • wp-admin/js/gallery.js (@dougwollison, #25999) (@jorbin)
  • wp-admin/js/image-edit.js ( #26000)
  • wp-admin/js/inline-edit-post.js ( #26001) (@jorbin)
  • wp-admin/js/inline-edit-tax.js ( #26002) (@jorbin)
  • wp-admin/js/link.js ( #26034)
  • wp-admin/js/media-gallery.js (@tommcfarlin, #25942) (@nacin)
  • wp-admin/js/media-upload.js ( #26023)
  • wp-admin/js/media.js ( #26020)
  • wp-admin/js/nav-menu.js (51 errors)
  • wp-admin/js/password-strength-meter.js ( #25990)
  • wp-admin/js/plugin-install.js ( #25993)
  • wp-admin/js/post.js ( #25994)
  • wp-admin/js/postbox.js (10 errors)
  • wp-admin/js/revisions.js ( #25864)
  • wp-admin/js/set-post-thumbnail.js ( #26008)
  • wp-admin/js/tags.js ( #26009)
  • wp-admin/js/theme-install.js (@kovshenin, #26045) (@nacin)
  • wp-admin/js/theme-preview.js (@tommcfarlin, #25944) (@nacin)
  • wp-admin/js/theme.js (22 errors) (@nacin)
  • wp-admin/js/user-profile.js ( #26016) (@jorbin)
  • wp-admin/js/user-suggest.js ( #26017) (@jorbin)
  • wp-admin/js/word-count.js ( #26018) (@nacin)
  • wp-admin/js/wp-fullscreen.js ( #26029)
  • wp-admin/js/xfn.js ( #25997)
  • wp-content/themes/twentyfourteen/js/functions.js ( #26031) (@jorbin)
  • wp-content/themes/twentyfourteen/js/slider.js ( #26032) (@jorbin)
  • wp-includes/js/admin-bar.js (@kadamwhite, #25970)
  • wp-includes/js/autosave.js ( #26035)
  • wp-includes/js/comment-reply.js ( #26038)
  • wp-includes/js/customize-base.js ( #26039)
  • wp-includes/js/customize-loader.js ( #26040)
  • wp-includes/js/customize-preview.js ( #26019)
  • wp-includes/js/heartbeat.js ( #25986)
  • wp-includes/js/jquery/jquery.table-hotkeys.js ( #26015)
  • wp-includes/js/media-editor.js ( #26022)
  • wp-includes/js/media-models.js (@kadamwhite, #26132)
  • wp-includes/js/media-views.js (@kadamwhite, #25974)
  • wp-includes/js/mediaelement/wp-mediaelement.js (3 errors)
  • wp-includes/js/plupload/handlers.js ( #26041)
  • wp-includes/js/plupload/wp-plupload.js (@atimmer, #26044)
  • wp-includes/js/quicktags.js (@kovshenin, #26046)
  • wp-includes/js/shortcode.js (@tommcfarlin, #25945) (@nacin)
  • wp-includes/js/tinymce/mark_loaded_src.js ( #26014)
  • wp-includes/js/tinymce/plugins/wordpress/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpdialogs/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpeditimage/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpfullscreen/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wpgallery/editor_plugin_src.js ( #26048)
  • wp-includes/js/tinymce/plugins/wplink/editor_plugin_src.js ( #26024)
  • wp-includes/js/tinymce/plugins/wpview/editor_plugin_src.js ( #26027)
  • wp-includes/js/utils.js (@adamsilverstein, #25957)
  • wp-includes/js/wp-ajax-response.js (@originalexe, #25954)
  • wp-includes/js/wp-auth-check.js ( #26009)
  • wp-includes/js/wp-list-revisions.js (#25864)
  • wp-includes/js/wp-lists.js ( #26012)
  • wp-includes/js/wp-pointer.js ( #26012)
  • wp-includes/js/wp-util.js ( #25957)
  • wp-includes/js/wplink.js (@jorbin, #25914)

See all open tickets in the Build Tools component

For tips on dealing with global variables, inlined third-party code within first-party scripts, etc, see the JSHint tips in the JavaScript Coding Standards

For the curious, this list was created with a jazzy little command @nacin came up with to pipe Grunt output through ack:

grunt jshint --force | ack '^Linting src/' | ack -o 'wp-.*.js' | sort | uniq -c | sort

What we’re NOT doing

The two JSHint options called out in the earlier post, “curly” and “eqeqeq,” would ordinarily make up the vast majority of the errors JSHint reports in our files. We’ve currently set Grunt and JSHint to ignore these two types of errors when JSHint is run against core. While these are best practices, we’ll come back to them once we address the more significant code smell issues like undefined variables.

Also note that we’re not tackling whitespace or non-JSHint-related refactoring during this effort. We’ll get there, but we have to mitigate the risk to core as much as possible so we don’t interrupt the 3.8 cycle. Keep your changes focused on passing JSHint this go-around.

#build-tools, #javascript, #jshint

The State of Inline Docs

We haven’t posted an update in several weeks, so thought we’d bring everyone up to speed on the Inline Docs project.

This project started July at WordCamp San Francisco as a 3.7 release action item. Work continues into the 3.8 release cycle, and we would like to have the hook documentation completed by the time 3.8 is released in December.

PHP Documentation Standards

The PHP Documentation Standard has been amended several times since it was first published in early September. The latest amendments include:

If you are one of our contributors, please make sure you read the standards again to familiarize yourself with the changes.

WordCamp Contributor Days

We would like to thank WordCamp Toronto (10/6), WordCamp Europe (10/7), and WordCamp Sofia (10/27) for including Inline Docs as part of their respective Contributor Days. Approximately 35 files were documented, and several new contributors had their first patches committed to WordPress core as a result. Woot!


So far, 47 people have received props for submitting inline docs patches:

@admiralthrawn, @aeg0125, @a.hoereth, @andg, @aralbald, @bananastalktome, @ben.moody, @betzster, @bftrick, @dllh, @drewapicture, @dougwollison, @dustyf, @enej, @ericlewis, @Faison, @FrankKlein, @gayadesign, @gizburdt, @johnafish, @johnbillion, @jonlynch, @kpdesign, @l10n, @nacin, @naomicbush, @NikV, @ninio, @miyauchi, @morduak, @Nao, @natejacobs, @netweb, @nukaga, @nullvariable, @pauldewouters, @r3df, @rzen, @sboisvert, @SergeyBiryukov, @ShinichiN, @Siobhyb, @swissspidy, @tmtoy, @tomauger, @tw2113, @vinod dalvi

There are 10 other contributors with patches waiting to be reviewed and committed that will be added to this list. We want to thank everyone for their participation so far, and hope you continue contributing!

Progress To Date

According to the “master list“, there are 185 files containing hooks to be documented. The current status, as of today:

  • Completed: 92 files (49.72%)
  • In progress: 23 files
  • Available to claim: 70 files

Weekly Office Hours

We continue to hold weekly office hours meetings on Wednesdays at 19:00 UTC in #wordpress-sfd.

#3-8, #inline-docs

Add Inline-Docs for Hooks

The time to document ALL THE HOOKS used throughout core is nigh.

We’ve hashed out the process in a couple of different meetings in #wordpress-dev, and we’ve added a new page to the Core Contributor Handbook that covers the broader PHPDoc standards, as well as the specific hook documentation standards (the praise for the bulk of that work should go to @kpdesign and @drewapicture, by the way).

At the bottom is a list of every file in core that has a call to either do_action() or apply_filters(). Files with a checkmark have been patched and are considered completed. Files marked with (username #xxxxx) are already claimed, and being worked on.

Directly below is the process we’re attempting to make sure each of these files can get patched swiftly with no duplicated nor wasted efforts.

How to contribute:

  1. Check the list first to make sure the file you want to work on hasn’t already been claimed.
  2. Update your local WordPress SVN or Git repo (use git pull) to the latest version of WordPress trunk (currently 3.9-alpha).
  3. Create a new ticket on Trac for the file.

    New Hook Docs Ticket Example

    • Format the title as “Hooks Docs: path/to/file.php”.
    • The Type should be “defect (bug)”.
    • Assign the ticket to the component the file is associated with.
    • Leave the Version blank.
    • Add the docs focus.
  4. Edit the file, and make a patch. Please make sure you create the patch from the root directory of your WordPress SVN or Git checkout.
  5. Upload your patch to the Trac ticket you created, and add the keyword “has-patch”.

*Note: We strongly encourage you to work on very few files at a time. In many cases, one at a time is probably best. In some cases it may make sense to tackle several at once. The important thing is that you realize your edits should be made and patched swiftly so that they aren’t invalidated by (or don’t invalidate) another patch. It’s also important to note that we’re working with a small time-table, and need to be able to claim, edit, patch quickly — which is hard to do if someone were to lay claim to 20 files at a time, and then sit on them for a few days.

Determining the since version for hooks

The recommended tool to use when searching for the version something was added to WordPress is svn blame. An additional resource for hooks is the WordPress Hooks Database. If, after using these tools, the version number cannot be determined, use @since Unknown.

Note: All @since tags should follow the three digit x.x.x format, unless it was ported from MU. Anything ported over from WPMU should use @since MU. Existing @since MU tags should not be changed.

Keeping Discussions Focused:

Any discussion about the specifics of a patch itself should happen on Trac. Any discussion about the broader scope of what we’re trying to do should take place during the weekly Inline Docs meeting on Wednesdays at 19:00 UTC in #wordpress-sfd.

Files needing patches:

Checked files are completed, marked files are claimed

Current status:

#3-7, #inline-docs

WordPress 3.7 organization

With WordPress 3.7 and 3.8, we’re a project in major transition. Version 3.7 aims to solve for a lot of things that are weighing us down. (See the initial kickoff post.) What do you want to do? In terms of process, here is what is being worked on for 3.7:

Processes, Tools, Workflows

  • New development tools — — run by @koop. If you are interested in Grunt, unit testing (including JS testing), and how we can streamline and modernize our workflows, this is for you.
  • Code reference — inline documentation efforts — run by @rzen, @ericlewis, and @drewapicture. If you are interested in inline documentation, this is for you. See this post to get started.
  • Process changes (including improvements to Trac and how we organize around components). If you want to write some Python for Trac, this is for you. If you’re just interested in helping with component reorganization, stay tuned here — there will be a post soon outlining a new component tree.

Security, Stability, and Updates

We have a few other focuses that all deal with a general theme of security and stability.

  • Passwords. We are aiming to improve the adoption of best security practices by assisting with password generation. #24633@duck_ is also working on some changes to strengthen cookies. #20276. If you are interested in security, this is for you.
  • Updates. @dd32 and @pento will be heading up automatic updates for minor releases, as well as improving the trustworthiness of our upgrader. If you love updates and stability, this is for you.
  • Language packs. We need to separate language files from plugins, themes, and core, allowing them to be maintained and updated independently (and, ideally, automatically). #18200. If you want to help WordPress’ global reach, hook up with me, @dd32, and @markoheijnen.

General Triage

Finally, we have 3,800 (already only 3,600) open tickets on Trac. There are dozens of components with many, many tickets. Already, there have been a few components with a strong base of contributors working on them, including:

  • Multisite, currently being smashed by @jeremyfelt and others. If you like multisite and want to make it better and more stable, this is for you. There are currently 122 open tickets.
  • JavaScript. A number of you have expressed interest on working on JavaScript in core. Whether that is shoring up the stability of existing features, improving existing JS, or working on a JS testing framework, this should be a great working group. @carldanley, @adamsilverstein, @nbachiyski, @kadamwhite, and others expressed interest.
  • Query and Taxonomy. These two advanced areas of core kind of go hand-in-hand, not in the least because @wonderboymusic smashes query tickets with his left hand and taxonomy tickets with his right. If you’re interested in bringing down these tickets (68 and 93 open), this is for you.
  • General triage. Folks like @c3mdigital and @avryl have been already going through old tickets either closing them out or finding diamonds in the rough. Or maybe you find that one of the many open components catches your interest. (Go here and choose any component from the drop-down to see all open tickets.) We’ll be coordinating efforts to work together both in IRC (especially during the weekly meetings) and here on make/core.
  • Components with a lot of open tickets: General (376 tickets), Administration (302 tickets), Media (221 tickets), Template (161 tickets), Comments (135 tickets), Users (107 tickets), Themes (105 tickets), Formatting (98 tickets), Menus (96 tickets), Widgets (90 tickets), Plugins (90 tickets), Editor (85 tickets), Upgrade/Install (84 tickets), Import (70 tickets). If you want to do general triage, General and Administration in particular need a lot of work!

Today during the weekly meeting, we’ll be talking about ongoing efforts, rallying the troops and helping to assemble working groups, and setting up some times for regular triage meetings.

So, what do you want to work on? Let’s start coordinating in the comments.


Better Inline Docs for 3.7

For the 3.7 cycle we’re going to focus hard on improving the inline docs throughout WP core. Eric Lewis, Drew Jaynes and myself will be leading this charge, and we invite anyone who is interested to join us.

You can join us for a meeting on the subject in #wordpress-dev IRC on Tuesday, August 13, 18:00 UTC.

For the first time ever, we’ll be adding inline docs to the many, many hooks found within core. This is the area I’ll be contributing the most, personally. Since we’ll mostly be marching to the beat of our own drum to document the hooks, so I’d like to use the remainder of this post to explain a bit more about our plan of attack – which we’ll discuss during Tuesday’s meeting.

Hook Doc Style

We’ll be using the same inline PHPDoc standard that is used for functions to documenting each of the hooks. This means both short description and long descriptions (where applicable), along with @since and @param tags. We will not be using the @return tag, however, because actions return nothing and filters simply return the first param.

The DocBlocks will appear, in almost every case, on the line directly preceding the call to do_action() or apply_filters. We feel this is the most logical placement when grokking the code as a human, and also the most convenient position for the parser that will power

Some Examples:

Note that in this third example we are using on the PHPDoc spec for describing hashes in order to document each of the passed items in the array. This, I think, provides a great deal of context for the array and a much greater value to our documentation (especially given the number of filters in core that pass arrays). As an aside, I agree that it may be odd we’re referencing the associative array keys as var names, rather than a string literal, but it’s necessary for parsing the docs properly.

Some Potential Issues

  1. I know there are a few hooks that appear in more than one location. In this case we’ll be documenting them in just one function and adding a pointer to that function across all other instances. We’ll determine the best way to handle this pointer in the weeks to come, for the immediate future I’ll just be using a shorthand comment for my own references.
  2. Many filters throughout core passed unnamed parameters and just embed the values of their parameters directly. In these instances I look first to core to see if an add_filter() is being called on the filter and then default to the var names passed there. If core is not calling the filter anywhere I’ve used names that seem most logical (e.g. $output)
  3. Several hooks have variable names. I don’e believe this will actually pose an issue, but I do want to make note of it.


Because of the sheer volume of things we need to document, the best idea I’ve got so far (as recommended by Mark Jaquith) is to allow anyone willing to contribute an opportunity to “claim” the files they’d like to document. This would grant them a 2 day “lock” on the file(s) to document everything and submit a patch. This will help us minimize or eliminate duplicated efforts and stale patches as much as possible. We’ll likely have 2 separate tickets: one for documenting hooks, one for documenting functions, and all patches will be made directly to those tickets. This could become unwieldy, and we’ll discuss the merits of this approach in Tuesday’s meeting.

Don’t worry if you really want to help, but can’t attend the meeting. It will all be logged, and we’ll be posting updates back to the blog here (using the inline-docs tag). Once we get underway you’ll be able to track progress directly on the trac tickets.

Hope you’re as excited about this as I am!

#3-7, #inline-docs