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 new release completes some cool additions to the editor. It includes the ability to create reusable templates by selecting multiple blocks in the editor. It then allows exporting and importing these templates using a JSON file transport. There’s also a visual diff mechanism for comparing options when a block was detected as invalid (which could scale in the future to improved UX for revisions as a whole), toolbar groups can be defined as collapsible into a dropdown to better organize available block controls.
There’s also the addition of a much clearer drag handle for drag and drop block operations next to the block arrow controls. It’s also possible to convert an image into a cover image and back, retaining the caption as the main text among many other small improvements and fixes.
$post object is set properly.isButton prop._n() is used just for single item.Deprecations removed with this version.
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 is the agenda for the weekly devchat meeting on September 19, 2018 at 20:00 UTC:
If you have anything to propose to add to the agenda or specific items related to the above, then please leave a comment below. Either way, we look forward to seeing you at the devchat this week!
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.
@wordpress/data continues, with the introduction of support for generator controls in resolvers.wp-polyfill script has been added to Gutenberg, the goal of which to serve as a single dependency which any plugin seeking support for either new language features or browser functionality can leverage. Gutenberg registers a number of scripts, but an exhaustive set of all scripts isn’t available, nor is it well-documented how these scripts can be used by a plugin.
Decision: Create new documentation to be included in the “Reference” section of the Gutenberg Handbook, detailing which script handles are available for plugin authors to reference.
Issue: https://github.com/WordPress/gutenberg/issues/10005
@wordpress/date moduleOur @wordpress/date module uses the popular Moment.js library to implement date formatting. We should be conscious of the long-term maintenance burden in committing this into our public API, particularly in light of alternative date formatting offerings and future maintenance likelihood of Moment.js.
Decision: We’ll continue to use Moment.js for the immediate future, but we should eliminate its availability from the public interface.
Issue: https://github.com/WordPress/gutenberg/issues/10007
Future Action Items:
Related Resources:
This post summarizes the weekly dev chat meeting held Wednesday, September 12, 2018 at 20:00 UTC. Agenda | Slack archive
We have a Road Map and she is gorgeous. Thank you @antpb and @schlessera for putting it together. Here’s a summary:
We will reassess these dates after the three-week mark:
If you’re interested in helping out with these topics, hit up these Slack channels:
*Not real but should be.
If you’re thinking about get all up in these Focus and Component Maintainer teams, try attending a chat. Here’s the comprehensive list.
Anyone can submit a ticket for the Open Floor. Send your submission to @jeffpaul or moi (@whitneyyadrich), or comment on the agenda for that week’s chat.
@psykro published his proposal for a second <dev chat> and it’s open for your comments. I’m sure we’ll touch on this during tomorrow’s dev chat, too.
As always, anyone is welcome to join <dev chat> every Wednesday at 20:00 UTC. As I said in the chat, to sorta quote the late, great Notorious B.I.G.
I’m goin’ go call my WP crew
You go call your WP crew
We can rendezvous in <dev chat> tomorrow around two (or Wednesday at 20:00 UTC)
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.
wp-polyfill-ecmascript (and will be simplified soon as just wp-polyfill) that you can add as a dependency to your script to ensure the polyfills are loaded.wp-polyfill-ecmascript instead of including them per dependency. A decision was made to have a unique wp-polyfill script you can depend on and use all the polyfills made available by WordPress. This script would include both ECMAScript polyfills and also different Web Standards that require polyfills such as window.fetchor element.closest. This results in a better developer experience as it’s not always easy to know what polyfill is needed for per script.wp-polyfill script (Pull Request to follow). cc @aduth
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.
Gutenberg has a policy where deprecated functionality is kept for two additional minor versions to allow time for plugin developers to move away. As we start deprecating functionality in the published npm modules, the idea of tying to Gutenberg version doesn’t make a whole lot of sense, as these packages could be used independently of Gutenberg or WordPress.
It was raised by many that our packages should just follow semver. The most likely scenario for the 5.0 merge will be that the JavaScript will still be maintained on Github and included in WordPress through npm. The aforementioned deprecation policy is mostly something that applies to the Gutenberg / WordPress context then. The initial idea in terms of flow looks somewhat like this:
deprecated to allow Gutenberg to define its domain-specific messaging (@aduth, @youknowriad)The build step that was introduced in #43055 seems to cause quite some friction for PHP development, since now you also need to build to see a change in the PHP reflected. This turns out to be a weird experience for PHP development, since there’s no real reason why it needs to be built. A solution that allows for building with symlinked PHP files was pursued in #44492, but seems to run into a dead end. @omarreiss is now working on a grunt build:dev task which allows to build into src after all and asked if anyone had any input / objections.
It was raised that some PHP files (ie. formatting.php) need to be built right now and this is really confusing. Since PHP is a dynamic server language, we should look if we can avoid any PHP from being built statically. Apart from this there seemed to be no objections to the approach.
@omarreiss will work on a patch.
Currently it’s not clear if plugin developers should consume WordPress packages through the wp global or by importing them from the @wordpress/ namespace. Documentation and guidelines about this are currently lacking. It was raised that different approaches are probably needed in different scenario’s. Factors that play a role are:
@atimmer will work on a guideline for the plugin development handbook in which he plans to document different scenario’s and approaches.
This is the agenda for the weekly devchat meeting on September 5, 2018 at 20:00 UTC:
If you have anything to propose to add to the agenda or specific items related to the above, then please leave a comment below. Either way, we look forward to seeing you at the devchat this week!
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.
What tasks do we need to complete on the core side to be ready for Gutenberg Merge?
| What? | Who? |
|
Experiment with the following steps to see how this works: WordPress side: – Gutenberg packages stay where they are – Gutenberg’s PHP (script registration and bootstrapping) move to core. – Webpack config to alias wp.* to npm dependencies moves to Core’s webpack config. Gutenberg side: – Kept as plugin for ease of maintenance, updates. – Plugin re-register’s the scripts (overriding wp’s registrations) – No more php bootstrapping in the Gutenberg repository. |
|
|
Some experimentation could involve consuming packages in WordPress core. Example: Usage of shortcodes.js could be replaced with @wordpress/shortcodes
|
|
edit-post needs to be moved to a package. |
|
Resolve componentsand block-library which have some code that lives outside packages. |
The following things were discussed:
No clear resolution to the above points was made in the meeting.
| What? | Who? |
|
Decision: Ship packages without any polyfills, then bundle all polyfills in WordPress core. Documentation will include something like this: This package assumes that your code will run in an ES2015+ environment. If you’re using an environment that has limited or no support for ES2015+ such as lower versions of IE then using core-js or @babel/polyfill will add support for these methods. Learn more about it in Babel docs. |
@gziolo |
lodash to lodash-es for distributed packages| What? | Who? |
| Continue discussion on the related issue. |
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.
WordPress.github.io/servehappy-resources, which is not very obvious for what it contains. A repository named update-php or update-php-resources would be a better alternative. Alternatively, a custom domain could be used. This needs to be carefully evaluated.