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 October 10th (agenda, Slack archive).
The next meeting will take place on October 17, 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.
To better understand how we can integrate Gutenberg into WordPress, it’s crucial to know how the Gutenberg plugin is organized.
The Gutenberg plugin is mostly a JavaScript application composed of several packages. Each one of these packages is:
wp global variable.For example:
A @wordpress/components npm package is registered in the plugin as a wp-components WordPress script; its API is available in the wp.components global variable; and depends on @wordpress/element.
In turn, @wordpress/element‘s script is wp-element and is consumed by @wordpress/components in the bundled script as wp.element.
To display the editor’s page we call wp.editPost.initializeEditor from the higher-level wp-edit-post package. This function takes as arguments the post to be edited and some editor settings.
This call is made when loading the edit.php page localizing the required arguments and enqueuing the wp-edit-post script.
Once the editor’s page rendered, all the communication with WordPress happens using REST API calls. In addition to the regular REST API endpoints to fetch, update and delete taxonomies, posts, etc., Gutenberg adds new REST API endpoints that include:
Many other tweaks have been necessary in existing endpoints (taxonomies, embeds, permalinks, post search, etc) and most of these have been merged in the previous 4.9.* releases.
To support MetaBoxes, Gutenberg hooks initially render the content of the MetaBoxes in a hidden DOM node rendered using a PHP script. We also hook into the post.php call to persist the MetaBoxes save call.
So, as a high-level picture, the Gutenberg plugin is composed of:
edit.php.In previous JavaScript meetings, we discussed the packages integration approach:
Since the JavaScript scripts are built as reusable npm packages, we’ll consume them in WordPress like any other npm package:
package.json.wp.* globals in enqueue scripts inside WordPress Core.wp.components = require( '@wordpress/components' );
wp-includes/script-loader.php.Scripts like wp.shortcode, wp.a11y.speak, wp.utils.WordCount can be replaced by their corresponding npm packages. This has already been proposed for the shortcode package and should continue for other packages.
The work being done in #core-js meetings to align the JavaScript guidelines (code style) between Gutenberg and Core would result in a formal @wordpress/eslint-preset package that should be used as a replacement for the current JSHint config.
The REST endpoints should be moved to the regular REST endpoints location in WordPress Core wp-includes/rest-api/endpoints.
The PHP utilities and classes should be moved to wp-includes.
Some minor tasks are also left to do in the Gutenberg repository:
Gutenberg name from all the PHP APIs still using it.block-library and edit-post packages:edit-post package.The e2e tests are crucial to avoid regression when making updates to WP-Admin. The e2e test infrastructure and the tests themselves should be moved to WordPress Core and their stability can be considered a metric for the success of the integration process.
Unit tests, in general, live next the code being tested. For packages, these will stay in the Gutenberg repository and, for the files moved to Core, the tests will follow.
After WordPress 5.0 is released, the Gutenberg plugin will continue to exist. Its purpose will be changed to the development and the maintenance of the WordPress npm packages, including the editor itself, and will also serve to develop the second phase (site customization) of the Gutenberg project. Plugin updates will continue to be released during the 5.0 cycle.
The PHP part of the plugin won’t be needed anymore, as the plugin will just register new versions of the scripts of the packages to replace the ones already registered by Core.
This post summarizes the dev chat meeting from September 26th (agenda, Slack archive).
The next meeting will take place on October 3, 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.
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.
@youknowriad proposed a pretty exciting change which would allow to consume the existing @wordpress/shortcode npm packge in WordPress core. It’s ready for testing and gathering feedback.
Issue: https://core.trac.wordpress.org/ticket/44987
Once it lands in core, it will enable further integrations with the packages like @wordpress/a11y, @wordpress/api-request, @wordpress/wordcount, etc. This is going to pave the way to integrate Gutenberg in core.
We have only 6 team members which are able to publish updated npm packges to npm. We would love to extend this group to have more flexibility and better coverage when people take time off.
We also discussed that we should start publishing updates to packages on regular basis like once a week. Preferably before the weekly JS chat.
@noisysocks volunteered to help with the upcoming release 🎉 Let us know if you are willing to join the group.
Kudos to @hypest for adding tests for Mobile Gutenberg in Gutenberg’s Continues Integration job. This is the first step towards merging those two repositories together and bring their development process even closer. It will help us prevent introducing changes which would break the mobile project.
This post summarizes the dev chat meeting from September 19th (agenda, Slack archive).
The next meeting will take place on September 26, 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 post summarizes the weekly dev chat meeting held Wednesday, August 08, 2018 (agenda | Slack archive).
It’s time to select release leads for our 4.9.9 maintenance release. Hooray! If you’d like to nominate someone, or yourself, add a comment to this post. Don’t be shy, y’all.
What does a release lead do? Here are some good resources:
🔥 Hot Tip 🔥 You don’t have to be an engineer to be a release lead.
Thank you to all who gave us feedback so far! The feedback is being processed and iterations are underway.
Via @davecpage. There are multiple tickets open related to this:
These are all related to the taxonomy component, and we’ll currently slate them for release in 4.9.9.
@jeffpaul is ill and will hopefully return next week. Until he’s at full strength, @joemcgill, @audrasjb, @antpb and I will continue to run dev chat.
The next meeting will take place on Wednesday, August 15, at 20:00 UTC in the #core Slack channel. Please drop in with any updates or questions. If you have items to discuss, drop a comment on next week’s agenda post, so we can take them into account.
This post summarizes the dev chat meeting from June 27th (agenda, Slack archive).
The next meeting will take place on July 4, 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 post summarizes the dev chat meeting from June 20th (agenda, Slack archive).
The next meeting will take place on June 27, 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.
Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack transcript). Notes compiled by @youknowriad.
Participants: @aduth, @atimmer, @bpayton, @gziolo, @jorbin, Jorge Costa, @omarreiss, @welcher, @youknowriad
A new post to track the work on the JS Docs effort has been published.
Gutenberg now includes a tool to generate documentation based on JSDoc. It’s being used to document the selectors and actions available in the data module.
Action items to follow-up on:
We discussed the best way to load JavaScript polyfills in WordPress for WordPress scripts and plugins while avoiding the duplicated code and reduce the bundle size as much as possible. There’s no clear path forward yet. An idea that’s being explored is to use the fact that browsers that support `modules` also support async/await, arrow functions, Set/Map, Promise, generators. This means we can generate two scripts once for browsers supporting “modules” (most recent browsers) and one for browsers that don’t (IE11) (See related blog post explaining the technique).
@bpayton proposed trying an alternative approach to target a base stub script which includes all polyfills. This will be proposed in a Gutenberg pull request and evaluated next week.
@jorbin raised a concern about the availability of meeting notes and agendas for #core-js meetings. On previous chats, it has been decided to avoid those because of the effort required to prepare and compile those for #core-js chat leads.
To address this, a group to rotate on the responsibility of taking notes has been created: @aduth @atimmer @gziolo @nerrad @omarreiss @youknowriad all volunteered to do so. If you want to volunteer as well, please leave a comment.
Two separate issues were raised regarding the deprecation strategy:
It has been argued that deprecating code in JavaScript is a requirement. Unlike PHP, keeping old APIs forever is not an option because of bundle size and performance.
It has been raised that It’s important for us to keep the trust plugin authors have towards WordPress in maintaining stable APIs without breakage. A clear communication strategy with plugin authors and developers is important in keeping the level of trust developers have towards WordPress APIs.
@atimmer proposed a path towards a clear deprecation strategy
It was argued that communicating the benefits of these deprecation is crucial instead of emphasizing on the potential breakage. We also discussed that raising awareness about this strategy to plugin authors is crucial to the trust factor.
@aduth proposed the introduction of versioned scripts and automatically wrapping scripts in closures to avoid conflicts between two different versions of the same script. (See demonstration)
Discussion on the deprecation strategy will continue in the next meetings.
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!
