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:
@Dave Ryan reported having made solid progress on login.css & finding some near-duplicate shades of blue, for which he added new custom properties. Work on colour unification can come later
@notlaura had a similar experience with shades of grey and agreed with the approach. @Dave Ryan added a note about it to the shared doc
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.
@notlaura wondered how we could encourage participation at the chats, and get more help with the Custom Properties project. She suggested maybe some guidelines on how to get started contributing
@danfarrow started updating forms.css noting that some custom properties have a longer ancestry e.g. --wp-admin--button--text takes its value from --wp-admin--button-primary, which in turn takes its value from --wp-admin--theme--primary. He speculated that tooling could make it easier to traverse & understand this hierarchy
For open floor:
If it’s okay, I’d be interested in shadowing someone close to my timezone (JST, so I’m guessing APAC or EU would work best) on a Gutenberg release, to learn more about what’s involved.
I’d eventually love to be able to help with running one, and hoping that would help with learning about the knowledge gaps to fill.
Could whoever is running the GutenbergPlugin release today please let me know how they found the automated changelog feature grouping? I worked on a couple of PRs on that and I’m curious to know whether anything could be improved. My DM’s are open 🙂
Also on that note, please can I make a plea for folks to consider being even more proactive in assigning labels to Github Issues? With the correct labels assigned creating the release changelog can be far more automated. I’ve noticed a number of recent PRs without any labels and so I’m hopeful that we can reverse that trend for the benefit of the release leads. Much appreciated 🙇🏻♂️
@desroj highlighted a bug in the Multisite Filesystem API that was requested to be prioritized in 5.9.
@chanthaboune raised a discussion about Making WordPress Slack — what we can/should use it for. Should #core be the default channel? Should some other Slack channel be created to greet new users (who may or may not have context entering Slack that it is mostly a working environment)? This was a lively discussion, please add more thoughts in the comments below!
While it’s been a fairly quiet (some might say too quiet) and smooth release, @chanthaboune encouraged the hosting (and greater) community to check-in with support folks and report back any trends. @johnbillion also noted a handful of tickets about Widgets have been opened related to “widget customisation and logic plugins.”
Watch For
WordPress 5.8 release reflection and retrospective.
As the project has landed in core, there is now a new tracking issue set up for things identified by the community as great follow up work to improve on it.
Mobile Team
Shipping: Block picker search and first iteration of the embed block will be shipping in the next release.
In Progress: Scoping the next phase of Global Style Support work focusing on text-related styles.
Cropping for the site logo needs reviewers PR: 31607.
Working on duotone enhancements we can discuss more during open floor PR: 33466.
Related bug fix for cover block spacing ui PR: 33560.
Open Floor
A test file was added to WP Core in 5.6.0, but added incorrectly, which means that the tests effectively were never run. I’m trying to fix that, but am now finding that 7 out of the 20 tests are failing. Raised by @jrf
We need someone with good knowledge of global styles to help figuring out if the test’s problem is on the PHP or JS side of the global styles.
This is probably a bug introduced by the recent work on the “select all” behavior in the block editor.
@ntsekouras surfaced a problem in PR: 1483 – It seems there will be the need for WP version check in patterns
The problem lies that patterns can have blocks with shape that is not supported in a WP version, but themes are also checked against WP version that are compatible. This isn’t the same WP version usually.
Add new arguments to hook_extra passed by plugin and theme updates to ensure we can rollback to the correct version.
After a plugin/theme is successfully downloaded and extracted, the old plugin/theme folder is moved to wp-content/upgrade/rollback/plugins/PLUGIN or wp-content/upgrade/themes/THEMEwp-content/upgrade/rollback/themes/THEME(thanks Paul Bigai for catching that)
If the plugin/theme was successfully installed, the backup of the previous version we kept in wp-content/upgrade/rollback/ is deleted.
If the plugin/theme was not successfully installed, then we cleanup any remnants of files in wp-content/plugins/PLUGIN (or the corresponding folder for themes), and then we move the backup we kept in the rollbacks folder back to its original location.
Adds info in the site-health screen, to make sure the rollback folder is writable (or can be created if it doesn’t exist)
That is the basic concept. The team ran some tests, helped by @peona as well and it seems to be working.
The main difference with the rollback-update-failure plugin is that this solution moves the plugin/theme folders instead of zipping/unzipping them. This change should help to make the implementation a bit lighter/safer on shared hosts with limited resources.
Before moving forward, I would like to ask the Upgrade/Install Maintainers to have a look at this and discuss together, in the comments of this post, if you agree with this change, if it works, etc…
I am not setting a deadline for the comments, but ideally, I would like to be able to write a merge proposal for 5.9 so I will review the post in mid-JulyAugust (thanks @meher for pointing out that we are at the end of July already 😂) and nudge a bit more 😉
Just my first feedback there are any plans like a filter to disable the rollback feature?
I am looking this as security stuff, as usually you update to remove old versions of themes or plugins affected. Also if they are not enabled they can be sources of troubles or have php files that can be called outside wordpress.
I think that something that ensure this is required like htaccess rules to disable the execution of those php file is important or zip those files.
The goal of this project is to make the process of updating a plugin or a theme more secure and less prone to errors.
The “rollback” is not something that stays, it’s a temporary backup of the plugin/theme to be updated, and as soon as the update is successfully completed, that backup is deleted from the filesystem. The rollback’s only purpose is so that in case of an update error, we can restore the site to what it previously was without breaking anything.
These “rollback” folders are not exposed to users, ie they can’t say “I want to rollback this plugin to the previous version I had”, it’s just a transient backup which usually has a lifetime of a few seconds (or as long as it takes to perform an update).
The reason this approach doesn’t go with zipping files, is because zipping a large plugin folder requires significant system resources that a low-end shared host may not be able to spare. Moving the folders is fast, requires practically zero resources, and achieves the goal of having a transient backup to restore if the update fails.
WordPress 5.8 is already here, an exciting release marked by the inclusion of many Full Site Editing features that have been big-picture focuses in recent times. Because of this important achievement, in contrast to normal monthly updates, this post seeks to review the status of Full Site Editing and summarize the next high-level focuses within Gutenberg Phase 2.
Full Site Editing is the lighthouse goal for phase 2 of Gutenberg. As such, it’s good to remember it is a collection of projects that allow site editing with blocks, bringing powerful capabilities for a smooth editing experience.
WordPress 5.8 includes some of these Full Site Editing projects and features; while some of them will continue as ongoing focuses for subsequent Gutenberg releases (⚒️), others can be considered stable and enter a maintenance phase (✅)
Without further ado, let’s look at the current status of the milestones that have guided Full Site Editing work in the last months and the updated scope for Site Editing.
The Site Editing Infrastructure and UI provide foundational work for the rest of FSE projects, mainly in the Site/Template Editor, Template parts, and the numerous APIs that support work around Full Site Editing.
The first two iterations of the site editor milestone introduced editing block themes and all their template files. The ongoing third one offers the possibility of creating custom block templates in classic themes and is available in WordPress 5.8 for those themes that opt-in to the site editing experience. Work will continue to finalize the Site Editor naming and placement: the current Site Editor as we know it in the Gutenberg plugin may evolve for better navigation flows and interactions.
Thanks to feedback from different FSE Outreach Program testing rounds, the next focus for site experience and tooling improvement include:
Global Styles comprises two major areas that fall underneath the global styles umbrella: centralized theme configuration and an interface for manipulating visual aspects of blocks globally.
Theme configuration absorbs things like declaring color palettes, presets, different supports and settings, and toggle on or off the available block design tools (typography, colors, dimensions, etc.). All of this can be managed through the theme.json configuration file and is one of the key features available in WordPress 5.8. After a few iterations and open testing, this feature is considered stable and moved to a maintenance phase.
The other major part of global styles is the user interface to make edits to blocks globally. With theme.json in place, the next release cycle will have the Global Styles UI as one of its main focuses, allowing users to tweak the theme easily. Color handling will be an important focus, not only to better theme switch but also to seamlessly integrate color palettes with patterns.
To support the theme building needs outside of the template and template parts infrastructure, there was a need to create many new blocks centered around theme functions. WordPress 5.8 brings several of these blocks, from Site Title, Site Tagline, and Site Logo that allow users to configure site settings with blocks, to the post-related blocks such as Post Title and Post Date, to be used inside a Query Loop to display post data.
Although new theme blocks may be added as the need arises and the existing ones will receive incremental upgrades, the basics of this milestone are complete.
Among the theme blocks, the Query Loop Block has been a significant area of the site editing focus in the past months, deserving its own milestone. Taking some of the block API infrastructures to the limit, such a powerful block has proven challenging to expose at a user level. As a result of the feedback collected in the FSE Outreach Program, the block has been renamed to clear confusion, and usability enhancements have been implemented before launching it in WordPress 5.8.
With the Query Loop foundations in place, the next iterations will seek to ease the user interactions and flows, even more, thanks to two fundamental Gutenberg tools – block patterns and block variations. The former will continue to help set the inner block structure and content. In contrast, the latter will present the powerful Query Loop’s features in the form of preconfigured blocks and consolidate similar blocks to use the Query Loop Block as their underlying mechanism.
Along with the Query Loop Block, the Navigation Block is another theme block that stands out as a project in its own right. This block has seen great improvements in the last few months, from improved overlays to responsive menus. New blocks are available as well, such as the Home Link block. Shortly, we will see the Navigation block house whole new kinds of blocks thanks to the recent frontend markup adjustments that allow blocks other than links in an accessible way.
Full Site Editing represents a new paradigm in site and theme building in the well-established WordPress ecosystem, and as such, providing the right tools is key to gradual adoption. Tools like the Widgets Editor and Navigation Editor bring block editing capabilities to traditional features that can’t take full advantage of their native block counterpart implementation.
WordPress 5.8 brings the power of blocks to both the Block Widgets Editor and the Customizer. Users will be able to add blocks in widget areas, add widgets and blocks with live preview, and schedule and share directly from the Customizer.
On the other hand, the Navigation Editor has also seen its share of iterative improvements in the last months. Together with the Navigation Block, it will remain an ongoing focus for the next WordPress release cycle.
As mentioned with regards to Query and Navigation blocks, the complexity of the editor increases as site editing capabilities are introduced with advanced block structures and customization options. This highlights the need to expand our APIs and interactions — which are well suited for simple block structures — to better support container blocks.
Another challenging editing experience with the increased number of container and inner blocks is adjusting parent block settings when editing a child block. Users often need to switch between different child and parent blocks to change settings like layout or positioning. In turn, it is necessary to explore Toolbar absorption mechanisms that allow parent blocks to expose their toolbar on their children.
Patterns everywhere
At this stage, it is no secret that block patterns represent considerable potential for users to add many blocks with different preset layouts and settings easily. By using patterns, users don’t need to individually add blocks to achieve rich representations in headers, columns, or Query blocks, as patterns act as a jumpstart blueprint that can be tweaked and adjusted to the user’s needs.
An example of the improved interaction block patterns is demonstrated by the Query block, which allows users to select block patterns in its placeholder state. This is just the tip of the iceberg in terms of the ways patterns can leverage the editing experience, and as such, efforts will continue improving pattern insertion capabilities.
Thanks to the recently released Block Pattern Directory, patterns can be copied and pasted into the block editor; upcoming Gutenberg iterations will connect and retrieve patterns from this directory, allowing users to choose from huge amounts of beautiful patterns without leaving the editor. Both to ease navigating the big number of patterns users will be able to choose from and accommodate increased pattern complexity and richness, such as in Query or Header patterns, revisiting the pattern insertion UI will be an ongoing focus in the months to come.
Several design tools are needed to ensure a wide range of exquisitely crafted patterns can support powerful settings and rich block customizations. These encompass all tools related to the appearance of blocks and range from colors, typography, alignments, and positioning to filters like duotone, cropping, and background media and will need to integrate seamlessly with theme.json mechanics.
Going further, controls like font size, even if exposed as single values to users in the UI, are built behind the scenes to accommodate different viewport ranges. Apart from providing access to the underlying mechanisms through theme.json, responsive-previewing and device-specific editing will be necessary to support this.
To support the ever-increasing number of tools, the sidebar, while secondary in some regards to the block canvas and toolbar, will need to accommodate many of these tools, whereas the Component System will provide a shared design language between all these controls.
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 on 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 #core-editor chats. While we can’t promise to fix everything, we’d appreciate being aware of any blockers.
As far as I can tell, that has already been done. For instance, the filter block_categories_all was adding in 5.8 and is in the Code Reference.
Thanks @pbiron, marking this as checked alongside the update of the history page since I took care of that task ✅