Week in Core, Feb. 23-Mar 1 2016

Welcome back the latest issue of Week in Core, covering changes [36672-36800]. Here are the highlights:

  • 128 commits
  • 52 contributors
  • 115 tickets created
  • 19 tickets reopened
  • 135 tickets closed

Ticket numbers based on trac timeline for the period above.

Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

Continue reading

#4-5, #week-in-core

Week in Core, Feb. 16-23 2016

Welcome back the latest issue of Week in Core, covering changes [36671-36541]. Here are the highlights:

  • 131 commits
  • 82 contributors
  • 89 tickets created
  • 9 tickets reopened
  • 140 tickets closed

Ticket numbers based on trac timeline for the period above.

Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

Code Changes


  • Improve the color contrast ratio for the input placeholders. [36619] #35777
  • Remove title attributes from the Plugin details modal. [36618] #35111
  • Remove the revisions limit warning from the Publish box. [36612] #35029
  • Fix displaying of Universal time and Local time info on the General Settings screen. [36585] #35064
  • Improve color contrast updating any #999 gray used for text or icons to a darker gray. [36587] #35660
  • Accessibility: after [36000] conditionally print out the aria-describedby attribute on the Featured Image postbox. [36584] #35076
  • Accessibility: Reduce the WordPress shades of grey, Episode 2. [36582] #35783


  • Replace the custom comment form with comment_form() and reduce number of links. [36595] #35888
  • Remove extra spaces between function names and brackets [36572] #16774, #34365
  • Remove slashes from search terms and use urldecode() in non-URL contexts. [36560] #35712


  • Allow users to log in using their email address. [36617] #9568


  • Do not strip slashes from the whole &_POST when doing autosaves. [36543] #35408


Build/Test Tools


  • Rename $linea to $remote_source for clarity. Add remote_source to comment data, so it’s available to preprocess_comment and comment_post filters. Pass the original (unfiltered) response source to the filters too (as remote_source_original in comment data). [36661] #34141
  • Pass comment data to the comment_post filter. [36660] #34141
  • Look for wp_error when checking whether $wpdb->get_col_length() has failed. [36542] #10377
  • Refresh the Moderate Comment screen for a friendlier experience with email moderation actions. [36588] #34133


  • Let WP_Customize_Selective_Refresh class be final to match manager and other component classes. [36624] #27355
  • Ensure dynamic_sidebar() finishes with removing the sidebar ID from the current_dynamic_sidebar_id_stack. [36623] #27355
  • Prevent dropping backslashes from input on general settings and settings for nav menus and some widgets. [36622] #35898
  • Fix and extend broken ajax unit tests to account for partials being skipped from rendering. [36650] #35914
  • Skip exporting partials to client and handling rendering requests if user can’t modify associated settings. [36643] #27355, #35914
  • Add visual feedback to reorder buttons. [36641] #35041
  • Contain “No image set/selected” in dashed border. [36639] #35826
  • Update unit test for WP_Customize_Nav_Menu_Item_Setting::value_as_wp_post_nav_menu_item() to account for slashing if user can’t unfiltered_html. [36610] #35869
  • Prevent PHP notice and JS error caused by widgets and nav menus components if user only has customize capability. [36611] #35895
  • Fix previewing and updating of nav menu items containing slashed/slashable characters. [36608] #35869
  • Fix “Loading…” message from persisting in panel title when user does not have manage_options cap to edit blogname. [36606] #35579
  • Add selective refresh framework with implementation for widgets and re-implementation for nav menus. [36586] #27355
  • Prevent consecutive refresh requests from preview from causing JS error. [36583] #27355, #35866
  • In nav menus show the location name instead of slug. [36573] #34755
  • Add missing test changes for [36573]. [36574] #34755
  • Autoprefixer for [36532]. [36548] #31195


  • Correct $number type in number_format_i18n(). [36644] #35893
  • Update the type for $callback parameters to callable in DocBlocks for add_settings_section() and add_settings_field(). [36642] #35772
  • Improve documentation for WP_REST_Request to highlight a caveat of ArrayAccess when it comes to passing similar arguments for multiple request methods. [36636] #35799
  • Improve description of get_term() return value. [36634] #35919
  • Correct param types on some filters in wp_filter_comment(). [36626] #35908
  • WP_Meta_Query accepts ‘EXISTS’ or ‘NOT EXISTS’ for $compare. [36609] #35891
  • Fix two incorrect notations of the $show_admin_bar global to specify a boolean type, not WP_Admin_Bar. [36601] #35686
  • Add missing since and access tags to get_curies method and filter from r36533 [36593] #34729, #32246
  • Add an explanation for the dynamic portion of the {$taxonomy}_term_edit_form_top hook, introduced in [36526]. [36577] #32246
  • Add formatting to a changelog entry in the hook doc for the rest_dispatch_request filter. [36576] #32246
  • Remove a duplicate @static tag from the WP_Customize_Panel->instance_count property DocBlock. [36568] #32246


  • Only display an iframe when it was successfully loaded. This prevents showing a blank iframe by first checking if a message was successfully received from it. [36648] #35894
  • Make the click event handler work for dynamically added links. [36637] #35630
  • Load the default site icon from the wp-includes directory. [36635] #35322

External Libraries

  • Update Backbone and Underscore to the latest versions. [36546] #34350



  • Avoid a PHP warning when wptexturize() is called with a trailing less-than symbol. [36578] #35864



  • Certificate bundle: Attempt to move a certificate lower in the file to allow older OpenSSL versions to parse it & communicate with WordPress.org securely again. The OpenSSL version which was failing in this case was OpenSSL 0.9.8e 23 Feb 2007. [36570] #35637, #30434, #25007


  • Add translator comments and context to “New Site Created” email notification strings. [36669] #35716
  • Replace hardcoded URL in a translatable string with a placeholder in wp-admin/upload.php. [36668] #35743
  • Add missing periods to two strings in wp-admin/network/sites.php [36664] #35720
  • Add translators comments to wp-admin/users.php. [36621] #35885
  • Remove HTML tags from translatable strings in wp-admin/plugins.php. [36662] #35679
  • Add the ability to parse a whole directory with add-textdomain.php. [36600] #35499
  • Remove PHP4 constructor from add-textdomain.php. [36599] #31982
  • Add test for wp_dropdown_languages(). [36631] #35294
  • Respect the coding standards when adding textdomains with add-textdomain.php. [36603] #21616
  • Remove tag from translatable string in wp-admin/includes/class-wp-filesystem-ssh2.php. [36670] #35741
  • Remove tag from translatable string in wp-admin/includes/class-wp-ms-sites-list-table.php. [36663] #35676
  • Remove tag from translatable string in wp-admin/theme-install.php. [36666] #35739
  • Remove tag from translatable string in wp-admin/options-general.php[36656] #35673
  • Remove tags from translatable strings in wp-admin/install.php. [36665] #35738
  • Remove tags from translatable strings in wp-admin/custom-header.php[36658] #35675
  • Remove tags from translatable strings in wp-admin/themes.php. [36657] #35745
  • Remove tag from translatable string in wp-admin/user-edit.php[36655] #35672
  • Remove tag from translatable string in wp-admin/import.php[36653] #35671



  • Ensure backslashes are saved in menu item fields. [36613] #14134


  • Make view mode sticky for network users and sites list tables. [36562] #34365
  • Avoid a PHP Notice when saving a site address without a path. [36561] #35631


  • In wp_upload_dir() do not cache error from wp_mkdir_p() when a directory cannot be created. Keep trying to create the dirs. This happens mostly in file upload context. [36628] #34359
  • Replace wp_upload_dir() with the new wp_get_upload_dir() in all cases where a file is not being uploaded. Deprecate _wp_upload_dir_baseurl(), and replace it with wp_get_upload_dir(). [36569] #34359
  • Reintroduce term meta unit test accidentally removed in [36566]. [36567]
  • More performance improvements to metadata lazyloading. [36566] #35816
  • Improve the performance of wp_upload_dir(): [36565] #34359



  • Introduce get_post_types_by_support(). Similar to get_post_types(), this new function returns a list of post type names that support a specific feature. [36652] #34010
  • Non-trashed posts should take slug priority over trashed posts. [36607] #11863


  • Search should match post_excerpt in addition to title and content. When ordering search results, exact matches in the post excerpt are weighted above those in post content, but below those in the post title. [36647] #35762
  • Allow a seed value to be passed when using ‘rand’ $orderby. [36632] #35692
  • In WP::handle_404() introduce a filter pre_handle_404 to short-circuit default header status handling. [36629] #10722
  • is_*( $int ) should not falsely match strings starting with “$int”. [36625] #24674, #35902



Script Loader

  • Don’t parse $src if the current color scheme isn’t registered. [36591] #35882
  • Pass the media attribute as an argument to the style_loader_tag filter. [36592] #34765
  • Bail if WP_Styles::_css_href() returns an empty value. [36590] #35229
  • Make sure that inline styles for handles without a source are printed. [36550] #35229
  • JSHint for [36602]. [36605] #33301
  • Fix missing script output when the groups of dependencies are different. [36604] #35873
  • Introduce wp_add_inline_script(). [36633] #14853
  • Restore loading order for wp-admin: open-sans, dashicons, etc. [36551] #35229


  • Clarify the allowed values for the $media parameter of wp_register_style()/wp_enqueue_style(). [36649] #35921


  • Make $taxonomy parameter optional in get_edit_term_link(). [36646] #35922
  • Allow get_terms() to fetch terms regardless of taxonomy. [36614] #35495
  • In get_terms(), assemble WHERE conditions in an array instead of concatenating. [36598] #35495
  • Add changelog entry for publicly_queryable argument in register_taxonomy(). [36564] #34491





  • Pass locales of all available languages to the themes/plugins update API. [36630] #34937


  • Prevent further actions if an update button is disabled. [36558] #35257
  • Add a hook to the end of the network’s Add New User form. [36556] #15389
  • Add a hook to the end of the Add Site form. [36555] #34739
  • Enhance the language of the “Success” message. [36553] #34897
  • Improve wording on the page for the database connection details. [36545] #26879
  • Use “Username” instead of “User Name”. [36544] #35850


  • Pass the array of user IDs being deleted to the delete_user_form action hook in two places. [36640] #35063
  • Introduce _wp_get_current_user() for improved backward compatibility. [36651] #19615


  • Avoid a PHP notice in is_dynamic_sidebar() is a sidebar is registered but does not yet have an index in the sidebars_widgets option. [36667] #35928


Thanks to @dnewton,@joemcgill, @abiralneupane, @adamsilverstein, @afercia, @aidanlane, @Ankit, @apaliku, @atimmer, @azaozz, @barryceelen, @boonebgorges, @charlestonsw, @chris_dev, @ckoerner, @coffee2code, @coreymcollins, @danielbachhuber, @dd32, @Denis-de-Bernardy, @dlh, @DrewAPicture, @dshanske, @ericlewis, @ethitter, @flixos90, @GaryJ, @gitlost, @groovecoder, @Gupta, @hakre, @helen, @hlashbrooke, @iamntz, @igmoweb, @iseulde, @JamesDiGioia, @jdgrimes, @jeremyfelt, @JoeFusco, @joehoyle, @johnbillion, @jorbin, @K, @karmatosed, @kjbenk, @kovshenin, @lpawlik, @mayukojpn, @mdgl, @meitar, @melchoyce, @MikeHansenMe, @mikejolley, @mikeschroder, @netweb, @nicd, @ocean90, @pento, @prettyboymp, @ptahdunbar, @rachelbaker, @ramiy, @realloc, @ryan, @ryankienstra, @salcode, @sc0ttkclark, @sebastianpisula, @SergeyBiryukov, @stevegrunwell, @stevenkword, @swissspidy, @thewanderingbrit, @thisisit, @usermrpapa, @valendesigns, @vhomenko, @welcher, @westonruter, @williamsba1, and @wpsmith for their contributions! for their contributions!

#4-5, #week-in-core

Feature Plugin chat notes for Jan 26


  • Review the feature plugins for status updates from leads
  • Open floor for feature plugin proposal

Feature Plugin Updates

  • Background Image Cropper: @celloexpressions asked for feedback for the Background Image Cropper. Current thinking is this is better explored as a standard enhancement for core. See #32403.
  • Customizer: @westonruter left status on the blog post for the Customize Pane Resizer, Customize Device preview (along with @celloexpressions), Selective Refresh, and Transactions. Please comment there if you’re interested in helping out where needed (especially requested for the Pane Resizer).
  • Fields API: @sc0ttkclark updated: term add/edit is in: props @technosailor. Team has been working on simplifying the code required for each screen implementing the Fields API. Scott posted an update on make/core and reports getting lots of feedback (especially from @helen, @drew, @technosailor & @celloexpressions)
  • Shiny Updates:  @obenland updated – Lots of progress in the last week. @ipstenu helped tremendously in getting it multisite compliant. Team decided to not pursue shiny activations/deactivations for a whole set of reasons, mostly around redirects on subsequent page loads, and fatal error protection.
    Currently working on enabling theme updates without having to open the modal, and revamping update-core.php.  An update will be posted to the make/core blog soon. The team needs more feedback and testing! Testers can get the current plugin from the wordpress.org repository.
  • WP-API: @danielbachhuber updated – released beta 11 yesterday. The team is meeting in person (minus @rachelbaker) this week at A Day of REST. Summary: in the home stretch, but there’s a ton more work to do. Friday’s contributor day (at the Day of REST) will hopefully get other people diving in and contributing to the final push.

Open Floor

The full logs are available on Slack.


WP REST API: Merge Proposal

Hello everyone! This is the post you’ve all been waiting for. 🙂

We on the REST API team (myself, @rachelbaker, @joehoyle, @danielbachhuber, and newest member and core committer @pento) would like to propose merging the REST API into WordPress core. We’ve been working a while on this, and think it’s now ready to get your feedback.

This is our first iteration of the proposal, and we’re actively looking for feedback. If you have thoughts on the project, or on this proposal, let us know! Only with your feedback can we make progress. 🙂

What is the REST API?

The REST API is a nice and easy way to get at your data in WordPress externally, whether that’s from JavaScript in a theme or plugin, mobile and desktop applications, or importing and exporting data. The API offers up all core data types (posts, terms comments, and users), plus support for meta and revisions; we’ve got plans to eventually have access to everything the admin and frontend have access to.

The REST API differs from existing WordPress APIs in that it is explicitly designed from the ground up for modern mobile and browser usage, using the lightweight and widely-supported JSON data serialization format with a modern REST interface. Both of these are already familiar to most developers: JSON is a subset of JavaScript intended purely as a data interchange format, and REST is a set of best practices around HTTP. Both are supported natively by almost every programming language and platform.

Why do we need a new API?

WordPress already has external APIs: XML-RPC, designed for desktop clients; Atom and RSS feeds, designed for post syndication; and the venerable admin-ajax, designed for Ajax requests in the admin and frontend. These APIs all serve different purposes, but often have a great deal of overlap. In addition, these have all been stretched beyond their original intentions: XML-RPC now contains site management tools, RSS has been extended into the WXR export format, and admin-ajax is the catch-all of any sort of browser-server communication in plugins and themes.

The REST API builds upon the heritage of these APIs to provide better support today for using these, as well as laying the groundwork for expanded use in the future.

XML-RPC is the closest analogue to the REST API in terms of usage and capabilities. Originally designed back in 1998 to allow desktop clients to create and edit posts on blogs, WordPress has extended this with both other specifications (such as MetaWeblog) and with its own proprietary additions. Fundamentally, XML-RPC is built around Remote Procedure Calls (RPC), essentially a way of calling a function externally. It then uses XML to serialize the data for passing back and forth.

Unfortunately, XML serialization can be problematic at times. XML has lots of power, but support for custom entities and DOCTYPEs can cause parsing problems and security attacks, including billion laughs, and XXE exploits. (Currently, WordPress has to disable parts of the XML parser and apply regular expression replacements to be able to parse these safely.) XML is also very verbose, and represents data in a way which doesn’t map easily to programmatic data structures. JSON on the other hand is both concise and well-represented in memory, as it’s based on JavaScript’s native syntax.

The admin-ajax API is also very commonly used in WordPress, albeit typically only by plugins and themes. This is a very lightweight API that essentially acts as a mini-router. Typical usage of this API uses JSON, since it’s a browser-based API, but all usage is completely custom. A lot of the usage of this involves retrieving or updating posts on-the-fly, but due to its nature as simply a framework, these are done in completely different ways. This doesn’t lead itself to extensibility, and requires a lot of duplication every time developers want to get data in or out. We don’t want to replace all of admin-ajax though, since some use cases don’t map exactly: UI-related interactions or things like the Heartbeat API are great examples of this.

The REST API can help to supplant these uses. Our aim is to eventually replace the XML-RPC API completely, to act as a secondary import/export format, and to replace most (but not all) uses of admin-ajax. The REST API offers an easier to use interface than the existing solutions.

Why this project?

We’ve been working on this project ever since the first WordPress Contributor Summit back in 2012. Since then, we’ve had lots of feedback from core developers, the community at large, and further beyond in the form of client developers. We believe that the REST API has an immense amount of experience behind it, and plenty of viewpoints have contributed to the project’s direction.

The API has seen great usage in the community, from various mobile apps to large news sites. This usage has helped to battle-test and prove out the API. In the process, we’ve found plenty of bugs, and some security issues. Thanks to this feedback, the API is incredibly stable and secure. (The most recent security bugs we fixed were relatively minor bugs.)

We also designed the API from the ground-up to be part of core, following a core-like mentality to our processes. The API is intended to be both a great feature and a base to build off in plugins. We undertook a significant refactoring and partial rewrite in version 2 to make this extensibility even better. This open process also means that most of the design decisions are documented publicly as we’ve engaged stakeholders to gauge feedback.

We believe these pieces combined make this a fantastic feature for WordPress core, and we hope you all agree. 🙂

What’s the plan?

The plan we’re aiming for is a two part merge of the API. For the first stage, the infrastructure code would be merged into wp-includes and made available for plugins and themes. This is an internal API only, but offers an “API construction kit” for developers to use. For the second stage, the endpoints would be merged, and the API would be enabled for sites by default.

This plan splits the API into two parts, infrastructure and endpoints:

  • Stage One: Infrastructure: The infrastructure is the code responsible for routing requests and handling the “meta” layer of the API, including JSON serialisation/deserialisation, linking, embedding, and REST best practices. This adds a simplified routing layer outside of WP’s rewrites, allowing non-query-var rewrites easily, acting as a base for building APIs inside WordPress.
  • Stage Two: Endpoints: These are where much of the complexity of the API lies, as they’re responsible for mapping data from the external JSON format to the internal data structures, and vice versa. The “business” logic of integrating with WordPress is almost entirely contained within the endpoints. These are the more complex part of the API, as they require using deep APIs in WordPress, and handling security and privacy concerns.

With this plan, we would aim to have the infrastructure merged in 4.4, and the endpoints merged one release later in 4.5.

The slow nature of this plan allows a longer review time on the API for core committers. It also gives extra time for reviewing the endpoints, since they would be delayed one release.

Merging the infrastructure now would allow third-party code to begin using the API to build upon it, including migrating from existing custom code. It would also help to increase developer confidence in the API (as it represents a commitment by the project towards a REST API).

In this plan, the first stage would not include any of the base controllers (such as the posts controller). This may limit the utility of the infrastructure for plugins and themes, however as the endpoints would be merged a cycle later, it’s expected that this wouldn’t have a huge impact.

The infrastructure of the API is approximately 2700 lines of code (roughly a third of the API codebase), and the endpoints make up the remaining 5500 lines of code.

What would happen after merge?

After merging the REST API into core, we’d spend approximately two weeks partying and celebrating. 🙂

Once we’re done with the parties, one major question would be how we manage the API in the future. The existing management and contribution process via GitHub has been extremely successful, as we’ve had 61 people’s pull requests merged into the API. Contribution via GitHub is especially useful for the API, as it’s a heavily developer-focussed project, and is aimed at external (non-WordPress) developers. On the other hand, all other contribution to WordPress is done via SVN and Trac, so integrating with this process is important for existing developers, as well as core’s general processes. We need to ensure the API is an integral part of core, not a separate project.

Given the team’s experience with GitHub as well as Trac, we can bring the best of both worlds by helping integrate the two. This would also improve contribution for WordPress as a whole, and benefit the whole community. This will be especially important as we encourage more contributions from the wider community (client authors, for example). We think we can make good progress here, and we’d love to try and help improve the process. 🙂

In addition to the project management, there are still further API projects we need to tackle. Authentication is the most important of these, as a huge focus on OAuth and similar would be needed to make the API more useful for external clients. Currently, we haven’t had enough time to spend on this as well as managing the API project, however the API is now reaching a finalised stage, so this should be able to improve quickly. Centralised authentication is a huge part of this, as the regular OAuth registration process is cumbersome for a distributed system like WordPress.

Important note: We don’t believe authentication is required for the API merge, and we treat it as a separate project. The authentication is a completely separate system to the API itself. This is something we’d give more time to in the future, but we want to focus on shipping the API for now.

Let’s go!

This is our merge plan for the API, however it’s not finalised. If you’ve got comments, thoughts, suggestions, opinions, or words of encouragement, let us know. We’d love to know what you think. Thank you all, you’re wonderful, and stay golden.

#feature-plugins, #json-api, #merge, #proposal, #rest-api

Trust, Live Preview, and Menus in the Customizer

One of the most important things in WordPress is users being able to feel confident as they make changes to their content and more generally to their sites. Being able to make non-destructive changes and preview them is an important component of building that trust. This is perhaps most noticeable in the “save and surprise” approach of the widgets admin screen – every time you add a new widget, modify its settings, or move one around, the changes are saved and appear live on your site, even if you’re not ready yet. The customizer is our framework for live previewing changes. We are committed to providing live preview for all aspects of site customization and making it usable on all devices from phones to large screens.

The customizer is the result of a tremendous amount of work over many releases. It was first introduced in 3.4. In 3.9, it received its first big updates in the form of widgets support and improved header upload and cropping. 4.0 brought panels and contextual controls. Development really started to take off in 4.1 when JS-templated customizer controls and a JS api were introduced, making possible an ecosystem of live preview compatible plugins and themes. 4.2 followed that up with two important features, theme switching and mobile support.

That brings us to today and the ongoing 4.3 development effort. Revamped navigation for the customizer is already in trunk and the nighty builds. The menu customizer feature plugin is a merge candidate for 4.3 and could land soon. These marquee features further our commitment to live preview and need all of the attention we can muster.

The customizer has come a long way, but it still lacks some features and needs time to mature. We have many improvements planned and in-progress, including transactions, partial refresh, theme installation, speedier loading, scaling to large screens, and possibly even integration with front end editing. Our live preview framework offers many possibilities.

Meanwhile, the Appearance screens will remain and will be maintained. Appearance > Menus recently received some attention in the form of a few fixes. More attention is needed and will be given. There are still differences in the flows each approach best enables, whether it’s new site/theme setup, small maintenance tasks, or dedicated content managers for heavy usage of widgets, menus, or other pieces of content that benefit from having a preview mechanism. We should gather quantifiable metrics when it comes to performance and time to completion for a given flow, as well as evaluating the less-objectively-quantifiable perceived performance. There may come a time where the worlds converge; however, that time is not now.

The feature plugin merge window is currently scheduled for June 17th. We have 8 days to get the Menu Customizer plugin ready for merge. Feature plugins must meet several criteria to be considered for inclusion in a release. To meet this criteria, the flow team has started testing and documenting flow and visuals for the menu customizer as well as the recently landed navigation changes. Merge criteria include identifying flows through the customizer, creating visual records of those flows, and creating flow comparisons of existing flow through Appearance > Menus versus flow through the customizer. This is a great and necessary way to contribute that requires no coding. All you need to do is take screenshots and publish them as a captioned gallery using the tool we’re making together, WordPress. We endeavor to be an Alan Lomax of flow, capturing and cataloging real user scenarios. Please help us capture the flows through Appearance > Menus used by you and your clients. We need this information to ensure our new interfaces are mindful and aware of how WordPress is actually used. Information on how to test and contribute visual records is available on the 4.3 development tracking page.

@ryan, @helen, @designsimply


#customize, #live-preview, #menus, #preview

WordPress 4.3 Kickoff

First I’d like to thank @drewapicture for his outstanding work in 4.2! I was particularly impressed with his ability to keep meetings on track and in time, I’ll work on making sure that won’t change going forward. 🙂 A lot of the structure and artifacts he put in place have been proven quiet successful and I’d like to continue that, so you shouldn’t see too much change in that regard either.

Release Date

We’re aiming to release on Tuesday, August 18th. The 4.3 schedule is live and can be found here: https://make.wordpress.org/core/version-4-3-project-schedule/

Deadlines are not arbitrary, and with your help I fully intend to get this version shipped comfortably on the 18th. Past releases have been quite good about releasing on time, let’s make that a signature trait of the WordPress project!


WordPress 4.3 will be all about enabling users of touch and small-screen devices. @ryan has been testing flows on a myriad of different devices the past few releases and uncovered many things that desperately need attention.

@joedolson has published a post over on make/accessibility about a11y priorities.

If you see anything that sparks your interest feel free to leave a comment here and attend the kickoff meeting tomorrow, when we go through the list of things that were suggested. Specifically, Admin UI can will need a lot of hands. The meeting will also be a good time to suggest additional areas that you want to work on.


We’ll kick 4.3 off with a 2-hour meeting in #core at the usual time, April 29, 20:00 UTC.

#4-3, #agenda, #meeting

Mobile make-flow update

Only two make-flow tickets have been fixed during 4.2. Here’s where we’re at.

List tables

We have some patches which attempt hiding columns on small screens, but that approach is unsatisfying. A single column approach feels better. Perhaps we could get some one column designs for media and tags and go from there.

#29993 – Media action links are cramped on small screens
#29992 – Cramped tag action links on small screens
#29991 – Comment action links are quite cramped on small screens
#29995 – Username is cut off on the user list table on small screens
#29994 – Border bug on empty list tables on small screens

Admin Menu

#31187 – Allow swiping the admin menu open and closed on touch devices

There’s a patch that tests well on everything we’ve thrown at it so far except a OnePlus One phone. I think that’s the only hold up. Can anyone give that a look?

#29906 – Submenus can’t be dismissed on mobile.

The patch here works well for me. It needs code review. There’s one more issue to address regarding admin bar menu behavior.


#29989 – Hide Media Buttons on small screens

This has lost all momentum. Unless a dev adopts it, this one won’t see 4.2. A big bummer.


#31159 – Kitchen sink should be hidden by default on small screens

I think always collapsing the kitchen sink on mobile is fine for now, but preserving interface state separately for mobile and desktop merits future discussion. There are no patches yet for this ticket.

#31161 – TinyMCE Help button is irrelevant on devices without keyboards

I’m down with removing the help button on mobile. Needs a patch.

Modal scrolling

Scrolling behind modals is a persistent problem for us. We need a holistic approach instead of the slow motion wac-a-mole we’ve been doing.

#31381 – The theme details modal has scrolling and toolbar problems on iPhone 6 and 6+

31381 has a reviewed patch that is ready for commit. Is this approach applicable elsewhere?


Open make flow tickets:


Dev Chat Agenda, March 4, 2015

Here’s the agenda for Wednesday’s Dev Chat in the #core channel on Slack.

» Beta 1 is one week away, along with the enhancements deadline.

Time/Date: March 4 2015 21:00 UTC:

  1. Feature Updates
    1. Customizer Theme Switcher – @ocean90 / @celloexpressions
    2. Press This – @michael-arestad / @stephdau / @azaozz
    3. Shiny Updates – @pento
    4. Emoji – @pento
  2. Component Updates
    1. Accessibility – @afercia
    2. Mobile – @ryan
  3. Release Schedule Recap
  4. Daylight Saving Time reminder
  5. Open Floor – Looking for dev feedback on a ticket? Use this part of the meeting to let us know!

#4-2, #agenda

Dev Chat Agenda, February 25, 2015

Here’s the agenda for Wednesday’s Dev Chat in the #core channel on Slack.

Time/Date: February 25 2015 21:00 UTC:

  1. Feature Plugins – The Customizer Theme Switcher and Press This were merged into core on Tuesday. Please test and create new tickets for any issues you find
  2. Component Updates
    1. Accessibility – @afercia
    2. Mobile – @ryan
    3. Components – All the news that is news with @nacin
  3. Enhancements Deadline Reminder – Beta 1 is 2 1/2 weeks away. Need to start wrapping up enhancements.
  4. Open Floor – Looking for dev feedback on a ticket? Use this part of the meeting to let us know

#4-2, #agenda

Dev Chat Agenda, February 18, 2015

Here’s the agenda for Wednesday’s Dev Chat in the #core channel on Slack.

Time/Date: February 18 2015 21:00 UTC:

  1. Feature Plugins:
    1. Consider the Customizer Theme Switcher plugin for merge [Proposal] [Plugin]
    2. Consider the Press This Revamp plugin for merge [Proposal] [Plugin]
    3. If you haven’t looked at either of the merge proposals yet, please spend some time today before the meeting. Please comment on those posts if you haven’t already.
  2. Component Updates
    1. Accessibility – @afercia
    2. Mobile – @ryan
  3. 4.3 Release Lead – If you’re interested in leading a future release, it’s time to speak up.
  4. Open Floor – If you have something you’d like to discuss, leave a note in the comments

#4-2, #agenda