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:
While the Block Widgets Editor was released with WordPress 5.8, the work to improve the experience hasn’t stopped to help even more folks use blocks to build out widget areas in an endless number of ways. The latest in a series of improvements comes with the launch of Gutenberg 11.5 that introduces a Widget Group block. This new block replicates the familiar experience of being able to add a title to a group of blocks and allows you to group any block, making it easier to move and layout content however you’d like. This both helps with compatibility for older themes when migrating over to the new editor and enables a more cohesive experience for building out widget areas.
For example, before this update, it was tricky to get the spacing right for adding a header above another set of blocks. Now, you can do that with ease:
Video showing how to use the Widget Group Block.
This also makes it a breeze to move collections of blocks into new widget areas:
Video showing how you can drag and drop a collection of blocks within the Widget Group Block.
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.
All core CSS files have now been claimed, and are either in progress or have a PR, however @dryanpress reminded us that if anyone has claimed a file and can no longer work on it please do let us know
The next step is reviewing and merging PRs. Help is very welcome if anybody is up for “trying out a PR and making sure the colors still look correct (or correct enough, where maybe we made changes)“
@dryanpress raised the topic of skinning admin colour schemes, as there are some custom properties for body.admin-color-ectoplasm already in custom-properties.css. We would probably create a couple of colour schemes at a later stage, for testing & demonstration purposes
@dryanpress outlined the final todo list for the project:
Merge all remaining files
Look for duplication and opportunities for property consolidation
Final team review
Merge proposal write-ups
@ryelle added that, before the final team review step, discussion will be needed about what to consolidate and how, for example rgba and box-shadow values
@ryelle added that, as there are several PRs now merged, anybody interested could start generating some ideas for these next steps right now
@dryanpress asked if we are still on target for an --experimental release in 5.9 which @ryelle confirmed we have good momentum for
@ryelle observed that there are other places outside of CSS files where CSS is used, for example php and js files, which also need to be reviewed. @dryanpress offered to add this and the other tasks (mentioned above) to the planning document
@danfarrow had quickly calculated there are now 127 custom properties in custom-properties.css. @robertg added that this isn’t including the 225 (approx) in his PR
This post was authored by @opr18 (Thomas Roberts).
During a recent WordPress #core-js meeting there was a discussion about updating the JavaScript coding standard. The specific update that is being proposed is to change the rules relating to comments.
Currently, the standard reads:
Comments come before the code to which they refer, and should always be preceded by a blank line. Capitalize the first letter of the comment, and include a period at the end when writing full sentences. There must be a single space between the comment token (//) and the comment text.
The proposal is that the new wording should be:
Comments come before the code to which they refer, and should always be preceded by a blank line. Unless writing a linter override, or a `@see` type comment, capitalize the first letter of the comment, and include a period at the end. There must be a single space between the comment token (//) and the comment text.
The problem with the current guideline is that it is not enforceable by automated tools. It is hard for linting tools to easily distinguish between what is and isn’t a full sentence in the context of code comments.
Code reviews can quickly fill up with noisy comments and suggestions to capitalise or add periods to code comments. If this were fixable with a linting rule then these comments wouldn’t be necessary.
There are instances where it may not make sense to write in sentence case, for example: adding linter overrides or writing `see` comments where the comment may just be the name of a method or file, etc. so we would not enforce the rule on these types of comments.
If this guideline were to be amended, there would be several instances of code in the Gutenberg repository alone that do not follow it. It would be necessary to create a PR that fixes all of these issues. Because the change only relates to comments, a single PR can be made addressing all instances of comments that don’t follow the guideline, because the rule relates to comments only, this would have no impact on functionality so minimal testing would be required.
WordPress core currently uses JSHint for linting JavaScript files, and it does not appear that even the existing style guideline is enforced. Even so, if efforts were made to move to ESLint in WordPress core, implementing a fix for any comments that do not follow the standard should be straightforward.
Initially the rule could be enforced as a “warning” while the PR to fix the issues is completed and after it has been merged the rule could graduate to an “error”.
Preliminary Roadmap, a quick overview of the main areas and features currently underway for 5.9 in Gutenberg.
Gutenberg 11.5.0
Gutenberg 11.5.0 was released on 16th September, this update includes Block Gap support, improved support for Flex Layouts, performance improvements, and additional design tools. Check out the release post for a complete list of features and enhancements:
Monthly Plan
The monthly update containing the high-level items that Gutenberg contributors are focusing on for June are:
Work is still progressing on migrating the navigation editor fully over to the REST API. The REST API changes have been merged, and now the front end code is being updated.
Lots of UI changes this week with the editor top bar being updated, the main block inserter added, and fixes to the block’s styles.
Also in general, we’re always looking for contributors to help work on the Nav Editor and bloc, if you’re interested please head over to the #feature-navigation-block-editor Slack channel. Look forward to seeing you there.
Simple PR’s to get the ball rolling as long as one is approved I guess we can merge multiple similar ones.
Worked on implement the new custom gradient picker design.
Currently working on the new color palette editor.
For the next week I will continue with improving the global styles related components.
Will see how can I best help the effort of implementing the new sidebar with its navigation system.
Will try to dedicate attention to old PR’s I have that are mostly ready.
Mosaic view and block awareness of global styles I hope to merge them so my head becomes free for other challenges and we can submit follow ups on them.
Some further planning for the Typography Panel features in Global Styles, which will use the same ToolsPanel component recently introduced alongside the new Dimensions Panel.
Allows `theme.json` to control features that are unique to particular blocks (as opposed to things that are common across all blocks such as spacing).
I’d really like to understand whether this is within the intended scope for Theme JSON.
This has large utility outside Nav Editor because I imagine Themers wanting to be able to control multiple facets of blocks (and not just common things such as padding/margin…etc) without having to use complex hooks/filters
With Block Gap support in place, it has also been added to the Columns, Title, and Navigation blocks.
Buttons in the the Buttons Block move closer together or farther apart as the Block Gap is changed.
Flex Layout Highlights
Following the introduction of Flex Layout in 11.2.0, now Flex Layouts are supported within the Social Links and Group blocks! The Social Links block now has a ‘flex’ justification option, for automatic best-fit.
There is also a new variation of the Group block that allows for flex layout. You can try it out by choosing “Row” from the block inserter.
Social Icons change flow when flex justification is selected.
Site Title and Logo Inside Navigation Block
It’s now possible to build your site logo or title directly into menus, enabling new design possibilities! Insert, and modify the title or logo that you prefer, using design tools, then re-order for your ideal look.
A Site Logo is added to a Navigation Block, then resized and placed.
Global Styles
Global styles are now available to themes by default, allowing block, theme, and patterns to have a reliable set of styles provided by core.
Themes are now able to selectively disable text and background colors. This allows theme authors to provide exactly the experience they’d like to provide users, whether allowing custom colors, gradients, or only their curated selections.
Other Notable Highlights
The Heading Levels menu has been redesigned, and is now vertical, making it easier to visualize the hierarchy.
Jest Preset: Restore the default setting for the verbose option. (34327)
Make Test_Widget compatible with WP_Widget. (34355)
Performance Benchmark
The following benchmark compares performance for a particularly sizeable post (~36,000 words, ~1,000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.
Version
Loading Time
KeyPress Event (typing)
Gutenberg 11.5
6.71s
40.42ms
Gutenberg 11.4
6.80s
44.79ms
WordPress 5.8
7.53s
50.72ms
Kudos to all the contributors that helped with the release! 👏
Thanks to @beafialho and @joen for the release post assets, @priethor for coordination and review, @youknowriad for release and tools wrangling, @mamaduka for answers and help throughout, and @talldanwp for inviting me to shadow a release in preparation.
This status update contains the high-level items that Gutenberg contributors are focusing onin preparation for the WordPress 5.9 Go/No Go that builds on the focus areas for 5.9 and the current Site Editing Scope. Please join us in our efforts and let us know in the comments if anything is blocking you from doing so.
The Template Editor is the editing mode that allows you to create, assign, and edit block templates to posts and pages. There are different editors that leverage this editing mode, such as the Template Editor inside the Post Editor or the Site Editor available in the Gutenberg plugin. Current focuses include:
With the initial rollout of the new directory in WordPress 5.8, there’s a growing need to expand the inserter integration to accommodate broader categories of patterns and the experience of browsing them:
WordPress 5.8 introduced the scaffolding necessary for themes to control how various aspects of blocks render and how the interface is controlled. The natural next step ahead is to develop the user interface that will allow themers to build with these style properties directly in the editor and when allowed, users to interact with these style properties.
Design tools encompass all tools related to the appearance of blocks and it ranges from colors, typography, alignments, and positioning, to filters like duotone, cropping, and background media creation of shared tools and its consistent application across blocks:
With the help of the Navigation block, editing a site’s navigation menu will be possible with a block interface and within a stand-alone block editor. This will allow users to edit not only the menu’s structure but also its design directly in context and without the need for previewing. The main current focuses in this project are:
The Navigation Editor aims to help expand what’s possible with menus while bringing block functionality to yet another part of WordPress while offering a more modern experience. Current efforts include:
While the above items are our focuses, don’t forget that you can always help with triage, testing issues, good first issues, and reviewing PRs. In particular, if you’re interested in helping with triage but don’t know where to start, there’s a course on Learn WordPress for how to do triage in GitHub! Check it out and join us.
If there’s anything we can do to make contributing easier, let us know in the comments or in #core-editor chats. While we can’t promise to fix everything, we’d appreciate being aware of any blockers.
I am honored to contribute ♥️.
Is there a planned release date for 5.8.2?
Yeah, and we have a “WP 5.8.2 Update” item in today’s devchat agenda, the minor release squad is going to tell us more about the planning 🙂