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:
The release this week introduces a few significant user experience improvements. The inserter has been tweaked to accommodate new icons for all core blocks (with core embeds showing the icon for the corresponding service), more visual breathing room, and better handling of searches with diacritics. The new icons aim to encourage people creating their own blocks to supply their own SVG—the hope is to make sure we can avoid multiple cases of duplicated icons diminishing the overall ability to quickly scan blocks.
The publishing flow has been updated to show the tag input panel and post format selector before publishing. Previewing should also be a bit more robust in handling the new tab.
A new help modal—showing all available keyboard shortcuts—has also been added. Several shortcuts have been introduced: inserting a new block before / after the current block, toggling the inspector settings, removing a block, and showing said help menu.
Likewise, there are several bug fixes, notably for IE11 users.
per_page=-1 in the queried data state.has_blocks function to the repertoire.has_block function and unit tests.strip_dynamic_blocks() for excerpts.Promise.resolve call that’s already handled by the JS runtime.withContext HOC and remove its usage.insert option.DOCKER_ENV=localwpdev.Deprecations removed with this version.
This post summarizes the REST API component team chat from August 9 (agenda, Slack archive).
The REST API team’s primary goal for the next major release is to support the Gutenberg team. There are still a number of REST API-related issues open in the Gutenberg merge proposal milestone; we always welcome assistance in getting these taken care of.
Issues that were raised as needing eyes and opinions:
wp/v2 namespace)Outside of Gutenberg, the two major areas of development we aim to tackle are
Following the register_meta improvements in 4.9.8, we wish to continue improving the state of meta handling and registration within the REST API.
We aim to release a tested version of the OAuth 2.0 plugin to the plugin repository by the end of the year. This will greatly assist application developers who wish to integrate their WordPress site with external applications. We are also interested in pursuing a basic auth solution within core (see discussion in #42790).
As @rmccue is currently unavailable to lead development in this area, we are opening a call for a lead contributor to the REST API authentication plugins. We need somebody to own the vision for how external applications should authenticate with WordPress.
The REST API team will be meeting shortly (now, in fact…) in #core-restapi for our regular weekly meeting at 2018-08-16T17:00 UTC. As always, if you have a REST API related ticket you would like to bring to the component team’s attention, please join us or leave a note in the #core-restapi channel. Hope to see you all later today!
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.
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.
This is the agenda for the weekly devchat meeting on August 15, 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!
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.
Another update has sailed! This one comes after WordPress 4.9.8 release with the “try the new editor” notice, which has increased the number of installs from 15k to more than 120k in a few days. This is an important milestone as we broaden the testing horizons. We’d like to take a moment to thank everyone that has tested and given feedback through the various channels.
Likewise, huge thanks to everyone that has helped answer questions, addressed forum feedback, triaged new issues, fixed bugs, and generally jumped in to contribute.
Back to the release, this one includes several fixes, polish, and cleaner interactions around the writing flow. On the developer side, there’s been work around refining and adding to the pool of APIs and documentation.
navigateRegions component.shift+alt+n to go to the next region.shift+alt+p to go to the previous region.forwardedRef prop.thead tags.wp-edit-post.gutenberg_can_edit_post filter.save.package-lock.json.jest, npm-package-json-lint and read-pkg-up.Deprecations removed with this version.
We’ve been remiss about posting these, but discussion has been ongoing in #core-restapi over the past few weeks. We’ve seen a lot of discussion of Gutenberg priorities and compatibility issues, and have also been discussing the need for more robust authentication and considering future improvements to register_meta.
This week, the agenda for our scheduled REST API component meeting today (2018-08-09 17:00 UTC) is:
register_meta: discuss and prioritize future enhancementsAs always, if you have a REST API related ticket you would like to bring to the component team’s attention, please join us or leave a note in the #core-restapi channel. Hope to see you all later today!
This is the agenda for the weekly devchat meeting on Wednesday, August 08 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.
Problem: Publishing modules to npm can be difficult because it is not always clear at the time of publishing to what version the package should be updated. The individual performing the publish is not always the same as the contributors who had proposed changes to the package.
Options:
Decision: Encourage developers to introduce changelog entries and evaluate success in a future meeting.
Problem: When deprecating a feature in Gutenberg, we add logging to highlight the deprecation, and allow for two minor releases of the plugin before removing the functionality. With this in mind, how do we handle versioning of modules? Following SemVer, the major version should be bumped on backwards-incompatible changes. If the deprecation is not entirely faithful and therefore introduces a breaking change, it results in the need for two separate major version bumps by the removal of a single feature.
Discussion points:
Decision: The major version should be bumped on any backwards-incompatible change. This will usually occur at the final removal of the feature. The deprecation should be fully backwards-compatible and, if it is not, it should warrant a separate major version bump.
Problem: There are several inconsistencies between the WordPress PHP implementation of add_query_arg and the parallel addQueryArgs from the @wordpress/url package:
Name pluralization: addQueryArgs (JS) vs. add_query_arg (PHP)
Arguments: url, param (JS) vs. param, url (PHP)
Usage: Object only (JS) vs. object or key+value pair (PHP)
Discussion points:
Decision: There will be no changes to the name or argument order of the addQueryArgs function. Supporting key and value arguments may be a separate enhancement to consider.
Announcement: The @wordpress/data module now supports a plugin API. Persistence behaviors, which were previously baked in, are now extracted out to an opt-in plugin. This should help improve isolation of specific behaviors, and allow external consumers to use only specific features relevant for their products.
A new pattern for asynchronous state behaviors has been implemented, distributed as the @wordpress/redux-routine package and integrated with the @wordpress/data module via a new controls plugin.
Announcement: A fix has been backported from the Meta team into the @wordpress/dom-ready package, addressing an issue where callbacks may not be called reliably if the document was in specific states. This was the cause of intermittent white-screen issues on the Gutenberg marketing page.
wp.api
Question: Do we still use wp.api ?
Answer: Only in the (now-deprecated) withAPIData higher-order component. Once this deprecation is complete, there will be no more usage of wp.api and it can be safely removed.
