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:
This post summarizes the dev chat meeting from June 13th (agenda, Slack archive).
The next meeting will take place on June 20, 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.
This release marks the 30th update to the editor plugin. The highlights are broken down below.
Arguably, one of the key pieces of the new editor UI is the block library or inserter. Unifying the way users can insert content has been one of the main objectives of the whole project. It has gone through multiple iterations and testing; balancing clarity, usability, flexibility, and extensibility. This release offers the result of some very fruitful collaborations between designers and developers.
Notably, tabs are being removed; blocks have bigger surface areas; and plugins can supply a distinct color for the block icon background. This seeks to allow the inserter to better scale while retaining visual clarity. The other addition to the inserter is related to the new concept of child blocks explained below.
The editor has had support for nesting blocks since around the beginning of this year. With 3.0, a block author can now also register a block as being a child of another block by declaring parent: [ 'block-name' ]. This now causes a few changes in the interface: the root inserter won’t show child blocks unless the user is within the context of the right parent block. (It aims to reduce the amounts of blocks shown at any given time by making the inserter more contextual.)
Note that for a block to be effectively a child two conditions must apply:
InnerBlocks area declared.This is how the block library looks after both changes:
During the whole process of Gutenberg, we have come to the realization that in order to have the most flexible system for styling within themes — and letting us get closer to visual parity between front-end and the editor — we had to separate presentational styles from structural styles when it comes to individual blocks. So far, we have not been loading presentational styles on the front-end in order to avoid unintentional changes to site’s appearance, but that also causes issues for new themes that would like to start working from the visual design baseline that Gutenberg offers by default as shown on the admin side.
The decision has been made to allow themes to opt-in to these styles with an add_theme_support( 'wp-block-styles' ) registration. This will allow us to keep (or reintroduce) some more opinionated styles for elements like Quotes, Tables, the Separator, and so on.
UrlInput box by using Popover component instead of custom positioning.InnerBlocks set, show available child blocks clearly at the top. Blocks with children are marked visually in the root inserter.PublishPanel and extensions.npm audit fix.preview_link through the REST API and use within client.default_page_template_title filter in page-attributes meta-box.enqueue_block_assets hook.ServerSideRender.blob package out of utils module.Because of a restriction of wordpress.org, you cannot comment on posts older than 120 days. This new post can be used to track the work on Javascript inline-docs. The original post on the JS docs initiative can be found here. In this post I have excluded files that have already been completed.
At the bottom is a list of every first-party JavaScript file in core. Files with a checkmark have been patched and are considered completed. Files marked with (username #xxxxx) are already claimed, and being worked on.
Directly below is the process we’re using to make sure each of these files can get patched swiftly with no duplicated nor wasted efforts.
svn up) or Git repo (use git pull) to the latest version of WordPress trunk.We’d like to welcome everyone to start contributing inline documentation! You can start contributing by picking a file from the list of unclaimed files below and claiming it in the comments. Please also see the JS docs handbook page for a step by step guide on how to get started.
Note: Note: To give everyone a chance to claim a file and to ensure the work proceeds as quickly as possible, please only work on one file at a time.
We use JSDoc’s @since tag to indicate when a particular function was added to WordPress core. When you are documenting a function, you will also need to identify when that function was first introduced.
The recommended tool to use when searching for the version something was added to WordPress is svn blame. An additional resource for hooks is the WordPress Hooks Database. If, after using these tools, the version number cannot be determined, use @since Unknown.
If you use the git repository of WordPress you can also use git to determine the @since version. Either use git blame or the GitHub blame function. Once you have the commit hash which introduced a piece of code you can find out the version by using git tag --contains [commit-hash]. This will list all versions a certain commit has been shipped in. The lowest version is then what you put after the @since annotation.
Note: Make sure that the commit you found it the actual commit where a piece of code was introduced. JavaScript files have been moved around a lot in the past, so make sure to take that into account.
Note: All @since tags should follow the three digit x.x.x format.
Any discussion about the specifics of a patch itself should happen on Trac. Any discussion about the broader scope of what we’re trying to do should take place during the weekly devchat. That’s either #core-js or #core.
Checked files are completed, marked files are claimed
Current status:
Happy documenting!
This is the agenda for the weekly dev meeting on June 13, 2018 at 20:00 UTC / June 13, 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 last 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.
Incompatible with your version of WordPress. Please update WordPress (link to update WordPress).
Incompatible with your version of PHP. Learn more about updating PHP (link to the Upgrading PHP page).
You can’t install this plugin because it doesn’t work with your version of WordPress. Please update WordPress (link to update WordPress).
You can’t install this plugin because it doesn’t work with your version of PHP. Learn more about updating PHP (link to the Upgrading PHP page).
While the preliminary decisions made during the meeting are certainly not final, @afragen implemented the state after the meeting in an updated patch and provided screenshots for it on the ticket, which can help a lot in evaluating the possible approaches in the upcoming meetings.
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.
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.
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.
This post summarizes the dev chat meeting from May 30th (agenda, Slack archive).
The next meeting will take place on June 6, 2018 at 20:00 UTC / June 6, 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.
