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:
In preparation for the final release of WordPress 5.8 on July 20, 2021, an RC 4 has been packaged and released to fix some late-discovered blocking issues. The following changes have been made since RC 3:
Block Editor: Backport fixes targeted for WordPress 5.8 RC4 ([51445] for #53397).
Media: When resizing, WebP images set the compression to “lossy” by default. It Fixes a bug where the compression was set to “lossless” when the uploaded WebP images have extended file format (VP8X) ([51437] for #53653).
Media: Fix JS error in Media Library when infinite scroll enabled ([51441] for #53672).
Media: Document edge cases with the new image_editor_output_formatfilter ([51444] for #53667, #53668, #35725).
Privacy: Ensure the copy button actually copies the suggested privacy policy text ([51433] for #53652).
Widgets: Prevent widgets unintentionally being moved to the inactive sidebar ([51439] for #53657).
“Release Candidate” means the new version is ready for release, but with thousands of plugins and themes and differences in how the millions of people use WordPress, it is possible something was missed. WordPress 5.8 is slated for release on July 20, 2021, but your help is needed to get there—if you have not tried 5.8 yet, now is the time, we have one week to go!
How to Help
Test RC 4
You can test the WordPress 5.8 release candidate 4 in any of these three ways:
Install and activate the WordPress Beta Tester plugin (select the Bleeding edge channel and then Beta/RC Only stream)
Directly download the release candidate version (zip)
Use WP-CLI to test: wp core update --version=5.8-RC4
Thank you to all of the contributors who test the Beta and RC releases and give feedback. Testing for bugs is a critical part of polishing every release and a great way to contribute to WordPress.
If you think you have found a bug, you can post to the Alpha/Beta area in the support forums. We would love to hear from you! If you are comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.
Test your plugins and themes
Please test your plugins and themes against WordPress 5.8 and update the Tested up to version in the readme file to 5.8. If you find compatibility problems, please be sure to post to the support forums so we can try to solve them in time for the final release.
For a more detailed breakdown of the changes included in WordPress 5.8, check out the WordPress 5.8 beta 1 post. The WordPress 5.8 Field Guide, which is particularly useful for developers, has info and further links to help you get comfortable with the major changes.
@ryelle observed that a small subset of custom-properties are getting used very often, noting “…while it feels like a lot of variables to be adding, we also use the same concepts in many places”. For example:
@ryelle clarified that it’s added from a SASS mixin in base-styles and she thinks its there to allow each package to be standalone
We agreed that it does feel somewhat redundant when multiple packages are used together. Possibly it’s something that could be improved in future with core custom-properties
CSS Link Share / Open Floor
@ryelle shared a comment on the CSS deprecation ticket (#53070) that she wants to reply to. This led to a discussion about CSS deprecation which covered some of the following:
A wider discussion about CSS backwards compatibility needs to happen
Some kind of tooling might help to address the issue
In the ticket comment, @tellthemachines comments that, as moving redundant CSS into a deprecated.css file doesn’t offer a performance boost, it would be simpler to move it to a /* Deprecated */ section at the end of its file. @colorful-tones disagreed, noting that it deprecated.css existed it could be dequeued for a performance boost. @ryelle asked what would then happen if you installed a plugin that uses a deprecated style
@colorful-tones agreed with JJJs comment, adding that “Plugin developers need to keep up with changes. If their plugin breaks then it is on them to update.”
@ryelle noted that the deprecation issue centres more on “elements that don’t exist in core anymore but a plugin could be using that markup & expecting the CSS to just be there”
@colorful-tones observed that multiple deprecation paths might be needed for the various sources of CSS, which @ryelle summarised as theme CSS (the Twentys styles), wp-admin CSS (all the files in wp-admin/css and wp-includes/css) and Gutenberg CSS (“technically a subset of wp-admin CSS but also its own thing”)
@colorful-tones expressed support for the approach recommended in the Trac ticket: “Create deprecated.css and perhaps even start appending --deprecated-5.8 to classes that are deprecated.”
And, the mobile teams would really like you to test their respective beta releases, for iOS here and for Android here.
Upcoming release: 5.8
A final schedule reminder: we’re in the RC period, with a hard string freeze. RC 4 is slated for Thursday, July 15 at 16:00 UTC (Ed. note: basically now, at this writing) and final release in FIVE DAYS on Tuesday, July 20.
Big celebration for all the hard work there with 107 issues in the Done column. There are a few new items listed but, with an RC4 coming tomorrow, anything that cannot be completed today will likely need to wait for 5.8.1. Both @desrosj and @youknowriad noted this for the group. Don’t let this stop you from testing and finding bugs but do let this set expectations!
Still heavily focused on end user documentation in order to get the major new features covered (Query Loop, Widgets editor, Block pattern directory, Preferences, etc).
Running a hallway hangout today for the #fse-outreach-experiment (all are welcome!) and have been testing 5.8 everyday over the last week+ to find some bugs.
Attendance at the CoreJS Office hours has been low for the last few weeks so at the most recent chat those that were present decided that we’d move to a bi-weekly cadence for now. Here’s a quick summary of what is happening:
Core JavaScript office hours will be bi-weekly at the same time slot (15:00UTC) with the next meeting happening July 27th.
Whenever there is something requiring more attention, the suggestion is to schedule a dedicated meeting for interested parties to gather together in the #core-jsSlack channel to have the discussion.
A reminder that the #core-js channel and office hour chats are intended to cover JavaScript across all of WordPress core, all JavaScript infrastructure, tools that build, lint, or test JavaScript code and higher-level discussions about coding styles, libraries used, etc. So has some distinction (even though there can be some overlap) from the kinds of discussions that happen within the #core-editor Slack instance which focuses predominately on the Gutenberg project and its implementation within WordPress.
RC 2 released last week and RC 3 yesterday, now under hard string freeze
Email to plugin/theme authors on Field Guide went out last week
No further bug scrubs scheduled, so please highlight issues of concern directly in #core
5.8 release in SIX days on Tuesday, July 20th
Components check-in and status updates
5.8 plans and help needed
Check-in with each component for status updates.
Poll for components that need assistance.
Open Floor
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.
Welcome back to a new issue of Week in Core. Let’s take a look at what changed on Trac between July 5 and July 12, 2021.
49 commits
44 contributors
67 tickets created
28 tickets reopened
62 tickets closed
Please note that the WordPress Core team released WordPress 5.8 RC 2 last week. Everyone is welcome to help testing the next major release of WordPress 🌟
Ticket numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component and/or focus.
Code changes
Build/Test Tools
Add assertions to ensure version-controlled files are not modified during CI, and fix the grunt clean command – #53606
Replace assertInternalType() usage in unit tests – #53491, #46149
Use caching built into actions/setup-node – #53584
Some documentation improvements for wp_check_widget_editor_deps() – #53437, #53569
Update the IRC link from Freenode to Libera.chat – #53590
Editor
Merge conflicting wp.editor objects into single, non-conflicting object – #53437
Fix for theme.json: color.duotone and spacing.units should allow empty sets – #53175
Update packages with latest fixes for 5.8 RC2 – #53397
Update packages with latest fixes for 5.8 RC2 – #53397
TinyMCE: ensure initialization runs in all cases on ‘interactive’ and ‘complete’ readyState. Fixes a rare bug when the init code is inserted in the DOM after the page has finished loading – #53632
WordPress 5.8 brings several additions and tweaks to the block editor API.
Contextual patterns for easier creation and block transformations
We’ve all been there. Staring at a blank page sometimes with an idea of what you want to create; often with a mind as blank as the page. To make the creation process easier, there is now a way to suggest patterns based on the block being used. This is now implemented for the Query block and includes some core patterns to start with.
In addition, there is an API to suggest pattern transformations that are contextual to the currently selected blocks. So how this is different to the patterns current behaviour? Previously, patterns insert demo content that must be updated after insertion. With this feature, it’s possible to use some patterns and retain existing attributes or content.
So it’s for existing blocks!
An important thing to note here is that a pattern transform can result to adding more blocks than the ones currently selected. You can see this with an example like the below where we have a Quote block but the pattern consist of more blocks:
This is the first iteration of the feature that covers most simple blocks (without innerBlocks). A new experimental API has been created where we can mark what block attributes count as content attributes. You can see more details in the PR.
In the long run as this work continues and spreads to more blocks, it will be easier to create content and get inspired without leaving the editor.
Pattern Registration API
if you’re creating your own custom block patterns, there’s a new blockTypes property that will allow your patterns to show up in other contexts like the transform menu. blockTypes property is an array containing the block names.
In WordPress 5.8, core blocks toolbars have been updated and made more consistent across blocks by splitting them into 4 areas like shown in the following screenshot.
To do so a new group prop has been added to the wp.blockEditor.BlockControls component. Third-party block authors are encourage to use this prop in their block code to follow the core blocks design pattern.
My PR to refactor and re-enable the Table of Contents block is ready for review:
http://wayback.fauppsala.se:80/wayback/20210723221433/https://github.com/WordPress/gutenberg/pull/29739
Awesome! Thank you 🙂