WordPress 4.9.9 Minor Release Roadmap

Release Schedule (Tentative) :

Beta : Monday October 22, 2018

Release Candidate : Monday October 29, 2018

Release Date : Monday November 5, 2018

Bug Scrubs:

We will be running bug scrubs across the planet for this release. We will do our best to provide coverage for every time zone, but you can expect to see one in the #core channel weekly. We will share the schedule soon.


For the 4.9.9, we plan on working on 4 focus areas: Accessibility, Internationalization, Site Health Project, Gutenberg Preparation. Along with these concerted efforts, we want to over-communicate and make sure we get involved with all teams as much as possible.

Key Focuses:

Internationalization (i18n):

We are going to try and bring focus around internationalization. Translations, making sure date/time values work and RTL is supported. More to come as we learn more about the current backlog.

Accessibility (a11y):

We’d also want to focus on fixing issues in accessibility. There’s lots of ways we can drastically improve the experience for a lot of people with minor effort.

Site Health Project (Servehappy) :

We will investigate the work remaining for the Servehappy project and determine how to get it in people’s hands as soon as possible. WSOD protection, update dashboard notice, plugin version requirements are the hot items pending. 

Gutenberg Preparation:

We are collecting the tickets that should be processed for laying the groundwork for the upcoming Gutenberg merge. The tickets that have been proposed by the Gutenberg team so far are:

Communication :

As per usual, we will be regularly communicating details around changes made. For this release, we’d like to aim to over communicate happenings in the release. If there is a commit and you don’t mind us putting you on blast, we’re going to explore ways to publicly celebrate and tell the story of that! This goes especially if the contribution is one of your first!

We will also strive to be more present in component meetings. We will each be attending every component meeting at least once in the release cycle to check in on any things that may be needed for 4.9.9.

One DevChat to rule them all…

From – https://make.wordpress.org/core/weekly-developer-chats/

The weekly WordPress core developer chats take place on Wednesdays at 20:00 UTC in the #core channel on Slack. These chats generally last one hour.

The purpose of the meeting is to discuss core WordPress development. This is a working product team meeting, not an open town hall or Q&A session. The focus is on technical issues and release scheduling, and the players are the people who are working on patches for the active core development cycle. Anyone is welcome to attend to keep up with what’s going on in core, but the agenda is generally limited to discussion by active contributors.

At the moment, one dev chat is held every Wednesday. This often makes it difficult for folks in different time zones to attend dev chat.

Multiple teams hold more than one weekly chat. For example Community has two chats, one at 8:00 UTC and one at 16:00 UTC. While this doesn’t cover every time zone, it does expand the opportunity to join a team chat for contributors close to U.S. and EU time zones.

After 4.9.8, it was suggested a discussion be held around adding an  alternative dev chat. 

During the 4.9.8 release cycle, @pbiron and @joshuawold tried  running two independant bug scrubs, one about 10 hours before the usual one, and one at the usual time. The jury is still out as to whether this was a success or not.

During dev chat on Wednesday, 29 August, and after a discussion with those interested in running a second dev chat, it was proposed to hold an alternative dev chat 12 hours before the current chat.


Some concerns were voiced during dev chat:

  • @karmatosed mentioned this time is during school hours in EU time zones.
  • @clorith and @afercia raised concerns that two meetings could result in a disconnect between the community and present communication obstacles for decision making.
  • @jeffpaul floated the idea of holding three chats, eight hours apart. This approach is more inclusive of global time zones, but requires additional dedicated volunteers to manage the chats and communicate with the other dev chat volunteers.
  • @jorbin feels that decisions should rarely be made during dev chat highlighting the fact that the dev chats be just that, chats about current development cycles, not a time when decisions should be made.
  • @nerrad (and others) echoed the sentiment that “there’s value in clearly identifying in agendas when a item needs a decision and what chat that decision will be made in ahead of time”

The general consensus was that all of this should be shared in a Make post, so that the greater community could comment on it and we could vote publicly on the subject.

Problem: Not all who want to contribute and participate during a devchat are able to because of the timing of the devchat (currently 20:00 UTC).

Questions to guide our designing a solution to the stated problem:

  1. Is one Dev Chat enough or should alternative dev chats be considered to accommodate more time zones?
  2. If there is agreement that alternatives should be considered, what times/intervals are the most suitable for maximum coverage of folks from all corners of the world?
  3. Is there some process that can be implemented to improve the decision making process and therefore either take that requirement out of any proposed dev chat or, alternatively, make it easier to reach decisions in any given dev chat?

This post’s comments will remain open for two weeks to allow for comments and/or suggestions.

Dev Chat Agenda: September 12, 2018 (4.9.9 Week 5)

If prisoners could take their own mug shots, they’d be called cell-fies. 

This is the agenda for the weekly <dev chat> meeting on Wednesday, September 12, 2018 20:00 UTC in #core.

4.9.9 Planning

  • When asked if we had 4.9.9 agenda items Tuesday at 3:39 p.m. CT, @antpb said, “Working on it now!” So I figuratively  👏cannot wait 👏to see what he and @schlessera have in store.
  • UPDATE: We have topics!
    • Tentative Release Schedule
      • Beta
      • RC
      • Release Date
      • Bug Scrubs
    • 4.9.9 Engineering Focus & End Goals

Focus Lead and Component Maintainer Updates

Open Floor / General Announcements

Open Floor tickets

Pssst. You can send these my way and I’ll add them to the list.

  • #12563 New action on body open – Might need to include Theme Review team. 
  • #25280 wp_localize_script unexpectedly converts numbers to strings 
  • #43657 Custom HTML widget editor content not updating after save 
  • #16828 Add filter on initial_meta_boxes for nav menu
  • #32326: Improve Support for Structured Data

General Announcements:

  • Update on potential second <dev chat> 😱

If you have anything to propose to add to the agenda or specific information related to the above, then please leave a comment below. Either way, we look forward to seeing you at the dev chat this week!

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

What’s new in Gutenberg? (12th September)

The release this week, apart from numerous improvements and fixes across the board, includes a new “full screen” mode, and improved mechanisms for styling blocks from a theme perspective. It also exposes the custom post type used to store reusable blocks from the block inserter as a way to manage saved blocks in bulk — an often requested feature. There are plans to expand on the possibilities here so stay tuned for the next series of updates.

Showing Toolbar improvements and Full Screen Mode

It brings news in the data parsing flow as well. Having a formal specification of the Gutenberg block grammar has allowed us both to maintain a stable core during the almost 40 releases of the plugin and lately to allow competing parser implementation to evolve and be compared in terms of performance and correctness. In concrete terms, we are shipping a new default implementation that is hundreds of times faster than the spec and has been stress tested with really long posts (including Moby Dick). These tests are also available for anyone to run against. Memory consumption has also gone down dramatically for server side operations. I’d like to specially thank Dennis Snell and Ivan Enderlin for their great work improving this area.

3.8 🥖

Deprecations removed with this version.

#core-editor, #editor, #gutenberg

WordPress 4.9.8

WordPress 4.9.8 is now available. This maintenance release fixes 46 bugs.

Download WordPress 4.9.8 or visit Dashboard → Updates and click “Update Now”. Sites that support automatic background updates are already beginning to update automatically.

Thank you to everyone who contributed to WordPress 4.9.8:

1naveengiri, Aaron D. Campbell, Aaron Jorbin, Abdullah Ramzan, alejandroxlopez, Allen Snook, Andrea Fercia, Andrew Ozz, Andrew Taylor, Arun, Ayesh Karunaratne, Birgir Erlendsson (birgire), Birgit Pauli-Haack, BjornW, Boone Gorges, Brandon Kraft, Burhan Nasir, Chetan Prajapati, Chris Lema, Corey McKrill, Daniel Bachhuber, Daniel James, David Herrera, Dion Hulse, Dominik Schilling (ocean90), dontstealmyfish, dyrer, Felipe Elia, Felix Arntz, Fernando Claussen, Gareth, Garrett Hyder, Gary Pendergast, Gennady Kovshenin, GM_Alex, Heather Burns, Ian Dunn, ibelanger, imath, Jb Audras, Jeremy Pry, JJJ, Joe McGill, Joen Asmussen, John Blackbourn, Jonathan Desrosiers, Jonny Harris, Josepha, JoshuaWold, Joy, jrf, K. Adam White, khaihong, kjellr, Konstantinos Xenos, laurelfulford, lbenicio, Leander Iversen, leemon, macbookandrew, Marius L. J., Matias Ventura, Mel Choyce, mensmaximus, mermel, metalandcoffee, michelleweber, Milan Dinić, Muhammad Kashif, Naoko Takano, Nathan Johnson, Ov3rfly, palmiak, Paul Biron, Prashant Baldha, PressTigers, programmin, Rafsun Chowdhury, redcastor, Robin Cornett, Sergey Biryukov, Simon Prosser, skoldin, spyderbytes, Subrata Sarkar, Sébastien SERRE, Tammie Lister, tharsheblows, Thomas Patrick Levy, timbowesohft, Timothy Jacobs, Tobias Zimpel, Tor-Bjorn Fjellner, Towhidul Islam, Usman Khalid, warmlaundry, William Earnhardt, Yui, and YuriV.

Primary Focuses

The primary focuses of 4.9.8 are:

  • Introduce “Try Gutenberg” callout
  • Privacy fixes/enhancements

Introduce “Try Gutenberg” callout

Most users will now be presented with a notice in their WordPress dashboard. This “Try Gutenberg” is an opportunity for users to use the Gutenberg block editor before it is released in WordPress 5.0.

You can learn more by reading the “Try Gutenberg” Callout in WordPress 4.9.8 post.  It contains information about the callout, including which users will, by default, be shown the callout and the hooks it provides for site administrators to modify that default behavior.

Privacy fixes/enhancements

This release includes 18 Privacy fixes focused on ensuring consistency and flexibility in the new personal data tools that were added in 4.9.6, including:

  • The type of request being confirmed is now included in the subject line for all privacy confirmation emails.
  • Improved consistency with site name being used for privacy emails in multisite.
  • Pagination for Privacy request admin screens can now be adjusted.
  • Increased the test coverage for several core privacy functions.

In addition to the primary focuses another notable change in 4.9.8 is that developers can now register meta keys for object subtypes:

With WordPress 4.9.8, the register_meta() function supports registration of metadata not only for an entire object type (posts, terms, comments, users), but also for a specific object subtype (such as a specific post type or taxonomy).

4.9.8 Changes

See the full list of closed tickets in Trac.


  • #44611 – try Gutenberg header wraps over text below on narrow screens
  • #44627 – minor tweaks to Try Gutenberg callout formatting

Bundled Theme

  • #44109 – TwentySeventeen backend editor: level 2 bulleted lists nested under numbered lists show numbers instead of bullets
  • #44646 – Bundled Themes: Bump version number and update changelog in Twenty Seventeen for 4.9.8 release


  • #44126 – Adding fields to comments_form args prevents checkbox displaying
  • #44141 – Privacy: Don’t replace comment author URL and email with anything
  • #44342 – Commenter cookie consent message should not be displayed if the cookie action isn’t hooked


  • #44627 – minor tweaks to Try Gutenberg callout formatting


  • #41316 – Introduce “Try Gutenberg” callout
  • #44341 – Replace _deprecated_function( ‘add_filter’ ) with apply_filters_deprecated()
  • #44680 – Restrict the Try Gutenberg callout audience


  • #44339 – minor tweaks to Try Gutenberg callout formatting

Filesystem API

  • #43054 – wp_is_stream fails with stream definition containing nonascii chars


  • #44139 – i18n: “About” disambiguation
  • #44574 – Saratov and other cities missing from translations

Login and Registration

  • #44052 – Missing parameter type for `login_header()`


  • #44532 – Extreme memory leak related to wp_is_stream in wp-includes/functions.php in WordPress 4.9.7
  • #43751 – REST API: Attachments controller should respect “Max upload file size” and “Site upload space” in multisite

Options, Meta APIs

  • #38323 – Reconsider $object_subtype handling in `register_meta()`

Posts, Post Types

  • #36085 – Add action hook to get_inline_data()


  • #44006 – Privacy Policy page should have suffix like other special pages
  • #44025 – Privacy: Pagination screen options for the requests list tables
  • #44099 – Add Request Type into Admin Email Subject for GDPR
  • #44100 – GDPR Privacy Page setting allows for Draft Pages
  • #44130 – Mixed Case of Privacy Policy on Privacy Settings page
  • #44131 – If draft page selected for Privacy Policy page should verbiage change from view to preview
  • #44181 – The input field id username_or_email_to_export should be something else on remove_personal_data page
  • #44192 – Title of Privacy Policy Page not used on login page
  • #44195 – “Silence is golden” index.html generates output
  • #44265 – Add filter for email subject for erasure complete notification
  • #44353 – Replace `site_url( ‘wp-login.php’ )` in `wp_send_user_request()`
  • #44373 – Add a privacy setting to disable comment cookie consent
  • #44379 – GDPR filters should provide either $request or $request_id
  • #44382 – Filter the subject within _wp_privacy_send_request_confirmation_notification
  • #44396 – Inconsistent use of blogname and sitename in Privacy emails
  • #44612 – Grammar – Missing ‘a’ in ‘select new Privacy Policy page’
  • #43967 – Admin emails after email confirmation don’t work for data privacy requests
  • #44590 – Remove “// WPCS:” comments


  • #40861 – REST API saves attachments with absolute path for `_wp_attached_file` on Windows platforms
  • #43874 – REST API: Only render fields specific to request when _fields= is used
  • #44321 – REST API: Expose revision count and last revision ID on Post response


  • #44287 – REST API: Declare user capability to perform actions using JSON Hyper Schema `targetSchema`


  • #42691 – WP_Term_Query get_terms generates invalid sql queries
  • #44096 – REST API: Taxonomy and term endpoints should use correct permission checks


  • #44134 – Update to TinyMCE 4.7.13
    • See the TinyMCE changelog.  WordPress 4.9.6 included TinyMCE 4.7.11, WordPress 4.9.8 updated to TinyMCE 4.8.0, despite the title of this ticket.
  • #44330 – TinyMCE: do not force-load external TinyMCE plugins

Change Log



source file: wp-admin/includes/user.php

source file: wp-admin/includes/misc.php

source file: wp-includes/meta.php

source file: wp-includes/post.php

source file: wp-includes/taxonomy.php

source file: wp-includes/post.php

source file: wp-includes/taxonomy.php

source file: wp-admin/includes/ajax-actions.php

source file: wp-admin/includes/dashboard.php


source file: wp-admin/includes/template.php

source file: wp-includes/capabilities.php

source file: wp-includes/meta.php

source file: wp-includes/meta.php

source file: wp-admin/includes/dashboard.php

source file: wp-admin/index.php

source file: wp-includes/user.php

source file: wp-includes/user.php


source file: wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php

source file: wp-includes/rest-api/fields/class-wp-rest-comment-meta-fields.php

source file: wp-includes/rest-api/fields/class-wp-rest-meta-fields.php

source file: wp-includes/rest-api/fields/class-wp-rest-post-meta-fields.php

source file: wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php

source file: wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php

source file: wp-includes/rest-api/fields/class-wp-rest-term-meta-fields.php

source file: wp-includes/rest-api/fields/class-wp-rest-user-meta-fields.php

source file: wp-includes/class-wp-term-query.php



modification: The $object_subtype parameter was added.
source file: wp-includes/meta.php

modification: The $object_subtype argument was added to the arguments array.
source file: wp-includes/meta.php

modification: The $object_subtype parameter was added.
source file: wp-includes/meta.php

modification: The $object_subtype parameter was added.
source file: wp-includes/meta.php

modification: The $object_subtype parameter was added.
source file: wp-includes/meta.php



alternative: Use auth_{$object_type}_meta_{$meta_key}_for_{$object_subtype} instead.
source file: wp-includes/capabilities.php

#4-9-8, #release

Javascript Chat Summary – August 14

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack transcript).

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

This week we discussed WordPress packages and how to optimize their distribution using npm. As of today, Gutenberg is built of 41 packages where each of them can be used independently by every plugin and theme developer in their projects.

Duplication concerns over independent versioning

Slack Conversation

Problem: An issue was raised about our independent versioning of packages, and how this can lead to duplication which, for packages like data which behave as a singleton, can result in some pretty undesirable outcomes. Related comments on GitHub:


  • This is not specific to @wordpress/data, and could affect anything which behaves in a global / singleton fashion: @wordpress/hooks@wordpress/filters@wordpress/blocks.
  • The issue is mitigated but not eliminated by moving away from Lerna independent versioning (toward fixed versioning) because the chance for differing versions still exists.
  • This shouldn’t be an issue in WordPress context at all. This seems to be an issue for external apps which consume WordPress packages directly from npm.

Decision: Avoid “globals” behavior, where a consumer must define and operate with its own registry (specific to @wordpress/data).

Action items:

How required built-ins should be polyfilled

Slack Conversation

Problem: The current npm packages that being built for Gutenberg polyfill usage of some browser features that are not available on older browsers. This polyfill is global and affects any client who uses WordPress npm packages. This is unexpected and can alter the runtime environment in surprising ways. More details in the related issue.

Decision: corejs flag should be set to false when generating distribution version for packages and set to 2 when bundling with Webpack. In addition, we should inform developers consuming WordPress packages to install proper polyfills on their own.

Guidelines for releases

Slack Conversation

Proposal: We have a documentation proposal to improve guidelines for creating, managing and publishing packages.

Observations: The versioning recommendations are very oriented toward deprecations which seems to be the right approach.

Action item: Add section about managing changelogs based on the discussion from last week.

What’s New in Gutenberg? (31st August)

Our final update for August aims to add further clarity to some core interactions, as well as fixing many issues. Notably, we are expanding on the previously called “Fixed Toolbar” mode — now named Unified Toolbar — as an optional mode for a more traditional writing environment. In our testing, this mode tends to be preferred by more experienced users who don’t mind the disconnect between the tools and the content blocks. There’s also an additional setting which focuses the editing experience on a single block at a time, as well as de-emphasizing some of the block boundaries. These tools can be combined at will to better suit personal preferences and creative workflows.

There are many improvements to individual blocks, conversions, templates, and interactions. We want to say thank you again to everyone who is engaging, raising concerns or making suggestions, and collaborating in making the project better with each release.

Updates to the Block Switcher Menu

3.7 🛵

Mobile Native



Deprecations removed with this version.

Dev Chat Summary: September 05, 2018 (4.9.9 week 4)

This post summarizes the weekly dev chat meeting held Wednesday, September 05, 2018, 20:00 UTC, including topic updates from the lively August 29 dev chat. Agenda | Slack Archive

4.9.9 Updates & Planning

Release Leads

  • After a lively discussion about the ideology of the leadership structure for minor releases during the August 29 dev chat, and following through on our effort to develop a broader group of people who can lead releases, @antpb and @schlessera will serve as co-leads for 4.9.9. @sergeybiryukov will assist with commits. There were 21 emoji reactions to this message in Slack, so it’s official. No takesies backsies.
  • A tentative schedule will be announced once release leads can align schedules for the next 6-8 weeks.

4.9.9 Inclusions

@youknowriad mentioned it would be lovely for these two REST API issues to land in 4.9.9:

  • #44862: Create REST API endpoints to lock, release and takeover post edition
  • #44758: The REST API is not respecting the user’s locale properly 

If you have other issues you’d like to see in 4.9.9, come on over to next week’s chat. We’ll keep the lights on for ya.

Focus Lead & Component Maintainer Updates


  • We’ve got a 3.7 release! This version includes clarifications for some core interactions, expanding the Unified Toolbar mode, squashing Gutenbugs and SO. MUCH. MORE. 
  • Please continue to provide us with feedback via testing and block usage. 
  • I personally appreciate any and all Gutenberg puns. Thanks in advance!


The fab JS team posted notes from their weekly chat. Thanks @matveb for posting the recap! Highlights:

  • Deprecation strategy
  • Allow building in `src`
  • Guidelines for including WP packages

General Announcements

A second dev chat? 

  • During the August 29 dev chat, we notified the channel that we had volunteers to host a second dev chat at a different time on Wednesdays. The goal of having a second dev chat is to see if expanding dev chat across another set of time zones would be more inclusive of the non-U.S. based WordPressers.
  • Following a lively discussion, those who volunteered to lead the second chat are drafting a proposal that is still a WIP. We’ll open up the discussion again during next week’s dev chat.

Merge Proposal: Dark Mode

  • @danieltj is here 100% here for our eyeballs with Dark Mode. His merge proposal answers what Dark Mode is and isn’t, especially the big question about why it isn’t a color scheme. You have to click to find out. I’m not spoiling it here.
  • Further testing and feedback is needed, so please help out if you can.


tl;dr – This conversation has moved over to #core-http in Slack and is being self-organized by those involved. And yes we know that channel name is not secure!

  • Chrome stepped their game up when it comes to flagging non-SSL sites, so @westonruter suggested we do the same when encouraging users to enable HTTPS whenever possible. 
  • Some additional resources on this topic:

That’s it! We’ll see you at <dev chat> next week: Wednesday, September 12 20:00 UTC in the #core Slack channel. 

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

Merge Proposal: Dark Mode

Dark Mode

Dark Mode has become a rapidly popular feature to many online tools and services in recent years and it’s about time WordPress joins in on this trend as well. Many websites such as Twitter, YouTube, Reddit and even macOS Mojave, Apple’s newest operating system have adopted this feature as one to help user’s who are looking at screens for long periods of time. Traditionally we’re use to seeing light backgrounds and dark text in a high contrast environment which can be damaging for the eyes.

If you have ever found yourself working on something late at night and having to make adjustments so the bright light doesn’t hurt your eyes so much, you’re in for a treat!

Say good evening to… Dark Mode

Dark Mode transforms the colours of the WordPress dashboard from bright white and grey colours to dark grey and black instead. This means you no longer need to squint or turn down your brightness setting trying to avoid things like headaches and eyestrain.

Whilst Dark Mode is a great way to personalise your setup, there’s a few things that it’s not. These include but is not limited to:

  • It is not a high contrast mode for accessibility needs
  • It is not a new admin colour scheme for WordPress
  • It is not a tool to aid in any health issues you may have (poor vision etc)

Your Questions Answered

1. What is Dark Mode?
Dark Mode is a new option available for each individual user of your WordPress website to change the dashboard style to a darker design, steering away from the classic white and grey design we’re all use to.

2. Why should this be in Core?
WordPress has always made use of lighter colours within the dashboard. Whilst this may be fine for many, some users may find it harder to read text on the page and it gives people the opportunity to experience their settings in a much nicer, and more comfortable design.

3. How would this be maintained in Core?
As this affects the entire WordPress experience in the dashboard, it would require at least a small group of people to actively maintain it as a component and would need continuous input between developers and designers when new features are rolled out.

4. Will this support Gutenberg?
No, Dark Mode supports TinyMCE (not the theme editable areas) but will not support Gutenberg right now. This is something that should be worked on in tandem with the Gutenberg core team. It’s been decided that a merge proposal with Gutenberg support is the most beneficial way forward at the moment. This is partly due to the nature of rapid weekly updates and changes that Gutenberg is facing which would make it difficult to properly maintain at the moment.

5. Which plugins will be supported? / How can plugins support Dark Mode?
Please refer to the plugin compatibility guide on the GitHub repository for more information on this. For most plugins, this will be a case of using an action hook to include the third party plugin’s Dark Mode stylesheet which is triggered when the current user has confirmed they’d like to use Dark Mode.

Currently, the only plugin which is natively supported by the Dark Mode plugin is Gutenberg. This is because Gutenberg is a feature plugin which will become part of the WordPress core and must be supported by default. No other plugins are to be supported at this time. Plugin developers wishing to save themselves time should try to use the default WordPress UI elements as much as possible.

And for the most important and most asked question of all…

6. Why isn’t this a colour scheme?
Admin Colour Schemes, since being added in WordPress 3.x change the colour of the admin toolbar and the side menu within the dashboard. Colour schemes, generally (and should only) change these two elements and nothing else. Dark Mode doesn’t affect either of these two elements. In fact, the sole purpose of Dark Mode is to change the style of the main content area in the dashboard. This means you can have a custom admin colour scheme enabled alongside Dark Mode if you really wanted to.

Testing & Merging

Dark Mode has already been thoroughly tested but should have further testing before merging to ensure that every element is styled just right. As it currently stands, Dark Mode has been designed in a class model which enables it to be placed within core very easily with the use of hooks.

Whilst there may be some changes required to port it over into the core stack, the current files required for it to actually work are only 2. The PHP code to check the user preference and the CSS file containing the styles meaning the task of actually merging could be relatively quick.

If you do find any issues, please report them by opening a new issue on GitHub.

Thank You!

I would like to give a big thank you to everyone who has helped get Dark Mode to where it is today. The development of the the plugin started on the 3rd October 2017. Since then, the plugin has seen contributors of various levels assist in testing, coding and designing the product we have now. Yay for open source communities!

PHP Meeting Recap – July 30th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • It was discussed which types of errors and exceptions to handle in scope of the sandbox mode (see #44458).
  • @schlessera presented a document in which he had prepared comprehensive resources and his suggestions for what to handle.
  • The approach was mostly agreed on, with the addition that the E_USER_ERROR type should also be covered, since many plugins make use of it, some of which are among the most popular ones.
  • The following PHP errors should be treated:
    • E_PARSE
    • E_ERROR
  • Regarding exceptions, only the base Exception and the PHP7 Error exception classes need to be treated, basically as a catch-all.
  • It is not necessary to wrap the try-catch statement catching Error into a PHP7 version check clause, since catch statements do not trigger autoloading since PHP 5.1, so there won’t be an issue on PHP versions below 7.
  • The following exceptions should be caught:
    • Exception
    • Error
  • Something to consider and test with the implementation is whether the shutdown handler plays well with other shutdown handlers possibly registered by plugins.
  • In addition to implementing treatment of the above errors and exceptions, an important item is how to handle multiple broken plugins: In the latest patch, when an error is detected and the plugin is paused, the next request might simply do the same thing if another plugin causes a problem. In case many plugins are affected, this presents a significant UX issue.
  • Therefore a mechanism is needed that detects multiple issues in one go without requiring further user interaction. Redirects and/or AJAX requests are ideas that could be used to accomplish that. @schlessera is going to continue working on that.
  • Due to the project becoming increasingly big, it was decided to proceed work through a pull request against a WordPress fork, to have a better overview of the incremental code changes. GitHub should only be used for the implementation while discussion can stay on Trac. A pull request has been opened for that purpose to which the latest patch has been ported over. Note: In order to test the code, it is only necessary to append a .diff extension to the PR.

Next week’s meeting

  • Next meeting will take place on Monday, August 6th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue discussion on avoiding WSODs in PHP.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #summary