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:
Agenda proposal:
Join us on slack at 15:00 UTC.
Open trac tickets
#gdpr-compliance, #agenda
This is the agenda for the weekly dev meeting on May 23, 2018 at 20:00 UTC / May 23, 2018 at 20:00 UTC:
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!
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.
This update is packed with improvements and fixes. It introduces the Plugin API that allows pinning items for quick access in the editor header. There are many refinements to the UI and consistency of various block tools. Toolbars now expose the keyboard shortcuts used to access most features. It also includes significant improvements around API support — lifting limits to various endpoints, capabilities, conditional UI, etc. Dive into the changes below to find all the details.
per_page=-1 request. Makes sure no users appear missing.wp:action-publish and update corresponding UI to reference it. Use wp:action-publish to determine whether to display publish UI.wp:action-assign-author to indicate if user can assign authors. Fixes issues with author selector not appearing under certain circumstances.withColors. Also solve memoize problems.editorMediaUpload to the editor module.UrlInput autofocus when used in a custom block.targetSchema of JSON Hyper Schema to communicate sticky action.title and modalClass props in MediaUpload.test/integration folder.npm audit.package-lock.json for fsevents.tail-ing the PHP 5.2/3 build logs.%s from Lerna publish message.lerna a dependency rather than a devDependency.build folder to be used by all modules.This post summarizes the dev chat meeting from May 16th (agenda, Slack archive).
The next meeting will take place on May 23, 2018 at 20:00 UTC / May 23, 2018 at 20: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.
Included in WordPress 4.9.6 are several new functions and tools that you should be aware of. Here is a brief breakdown of resources to help you become acquainted with WordPress 4.9.6.
4.9.6 adds several new privacy related features, one of which may require a small styling adjustment. These are detailed in the following dev note.
Changes that Affect Theme Authors in WordPress 4.9.6
WordPress 4.9.6 introduces some new tools related to data privacy. This includes a tool for users to request an export of all the stored data associated with them on the site. It also includes a tool for users to request erasure of that same data. Both tools include admin workflows to fulfill those requests.
To help plugin and theme authors integrate with these new tools, several new pages in the Handbook have been created.
Suggesting text for the site privacy policy
Adding the Personal Data Exporter to Your Plugin
Adding the Personal Data Eraser to Your Plugin
Privacy Related Options, Hooks and Capabilities
To help WordPress Core, plugins, and themes with forward compatibility, a polyfill for each of these functions has been added in 4.9.6. When a site is not running a version of PHP that includes these functions, WordPress will automatically load these polyfills.
New PHP Polyfills in 4.9.6
TinyMCE has been updated from version 4.6.7 to version 4.7.11. This update provides a large number of bug fixes. For more information, see #43862.
A full list of bugs and enhancements in 4.9.6 can be found on Trac.
Update 5/18: Added note about privacy policy management on multisite installs.
Update 5/17: Added details about themes passing the fields argument to comment_form().
In WordPress 4.9.6, several tools were introduced to help sites meet the requirements of the new European Union’s new GDPR (General Data Protection Regulation) laws. This post will detail what theme authors need to know about compatibility with the new features.
Theme authors should test their themes to confirm that there are no design conflicts between the new features and their themes detailed below.
WordPress 4.9.6 introduced the ability to easily select a page as a privacy policy for a site in the Settings > Privacy section of the admin area (#43435). For new sites, a privacy policy template page will automatically be created in draft status (#43491).
To easily link to the selected page in plugins and themes, three template tags have been added (#43850):
get_privacy_policy_url() – Retrieves the URL to the privacy policy page.the_privacy_policy_link() – Displays the privacy policy link with formatting, when applicable.get_the_privacy_policy_link() – Returns the privacy policy link with formatting, when applicable.Note: On multisite installs, only super admins are allowed to manage privacy policies. If one policy is desired for the entire multisite, the `privacy_policy_url` filter can be used to accomplish this. See #43919.
The following example will display the privacy policy link surrounded by a <div>.
if ( function_exists( 'the_privacy_policy_link' ) ) {
the_privacy_policy_link( '<div>', '</div>');
}When a logged out user comments on a post, they are asked for their name, email, and website. This information is stored locally in the commenter’s browser for two purposes:
The information stored in this cookie is for convenience and is not essential. Therefore, the user needs to be given the choice to opt in or opt out of the storage of this data.
For this reason, a checkbox has been added to the comment form that allows commenters to opt-in to storing this data in the cookie. This checkbox will be unchecked by default, as opt-in is an action the user must explicitly approve.
The new checkbox field is automatically added to comment forms displayed using the comment_form() function inside a p.comment-form-cookies-consent element.
While most themes will not require any action, it is recommended that you double check that the new input and label does not require CSS adjustments in custom themes.
For more information on this change, check out #43436 on Trac,
By default, WordPress automatically displays the new checkbox field discussed above. However, if a theme is passing the fields argument to the comment_form() function, the field will not display and needs to be added to the list of fields.
The following example will only display the email field above the comment message field in the comments form.
comment_form(
array(
'fields' => array(
'email' => 'field markup',
),
)
);After updating, the new comment opt-in field will need to be added.
comment_form(
array(
'fields' => array(
'email' => 'field markup',
'cookies' => 'opt-in field markup',
),
)
);The default markup for the field can be found in wp-includes/comment-template.php.
A second option for fixing this would be to utilize the comment_form_default_fields filter instead. Using this filter, default comment fields can be added or removed without having to pass the fields argument to the function.
All 8 currently supported bundled themes (Twenty Ten-Twenty Seventeen) have been updated to support these changes. Site footers will display a link to the site’s privacy policy when one has been selected (#43715), and the commenter cookie opt-in field has been styled.
Child themes built on top of bundled themes should be checked to see if any adjustments are necessary for the privacy policy link in the footer.
It is considered good practice to validate variables before using them. As using type declarations is still very rare in the WordPress world, parameters passed in to functions may not be of the variable type expected. Similarly, the type of variable returned by a filter may have changed due to incorrect usage of the filter by plugins or themes.
One particular situation which causes bugs often is counting something which isn’t countable. Proper variable validation can prevent those bugs.
In PHP 7.2, a warning was introduced when count() is used on an uncountable value. PHP 7.3 will introduce the function is_countable(), which will help prevent this warning by checking that the passed variable is actually countable (the RFC has passed the vote and the function has already been implemented and merged into PHP Core).
Using count() to detect if a value is iterable (able to be passed to a foreach() loop, for example), is also a common practice. However, this will also result in warnings when upgrading to PHP 7.2. In PHP 7.1, the is_iterable() function was introduced to help prevent these warnings.
To help WordPress Core, plugins, and themes be forwards compatible, a polyfill for each of these functions has been added in 4.9.6. When a site is not running a version of PHP that includes these functions, WordPress will automatically load these polyfills.
is_countable() was introduced in #43583.
if ( count( $var ) > 0 ) {
// Do something.
}if ( is_countable( $var ) && count( $var ) > 0 ) {
// Do something.
}is_iterable() was introduced in #43619.
if ( count( $var ) > 0 ) {
foreach( $var as $key => $value) {
// Do something.
}
}if ( is_iterable( $var ) ) {
foreach( $var as $key => $value) {
// Do something.
}
}New tickets should be opened on Trac for instances in Core that would benefit from these new functions on a case by case basis. Since all instances of count() and foreach() should be verified, a meta ticket has been opened to keep track of which files have been checked (#44123).
To better understand how variables behave in various PHP versions, how to write better conditions, and to improve variable validation, you may like the PHP Cheat Sheets website.
This post summarizes the REST API component team meeting from May 10 in the #core-restapi channel.
Following up on this blog post outlining priority REST API issues affecting Gutenberg, we discussed ongoing work to address these questions. If you’re interested in helping with these projects, review the linked blog post and tickets in the Gutenberg “Merge Proposal: REST API” milestone; all assistance is welcome!
The remainder of the meeting was focused on ongoing discussion about upcoming changes to register_meta. Per the summary posted last week, we are introducing the ability to limit meta registration to a specific “object subtype” (e.g. specify meta for a single post type, rather than forcing registration for all post types equally). We will also be introducing wrapper functions such as register_post_meta() to encourage use of the new subtype argument. See ticket #38323 for the latest patch.
The REST API team requests review from committers and any developers with prior history around meta. There’s some great discussion going on but these changes will have a strong impact on how we do data-modeling in the REST API, so we want to make sure that all interested parties are involved. See in particular this comment on trac for a summary of the latest patch, and some remaining open questions:
Please check out the ticket (#38323) for further discussion.
In the past couple of months, I have been working on a patch to make WordPress fit with modern modular JavaScript programming practices. We’ve figured out what the concerns are with regard to JS code organization in WordPress and how to be future compatible, so we can easily allow modern JS practices and inclusion of projects like Gutenberg in WordPress.
This patch is the first big step towards an improved JavaScript development workflow for WordPress core and introduces the following major changes:
src directory, but I’ve taken multiple steps to make this transition acceptable and as smooth as possible, described below.src. All JavaScript is placed under src/js and is organized in an improved directory structure that gives much more context and is future compatible. In production, everything is built back into its original location to ensure backwards compatibility.Here’s an overview of the directory structure that comes with the patch and the idea behind it.
src/js | All the JavaScript source. ├── _enqueues | Any script that ends up being enqueued. │ ├── admin | Procedural scripts ran in the admin. │ ├── deprecated | All deprecated scripts. │ ├── lib | All standalone lib scripts. │ ├── vendor | All 3rd party deps that can't be managed with NPM. │ └── wp | All scripts that assign something to the wp namespace. │ ├── customize | Anything under wp.customize. │ ├── editor | Anything under wp.editor. │ ├── media | Anything under wp.media. │ ├── utils | Anything under wp.utils. │ └── widgets | jQuery widgets on the wp namespace. └── media | The media library.
This approach was taken for several reasons, almost all of which have to do with improving development workflows. This is broken down into the following concerns.
For a more elaborate description of these concerns, please refer to the ticket.
To make this transition as smooth as possible for code contributors, we’ve taken a couple of initial steps, with more to follow.
We’ve added a special page that people running WordPress from source will start seeing:
As the screen says, npm install && grunt build will be enough to trigger a build. After that, you should have a smooth development experience using grunt watch. The wording in the notification can still be improved. I’ve created a separate ticket to improve the wording of this message.
grunt watch
We’ve optimized grunt watch rebuild times to be much faster, typically around 1 second for JavaScript and almost instant for PHP. Developing with grunt watch should be a comfortable experience. Future optimizations in this area should still be possible and could make the developer experience even smoother.
I’ve written documentation drafts, which has been reviewed extensively by the Core JavaScript team, though more feedback is always greatly appreciated. There are 4 documents in total with the following topics:
These documents can be integrated into existing documentation or added to the handbook as separate entries once this patch takes effect.
In working on this, we’ve come to the conclusion that we can do a much better job at creating a seamless development experience for WordPress core. Some complexity cannot be avoided. But if we can find ways to not force that complexity onto contributors, we should do so. This patch is a good first step in enabling more modern development workflows and practices, but it also invites future iteration. To that end I’ve opened two more tickets:
The plan is for this change to be committed to trunk, so iteration can continue. I do acknowledge that, while we work on further improvements and optimizations, trunk might become slightly less comfortable to work with. This is the point where we need everyone’s help to get it right. Any help to improve the developer experience for WordPress core is greatly welcomed. You can think of feedback in the form of comments or tickets, tooling proposals, better use of existing tooling, optimizations of the build, anything that helps make the development experience for WordPress core more seamless.
