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:
Focused on substituting existing colors throughout Core stylesheets, the CSS Custom Properties project aims to make working with Admin Themes & Admin Color Schemes easier and more reliable both in Core and Plugins.
The #core-css team is looking for contributors interested in adopting a stylesheet (a process outlined here). No prior contributing experience is required — we’re happy to assist anyone who would like to participate! This meeting we will continue with work and collaboration, time permitting.
The team have been focused on reforming the project around the goal of removing the “experimental” status of the feature within the Gutenberg Plugin (only).
Friendly reminder from Dave to add the most appropriate labels to PRs in GitHub, whether you’re submitting PRs or helping with triage. All efforts there make work easier for the release lead.
It would be very helpful for us who run the Core Editor Meetings to have tracking issues that are updated once a week, so we can share the project updates during the meeting. As it will also give a nice overview and it would make it easier for anyone to follow along to see the progress over time.
The block-based Navigation editor screen has been behind an “experimental” feature flag within the Gutenbergplugin for some time. The purpose of the call was to outline the work required in order to remove the “experimental” status from the screen in order that the editor is active by default in the Gutenberg plugin.
The team working on the feature feel this is valuable in order to increase the visibility of the feature and therefore improve the quantity of feedback we receive.
Meeting Recording
If you’d like to watch the full recording of the session you can do so below:
Key points agreed
It was agreed that the prerequisite for removing “experimental” was: UI/UX feature parity with the existing Navigation screen (nav-menus.php) in Core.
We also acknowledged that:
We wouldn’t commit to feature parity of developer focused APIs at this stage.
Removing “experimental” in the Gutenberg plugin, would not automatically make the feature ready for merging into Core (that won’t happen until WordPress 5.9 at the earliest).
What was discussed?
The format of the hangout was an open discussion comparing and contrasting the classic menu screen with the experimental block-based navigation screen.
To this end attendees were asked to test drive both screens and note down their findings prior to the call.
The meeting facilitators also prepared a list of items as discussion points which were worked through during the call.
Each item was demonstrated, discussed and then assigned a loose priority of High/Medium/Low based on how critical the group felt the issue was to achieving feature parity.
Outcomes
The key outcomes of the call were:
A clearer understanding of the current project roadmap and the next steps required.
Contributors working on the Nav Editor will now look to reorganise and reprioritse the tracking issue around the problems identified during the call.
All items will be added to the tracking issue (with the possible exception of bugs).
The High priority section of the tracking issue will be reformed and refocused around the goal of “removing the experimental status from the Navigation Editor”. Only tasks directly related to this goal will be considered for inclusion in the “High” priority section.
Tasks identified during the call that were marked as Medium or High till be added to the aforementioned High priority section of the tracking issue.
Contributors will focus on tackling High priority tasks in order to realise the goal of removing the “experimental” status.
All contributors are encouraged to become involved in prioritisation. Everyone is welcome and we’d very much value your feedback. If you feel a priority is wrong or missing then please let your fellow contributors know.
Thanks to everyone who attended the hangout and we look forward to moving the Navigation Editor forward together.
The following schedule is being proposed for 5.8.1:
RC: Wednesday, September 1, 2021
Final release: Wednesday, September 8, 2021.
As of the publish date of this post, 24 tickets have already been fixed and backported to the 5.8 branch to be included in 5.8.1. 38 additional open tickets are currently in the 5.8.1 milestone for consideration. Please head over and check out that list to contribute to the release.
Release coordination
During the 5.8 release, a new, #5-8-release-leads channel was created in Slack for the release squad to have all 5.8 related conversations. Because the 5.8.x releases are part of 5.8 by extension, all coordination and conversation related to the 5.8.x releases will also be held here before the channel is archived when WordPress 5.9 is released.
Do you have something to propose for the agenda, or a specific item relevant to the usual agenda items above?
Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you accordingly.
This meeting happens in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.
The aim of the chat is to check the status of the rollback for failed plugin/theme updates after last Friday’s testing session and triage/scrub tickets in the component.
Got something to propose for the agenda? Please leave a comment below.
Work is continuing on (ryelle/wordpress-develop)[https://github.com/ryelle/wordpress-develop/pull/2]
Last week’s chat summary here covers our discussion around box-shadow, why we can’t use HSL and that we’ll be continuing discussion on this PR
This project is targeted for experimental release in WordPress 5.9 and then a stable release in 6.0. To make WordPress 5.9, the project probably needs to be merge-ready by end of August
If you have ever added a custom link to an image block and then tried to do the same on a Gallery image, you will understand the frustration and confusion of not having consistency between different types of image blocks. This inconsistency is because the core Gallery block stores the details of the included images as nested <img> elements within the block content. Therefore, the images within a gallery look and behave different from images within an individual image block. There are some long-standing open issues related to this:
The only way to fix this with the Gallery block in its current state is to try and replicate the additional functionality that the Image block has in the Gallery block, and vice versa. While this would be possible, it would lead to an additional maintenance overhead to keep the UI and underlying code in sync between the two blocks.
Changes made
To make the behavior of images consistent between the Image Block and Gallery, while avoiding code duplication, the core Gallery block has been refactored to save the individual images as nested core Image blocks using the standard core innerBlocks APIs. To make this work with the innerBlocksAPI, the gallery structure also had to change from an ordered list to a collection of figure elements within a figure. This structure change also brings the core Gallery block into line with the W3C WAI guidelines on the grouping of images.
The structure change means that Gallery images now have the ability to add custom links, or custom styles, for each image. An example of the flexible Gallery layouts this opens up can be seen below.
Gallery images will also automatically inherit new functionality that is added to the Image block, including those added by plugins. Below is an example of a Gallery block making us of the Image wave style and vintage filter option added by the CoBlocks plugin.
Other benefits include being able to use the standard move, drag and drop, copy, duplicate, and remove block functionalities. Keyboard navigation also benefits from the adoption of the standard block model by the Gallery block.
What theme and plugin authors need to do before 5.9
To support the new Gallery block format, plugin and theme authors should aim to do the following before the December release of this change in WordPress 5.9.
Any gallery related CSS should have additional selectors added to target images in the following structure in both the editor and front end (existing selectors must remain to support the existing gallery block content). The new structure can be seen below. See this issue for an example of the type of additional selectors that may need to be added.
For custom blocks with options to transform->from and transform->to the core Gallery block the plugin should be tested with the Gutenberg plugin to ensure that these transformations work correctly with both existing gallery content and the new gallery block format
In the future, when the new Gallery format is stable in a core release, the transformation filters will be deprecated, and plugin authors will need to update their transformations to handle both Gallery formats. Notice will be given ahead of this change being made.
It is also expected that existing gallery content will be automatically migrated to the new format. This will allow the old gallery version’s code to be removed from the codebase. There is currently no time frame set for this to occur.
Additional context and considerations
Other existing solutions
Third-party block developers are currently solving some of the problems caused by the limitations of the core Gallery block by implementing their custom Gallery blocks. These include some of the missing functionality, like the ability to add custom links to individual images. This can be problematic for site owners and content editors due to a large number of Gallery blocks that offer very similar functionality, but none of which appear to provide a close match to the functionality available with individual core Image blocks.
There do not appear to be any examples of plugins that already solve this problem in a way that utilizes Image blocks as inner blocks.
Backwards compatibility considerations
This is a breaking change due to the fundamental change in the underlying Gallery structure. Due to the large number of Gallery blocks already in use, along with themes and plugins that may rely on the existing structure, the following steps have been taken to mitigate the impact of this change on theme and plugin developers as much as possible:
Initially, there will be no automatic migration of existing gallery content. This means that all existing gallery content will behave the same in the editor and front end as it does now, so will be compatible with existing plugins and themes. Only new gallery blocks added after this change will have the new structure in the editor and the front-end.
The refactored Gallery format has been tested against the following sample block libraries that have existing transforms to and from the core Gallery block:
While the refactored gallery works effectively with these plugins and themes, there may be edge cases in other plugins and themes that have not been accounted for. Themes that heavily modify the gallery CSS based on the existing <ul><li></li></ul> will definitely need to be updated if the same style changes need to be applied to the new gallery format. Therefore, it is recommended that theme and plugin authors test the changed gallery block well in advance of the 5.9 release.
You must be logged in to post a comment.