The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Beta : Monday October 22, 2018
Release Candidate : Monday October 29, 2018
Release Date : Monday November 5, 2018
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.
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.
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.
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.
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:
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.
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:
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:
This post’s comments will remain open for two weeks to allow for comments and/or suggestions.
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.
Pssst. You can send these my way and I’ll add them to the list.
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!
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.
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.
hasSelectedInnerBlock did not account for multi-selected innerBlocks. This caused an edge case in Spotlight mode where multiple blocks selected inside a column would appear unfocused.Deprecations removed with this version.
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.
The primary focuses of 4.9.8 are:
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.
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:
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).
See the full list of closed tickets in Trac.
_wp_privacy_requests_screen_options()
source file: wp-admin/includes/user.php
_wp_privacy_settings_filter_draft_page_titles()
source file: wp-admin/includes/misc.php
get_object_subtype()
source file: wp-includes/meta.php
register_post_meta()
source file: wp-includes/post.php
register_term_meta()
source file: wp-includes/taxonomy.php
unregister_post_meta()
source file: wp-includes/post.php
unregister_term_meta()
source file: wp-includes/taxonomy.php
wp_ajax_update_try_gutenberg_panel()
source file: wp-admin/includes/ajax-actions.php
wp_try_gutenberg_panel()
source file: wp-admin/includes/dashboard.php
add_inline_data
source file: wp-admin/includes/template.php
auth_{$object_type}_meta_{$meta_key}_for_{$object_subtype}
source file: wp-includes/capabilities.php
get_object_subtype_{$object_type}
source file: wp-includes/meta.php
sanitize_{$object_type}_meta_{$meta_key}_for_{$object_subtype}
source file: wp-includes/meta.php
try_gutenberg_learn_more_link
source file: wp-admin/includes/dashboard.php
try_gutenberg_panel
source file: wp-admin/index.php
user_erasure_complete_email_subject
source file: wp-includes/user.php
user_request_confirmed_email_subject
source file: wp-includes/user.php
WP_REST_Attachments_Controller::check_upload_size()
source file: wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php
WP_REST_Comment_Meta_Fields::get_meta_subtype()
source file: wp-includes/rest-api/fields/class-wp-rest-comment-meta-fields.php
WP_REST_Meta_Fields::get_meta_subtype()
source file: wp-includes/rest-api/fields/class-wp-rest-meta-fields.php
WP_REST_Post_Meta_Fields::get_meta_subtype()
source file: wp-includes/rest-api/fields/class-wp-rest-post-meta-fields.php
WP_REST_Posts_Controller::get_available_actions()
source file: wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php
WP_REST_Posts_Controller::get_schema_links()
source file: wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php
WP_REST_Term_Meta_Fields::get_meta_subtype()
source file: wp-includes/rest-api/fields/class-wp-rest-term-meta-fields.php
WP_REST_User_Meta_Fields::get_meta_subtype()
source file: wp-includes/rest-api/fields/class-wp-rest-user-meta-fields.php
WP_Term_Query::populate_terms()
source file: wp-includes/class-wp-term-query.php
get_registered_meta_keys()
modification: The $object_subtype parameter was added.
source file: wp-includes/meta.php
register_meta()
modification: The $object_subtype argument was added to the arguments array.
source file: wp-includes/meta.php
registered_meta_key_exists()
modification: The $object_subtype parameter was added.
source file: wp-includes/meta.php
sanitize_meta()
modification: The $object_subtype parameter was added.
source file: wp-includes/meta.php
unregister_meta_key()
modification: The $object_subtype parameter was added.
source file: wp-includes/meta.php
auth_{$object_type}_{$object_subtype}_meta_{$meta_key}unregister_meta_key()
alternative: Use auth_{$object_type}_meta_{$meta_key}_for_{$object_subtype} instead.
source file: wp-includes/capabilities.php
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.
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:
Discussion:
@wordpress/data, and could affect anything which behaves in a global / singleton fashion: @wordpress/hooks, @wordpress/filters, @wordpress/blocks.Decision: Avoid “globals” behavior, where a consumer must define and operate with its own registry (specific to @wordpress/data).
Action items:
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.
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.
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.
preload attribute in Video Block.doAction when a deprecated feature is encountered.window in data registry.FocusableIframe component URL example.withSafeTimeout in compose.onSetup and getSettings as unstable APIs from RichText.core-data explicit.spec-parser package.stylelint to 9.5.0 and stylelint-config-wordpress to 13.1.0.contentSizeChange on Aztec component.Deprecations removed with this version.
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
@youknowriad mentioned it would be lovely for these two REST API issues to land in 4.9.9:
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.
The fab JS team posted notes from their weekly chat. Thanks @matveb for posting the recap! Highlights:
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!
That’s it! We’ll see you at <dev chat> next week: Wednesday, September 12 20:00 UTC in the #core Slack channel.
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!
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:
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.
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.
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!
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.
E_USER_ERROR type should also be covered, since many plugins make use of it, some of which are among the most popular ones.E_PARSEE_ERRORE_RECOVERABLE_ERRORE_USER_ERRORException and the PHP7 Error exception classes need to be treated, basically as a catch-all.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.ExceptionError.diff extension to the PR.