Max-width captions reverted in 4.9.5

In WordPress 4.9.0 the caption shortcode output was changed to use an inline max-width style instead of width. This change broke several existing themes and has been reverted in trunk and will be in 4.9.5, when released.

For background, the change was added via #33981 and was reverted in #43123.

Any themes that would like to maintain the behavior from 4.9.0 can do so by filtering the output of image captions like this:

function filter_caption_max_width( $output, $tag ) {
    if ( 'caption' === $tag || 'wp_caption' === $tag ) {
        $output = str_replace( 'width:', 'max-width:', $output );

    return $output;

add_filter( 'do_shortcode_tag', 'filter_caption_max_width', 10, 2 );

Dev Chat Summary: March 14th (4.9.5 week 6)

This post is a summary of  the latest dev chat meeting which took place on March 14th (agendaSlack archive).

4.9.5 Planning

Planned release schedule:

  • Beta: 03/20
  • RC: 03/27
  • Expected release date: 04/03

Beta scheduled for next Tuesday, March 20th. Beta release process planned to begin after the weekly bug scrub.

An extra bug scrub is planned on Saturday 17th at 15:00 UTC for 4.9.5 triage.


  • Some 5.0 good-first-bug labelled tickets have been moved back to 4.9.5.
  • All tickets slated in 4.9.5 that are not 100% OK before beta release process will land in future release. @pento added 4.9.6 milestone to handle this.

Release planning: Gutenberg, GDPR, serve happy and other projects

There are a couple items that would be good to ship ahead of Gutenberg's release. How can WordPress best supports getting GDPR updates out ahead of its May deadline? Similarly for other non-Gutenberg projects (e.g., serve happy, debug screen, on-boarding improvements), how can WordPress best supports getting them out ahead of Gutenberg?

Now for Gutenberg, and as discussed last week there are various "Gutentasks" that could use some "Gutenhelp":

  • Various REST API tasks that can be done now in parallel
  • Core changes
  • New endpoints and infrastructure plans
  • How would inclusion of Gutenberg/JS packages work


  • @pento: about GDPR, there may be some smaller things ready for 4.9.5, but it will probably needs a 4.9.6/7 release towards the end of April or early May to add all the bits and pieces.
  • @audrasjb: question about new files or big changes like GDPR in a minor release.
  • @pento: new files can't be added in point releases, as a general rule, but there is no problem adding features (like GDPR) in 4.9.x releases, and there won't be a 4.10 release.
  • @pento: Serve happy needs some polish, but should be ready for 4.9.5. Unfortunately, it was merged to trunk early: There was design feedback on it which wasn't implemented.
  • Discussion about design in WordPress: @pento, @afercia, other contributors & core-committers to talk about design decisions in Trac workflow and in WordPress development in general. This topic will be discussed separately of this dev chat but it seems really fundamental.
  • @Krizzy: question about some good-first-bug tickets status while Gutenberg is being developed. @melchoyce answered if it’s something small and contained, it’s good to push that forward into a point release. And as a reminder, everybody is always welcome to contribute to the discussion, even if the ticket is already marked as "claimed".
  • @aduth: inclusion of Gutenberg/JS packages was a topic of the JS meeting this week. Conversation already started in core-js slack channel.
  • @pento: There have been some small core changes for Gutenberg that have landed in trunk already, mostly REST API tweaks. That process can continue. The larger REST API changes probably won't come until around when the merge proposal comes.
  • @kadamwhite announced REST API meeting is still 17:00 UTC post-daylight-savings, so that's an hour later than last week.


  • @matveb: 2.4 of Gutenberg was released today.
  • @sergeybiryukov: question about the right time for #41316 – Introduce "try Gutenberg" callout –, or still too early.
  • @pento: 4.9.5 release being in 3 weeks is good time for the callout to be added, so it should be kept in the milestone.

Various questions

  • @benoitchantre asked if #36455 should be milestoned for 4.9.5 to prevent OPcache issues to users invited to upgrade their PHP version.
  • @mikeschroder: that particular ticket needs a new patch.

Next meeting

The next meeting will take place on March 21st, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

What’s new in Gutenberg? (14th March)

2.4 π


Continues the work done in previous releases around balancing writing flow with the ability to easily insert non-text blocks.

Writing Flow

Strengthened, tweaked, and polished underlying mechanisms for handling the writing flow in order to provide more stability and consolidation.

  • Move isTyping behaviour to a separate component.
  • Inserting a block should only shift focus to a text field, otherwise focusing the block's "focus stop".
    • Example: Inserting an image should focus the top-level placeholder.
  • Pressing backspace or enter from the block's focus stop should respectively delete or insert a subsequent paragraph block.
    • Example: Pressing enter or delete on an image placeholder.
  • Pressing down arrow from a non-text-field should proceed with a tab transition as expected.
  • Multi-selection at the last text field in a block now accounts for non-contenteditable text fields.
  • Better internal identification of text fields for writing flow transitions. Previously, if a block contained a checkbox, radio, or other non-text input tags, they would be erroneously included in the writing flow sequence.
  • Inserting paragraph block (quote, etc; those with text fields) via autocomplete should move focus to the cursor.
  • Shift-arrow from a text field engages multi-selection, but not if there are other text fields in the intended direction in the same block.
  • Cancel isTyping state when focusing non text field.
  • Improve reliability of the block click-to-clear behavior.
  • When clicking below the editor move focus to last text field — this includes creating a new provisional block if last block is not text. This is equivalent to the default block appender spanning the entire viewport height of the editable canvas.
  • Introduce same undo buffering for general text to the post title (and other post properties).
  • Allow breaking out of List block upon Enter on last empty line.
  • Address conflicts between WritingFlow's selection transitioning and nested blocks by moving selection to the block's focus handler.

Other Changes

Dev Chat Agenda: March 7th (4.9.5 week 5)

This is the agenda for the weekly dev meeting on March 7, 2018 at 21:00 UTC / March 7, 2018 at 21:00 UTC:

  • 4.9.5 planning
  • Definition of what’s included in minor releases
  • Updates from focus leads and component maintainers
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-9-5, #agenda, #core, #dev-chat

Dev Chat Agenda: March 14th (4.9.5 week 6)

This is the agenda for the weekly dev meeting on March 14, 2018 at 21:00 UTC / March 14, 2018 at 21:00 UTC:

  • 4.9.5 planning
  • Release planning (GDPR, serve happy, debug screen, on-boarding improvements, Gutenberg)
  • Contribute with Docs handbook content
  • Updates from focus leads and component maintainers
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-9-5, #agenda, #core, #dev-chat

What’s new in Gutenberg? 2nd March

This release includes significant progress in consolidating the codebase and refining aspects of the experience. Notably, it introduces APIs for extending Gutenberg beyond blocks, allowing plugins to register a full sidebar for their functionality. There are also expansions to the template support (now allows to declare nested structures), ability to duplicate blocks, various design adjustments, etc. Overall the tone has been fine tuning existing elements and simplifying implementations.

2.3 🍇

HTML block, now with syntax highlighting.

Other Changes

High contrast mode in Windows.

WordPress 4.9.1 scheduled for November 29th

WordPress 4.9 has been downloaded over 6 million times since its release two weeks ago.

A small number of bugs have been identified which are impactful enough that the core team has decided to release 4.9.1 with fixes for those issues. The release is scheduled for tomorrow, November 29th, 20:00 UTC. A beta release will be packaged later today and made available for testing.

The issues that have been fixed are:

  • #42573: File caching affecting users’ ability to use the plugin and theme file editors.
  • #42574: MediaElement upgrade causing JS errors when certain languages are in use.
  • #42579: Incorrect logic in extract_from_markers().
  • #42454: Unable to translate Codex URL in theme editor.
  • #42609: Theme editor cannot edit files when running on a Windows server.
  • #42628: flatten_dirlist() doesn’t play nice with folders with numeric names.
  • #42634: DB_HOST socket paths with colons not parsed correctly.
  • #42641: On multisite upgrade the wp_blog_versions table doesn’t get updated
  • #42673: Themes page throws console error when there is only one installed theme.

In addition, one fix for a bug introduced in WordPress 4.7 will be included in 4.9.1:

  • #42242: lang attribute in the admin area doesn’t reflect a user’s language setting.

Stay tuned for the announcement of a beta package.


Proposed roadmap: Tools for GDPR compliance

This is a proposed roadmap for adding privacy tools to core. The plan is to finalize it at the next #gdpr-compliance chat in Slack.

Main goal

Add tools to help site owners comply with the GDPR and other privacy laws and requirements.

Add notices for both registered users and commenters on what data is collected in core by default, and why.

  • Shorter texts in core with links to more information. Needs text.
  • Create these “more information” pages on Needs text.

Create some guidelines for plugins on how to get compliant.

A page (or several pages) on Needs text.

Add tools to core to facilitate compliance, and privacy in general.

There are few plugins that have started implementing these tools, so we have a nice head start.

The requests to see, download and delete/anonymize private data have to be with a confirmation (double opt-in) to avoid misuse. One possible solution would be to send a token by email when a user or a commenter has requested access to or deletion/anonymization of their private data. Then they will have to submit that token as a confirmation of their request.

TBD: shall we make this process automatic or should a site owner perform the action upon receiving the confirmed request?

  • For commenters. The stored private data is emails and IP addresses, the rest is public.
    1. Dialog for requesting to see and download their private data.
      TBD: should that data also contain the public portion?
    2. Dialog for requesting deletion/anonymization of the data.
      TBD: Deletion or anonymization? Or both and let the site owner decide?
    3. Ask for consensus for storing commenter cookies. This can be a (checked) checkbox under the comments form, something like “Save my name, email and site URL in my browser for next time I post a comment. More information”.
  • For registered users. All of the data stored by default is already visible in the user profile (except IP addresses if they have commented on the site), and most can be edited or deleted from there.
    1. Button for downloading their private data, including IP addresses if they have commented. Again, should that also contain the public data?
    2. Button for requesting deletion/anonymization of their account.

Add documentation/help for site owners on how to use these tools.

This should probably be another page under the Tools menu and contain short explanation of what privacy tools are available and how to use them. It could also contain the actual tools, for example an input field for anonymizing commenters by email address.

There are a few things that need clarification:

  • IP addresses may be considered personal data so they need to be deleted or anonymized. However do they need to be sent to the user when requesting to see or download their personal data? They are essentially third-party tokens used temporarily to access the Internet and the users have no control over them. Do other websites make them available?
  • Who are considered “controllers”? All admins on single install and all superadmins on multisite? Are admins on multisite controllers for their own site?

Please post your suggestions in comments so we can finalize the roadmap at the next #gdpr-compliance chat on Wednesday. Thanks @casiepa for helping with this!


Dev Chat Summary: March 7th (4.9.5 week 5)

This post summarizes the dev chat meeting from March 7th (agenda, Slack archive).

4.9.5 planning

  • @audrasjb and @danieltj to lead bug scrubs every Tuesday from 20:00 to 21:00 UTC
  • Planned release schedule:
    • Beta: 03/20
    • RC: 03/27
    • Expected release date: 04/03
  • Looking to move some 5.0 `good-first-bug` labelled tickets to 4.9.5 if they are already committed, self-contained, can be back-ported cleanly before milestoning, and don’t introduce any unintended backcompat issues

Definition of what’s included in minor releases && Gutenberg updates

  • @jbpaul17: Suggestion to expand what can go into minor releases and allow new files to be introduced as this could benefit projects being able to ship in a minor versus waiting for a major release/5.0 (e.g., serve happy, debug screen, on boarding improvements, GDPR compliance tools)
  • @jbpaul17: Question as to cons for doing so (e.g., breaking auto-updates) and whether they’re unsolvable technical problems or historical blockers that haven’t been researched recently and could potentially be resolved
  • Previous discussion on this topic related to inline docs
    • “Every extra file adds a significant amount of KB to the package, which adds up pretty quickly. This not only stretches the load balancers (when suddenly millions of sites are updating within an hour), but also each individual site, which must download the ZIP, which takes time (partial builds made things, on many shared servers, go from minutes to seconds) and introduces lots of possibilities of download failures, and thus sites needing to retry later (and wait longer) to get patched.”
  • Prior comment that although it’s a little inconvenient, it’s a handy line in the sand for backporting to prevent new files
  • @joemcgill: Important to get input from people familiar with and have access to the infrastructure and historical data about releases
  • Side conversation on altering version numbering scheme such that next major could be 4.10.0 and allow non-Gutenberg projects to land in a major release while Gutenberg can still have the 5.0 version number; alternative to switching to semantic versioning is pushing Gutenberg back to 5.1
  • @joemcgill: Important to clarify what we’re trying to solve: trying to release some new features that are blocked while we wait for Gutenberg/5.0. Suggestion: discuss the specific features and why they’re worth including in a minor and figure out the technical blockers to make that happen
  • @xkon: GDPR work is trying to avoid shipping with Gutenberg to ensure user-stress levels are low for these respective updates; in an ideal world GDPR should land before May 25th
  • @joemcgill: Helpful to understand the roadmap for 5.0 timelines to know if we should squeeze something in a minor release or do a vanity 4.9.10 major release
  • @matveb: Gutenberg plan is still tentatively April
  • @peterwilsoncc: Pushing new files into minors would require two releases:
    • 1 to update auto updates
    • 2 to update and include the new files for GDPR, serve happy, etc.
  • @sergey: precedent of adding new functions to existing files in a minor branch where they’re in separate files on trunk, same could apply for GDPR/etc.
  • @joemcgill: restating the problem… We have some features ready for release but are blocked by historical constraints on our minor release process, meanwhile we have no clear sense of when the next major is going to be ready because it’s tied to Gutenberg
    • Option 1: Change the constraints on a minor release and add the features. This needs input from infrastructure people
    • Option 2: Do a major release before Gutenberg is ready if we need to
    • Option 3: Wait for Gutenberg to be ready
  • Gutenberg team looking for more help in getting it ready for the path to merge proposal, getting a promo notice in a release to help increase testing
  • @azaozz: GDPR tools cannot wait very long. Will need to be out end of April, early May the latest
  • Gutenberg work divided into “feature complete”, “merge proposal” (things we definitely need), and “5.0
  • Gutenberg areas that need attention for 5.0 merge:
    • API tasks need owners.
    • All core issues should have corresponding tickets.
    • JS packages integration can be a topic for the core-js chats.
    • Gutenberg repo needs help with triage and fixing bugs.
    • Documentation and coding standard updates.
    • Accessibility needs to be improved
  • Various Gutenberg-related tasks could use help and don’t have to wait for merge proposal:
    • Various REST API tasks that can be done now in parallel
    • Core changes
    • New endpoints and infrastructure plans
    • How would inclusion of Gutenberg/JS packages work
  • Gutenberg team would like to see how integration with truck would work as early as possible, aiming for April for an initial merge/first beta (not actual 5.0 release)
  • Gutenberg team needs more component and lead developers focus and feedback

Next meeting

The next meeting will take place on March 14, 2018 at 21:00 UTC / March 14, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-5, #core, #dev-chat, #gutenberg, #summary

WordPress PHP now (mostly) conforms to WordPress Coding Standards

For 12 long years, the WordPress Coding Standards have stood as a beacon of hope, a promise that code written for WordPress will be easily readable, recognisable, and portable. Sadly, WordPress’ own PHP hasn’t lived up to that promise.

Until now.

Weighing in at a respectable 105,650 lines added, 77,558 lines removed, with an 11MB diff, [42343] fixes 94.8% of the coding standards issues in WordPress’ PHP.

The 5.2%

The remaining 5% of coding standards issues require manual intervention, which means that we’re going to start accepting coding standards patches in the near future. Please hold off on creating tickets and submitting patches for now, while we figure out the best way to manage it.

Existing Patches

Unfortunately, this change means that most patches currently on Trac will no longer apply cleanly – they’re going to need updating. It’s going to take a bit of experimenting to figure out the most efficient way to handle this, if you’re interested in this problem, please go ahead and experiment!

The Wider Ecosystem

In the process of preparing for this, there were a lot of bugs fixed and features implemented in WPCS, as well as upstream in the PHPCS project – this not only benefits the WordPress ecosystem, but the wider PHP ecosystem. Special props to @jrf for driving the bulk of these changes, both in WPCS and PHPCS!