The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
WordPress 6.6 is set to be released on July 16, 2024. With a slightly shorter cycle, this release heavily builds on the foundation of the last with some new items, like section styles and overrides in synced patterns, and loads of enhancements to features that landed in the last few releases, including the Font Library and Interactivity APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. Data Views, the first taste of the admin redesign work introduced in 6.5, continues to evolve with new layout options, a combined template part and pattern experience, and more readily accessible management sections. Finally, design tools take center stage with everything from grid layout support to section styles to more power baked into style variations out of the box.
As always, what’s shared here is being actively pursued, but doesn’t necessarily mean each will make it into the final release of WordPress 6.6.
For a more detailed look at the work related to the blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, please refer to the 6.6 board and review the currently open Iteration issues. After a recent organization effort, Iteration issues are meant to reflect active work that’s been scoped down for a major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.. To get a sense of some of what’s being worked on both for this release and beyond, check out the demos shared in a recent hallway hangout.
Foundational experience
Advancing the new Data Views in the Site Editor
Building on an initial launch in 6.5, the new views in the Site Editor continue to be refined and advanced. This includes work to bring the various management pages forward (manage all templates, manage all template parts, manage all pages) so those options are immediately seen when visiting the respective sections, reducing the number of steps to access important information. For pages, a new side by side layout will be introduced so one can see both a list of all pages and a preview of the currently selected page. For patterns, template part management will be removed and integrated into the current overall patterns section. Interspersed within all of these larger changes are smaller enhancements in functionality and feel.
A few different initiatives are coming together to allow one to focus on building with patterns rather than granular block editing, including advancing contentOnly editing and zoomed out view. Key features planned include:
A zoomed out experience in the editor when inserting patterns to facilitate high level overview of the site.
Ability to shuffle top level patterns within a template in order to quickly explore alternative patterns.
Ability to manipulate patterns in the template via moving, deleting, etc while zoomed out.
Improvements to UXUXUser experience for dragging patterns (e.g. vertical displacement).
Taken together, this work aims to offer a first step towards a new way to interact with and build with patterns. Some questions remain including whether zooming out will be invoked in certain situations, like the patterns tab of the Inserter, or if it’s something that could be toggle on/off as one wants.
Knowing where a block’s style comes from is key to knowing where a change might need to be made. For 6.6, work is underway to show locally the value that a block inherits globally, when applicable. This means that, for example, if you set a paragraph to always have blue text in Styles, every paragraph you added will show blue text and the block settings will show the blue color as the chosen text color. This is in contrast to today’s confusing experience, where it shows a circle with a line through it, to indicate that no local color has been set despite the block inheriting it globally.
Unifying editor experiences, including publish flow
This is both a technical and design effort, consolidating shared code and creating a single, coherent flow across the post and site editors for common tasks. The more noticeable and big pieces will be seen in a unified publish flow and a new singular “summary” inspector panel, which will also be reused within the site editor when you are bulk editing.
Mix and match typography and color palettes from all styles variations
Style variations allow you to change the look and feel of your site, all while using the same theme. To build on the design possibilities of a block theme with style variations, 6.6 aims to add the ability to mix and match the color and typography styles of each individual style variations. This means the eight community created style variations baked into the Twenty Twenty-Four theme turns into 48 styling combinations, thanks to the six typography presets and eight color presets available. Add in more typography options thanks to the Font Library and the optionality available is immense, alongside all of the granular tinkering you want to do. This evolution in style variation possibilities will work out of the box with all block themes with style variations with no additional opting in or adjustments on the theme author’s end.
Syncing specific blocks and attributes of patterns
Building upon synced patterns, overrides in synced patterns would allow users to ensure a synced layout and style across patterns while allowing each instance of the pattern to have customized content. This allows for consistency in design across different pieces of content. For instance, consider a testimonial pattern in a grid. With the enhanced feature, someone can insert this testimonial pattern into multiple posts, ensuring that the layout and styling components, such as the overall design of the recipe card, remain consistent across instances. Meanwhile, the content, such as Name, Image, and Role, would be local to each instance allowing for individual customization. Additionally, folks would then be able to revisit and modify the design of the overall testimonial pattern without affecting the content in existing instances. To get a sense of the current work happening here, check out the “overrides in synced patterns” demo from a recent hallway hangout below:
Expanding block style variations for more styling options
Through work to extend the block style variations mechanism, 6.6 is set to introduce the ability for theme authors to define style options for sections of multiple blocks, including inner blocks. With just a few clicks, folks using block themes that add this functionality could quickly change just a section of a page or template to predefined styles that an author provided, like a light or dark version of a section. This feature is coming together thanks to work to expand the block style variations API. There are a few ways folks are aiming to offer this functionality:
Programmatically via gutenberg_register_block_style
By standalone theme.jsonJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. partials within a theme’s /block-styles subdirectory
Via theme style variations defining block style variations under styles.blocks.variations.
Grid is a new layout variation for the Group block that allows you to display the blocks within the group as a grid, offering new flexibility. There are two options for the Grid layout:
“Auto” generates the grid rows and columns automatically using a minimum width for each item.
“Manual” allows specifying the exact number of columns.
Outside of expanding functionality, including trying to implement drag and drop resizing, work is also underway to improve using layout tooling in general to make it simpler and clearer to accomplish what you want.
To build on its debut in 6.5, the Font Library will continue to see bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes and enhancements based on incoming feedback. This work will be less about adding new functionality and more about refining what’s landed.
Bringing the Site Editor experience for Pattern management to Classic Themes
Thanks to some internal code changes, the path is set to enable Classic Themes to have access to the new Patterns experience that the Site Editor provides. This will provide an upgraded, modern experience of managing and creating patterns.
This release cycle, a variety of initiatives are focused on improved loading times, especially template loading with improved caching of theme.json, block templates and computed styles as well as optimizing autoload options. Research and initial work to address potential improvements to the INP (Interaction to next pain) metric is also continuing in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. and the Interactivity API. In addition, ongoing performance improvements for the editor for this release are being tracked in this iteration issue, including major improvements to template loading.
Outside of the above efforts, work continues to improve performance tooling, including our automated performance test actions running in both GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ and core. The current effort is focused on making the performance tests more consistent, robust and reliable and on providing an easy-to-use GitHub action developers can leverage to implement the performance tests in their own pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or theme.
API iterations
Various APIs recently introduced in the last few releases are all slated for continued upgrades.
Interactivity API
The Interactivity API provides a standard way to allow developers to add interactivity to the frontend of their blocks. After the release of the initial version of the Interactivity API in 6.5, this next round of work is focused solely on enhancing the developer experience with better test coverage and code quality, improved error reporting, debugging tools, and fixing reported bugs.
Block HooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.
Introduced in WordPress 6.4 and iterated upon in 6.5, the Block Hooks API is an extensibility mechanism that allows you to dynamically insert blocks into block themes. At this stage of maturity, work is underway to help determine a proper UIUIUser interface for hooked blocks and continued improvements to the developer experience.
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API
Building on the initial launch in 6.2, work continues to evolve the HTML API with a focus on two aims for 6.6:
Complete and rely on a custom and spec-compliant encoder/decoder.
Design how to communicate when an HTML document has retroactively changed, allow calling code to match on, stop at, and modify implicitly-created elements, including when elements are closed.
The Block Bindings API launched in 6.5 allows you to bind dynamic data to block attributes, solving many use cases for custom blocks and powering other features, like overrides in synced patterns. This next round of work is focused on allowing the editing of connected sources directly from the block. As showcased in a recent Hallway Hangout, users can update the value of a custom fieldCustom FieldCustom Field, also referred to as post meta, is a feature in WordPress. It allows users to add additional information when writing a post, eg contributors’ names, auth. WordPress stores this information as metadata. Users can display this meta data by using template tags in their WordPress themes. by editing the paragraph connected to it. As part of that, the existing editor implementation is being refactored, and the editor APIs are being defined with the goal of “potentially” making them public for 6.6. Outside of the broader technical work, initial explorations are underway around a UI to create bindings, but it’s unlikely to land for 6.6.
Dropping support for PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 7.0 and 7.1
Support for PHP 7.0 and 7.1 will be dropped in WordPress 6.6, scheduled for release in July 2024. The new minimum supported version of PHP will be 7.2.24. The recommended version of PHP remains at 7.4 or greater. Read more in the Dropping Support for PHP 7.1 Make Core post.
Add rollbacks to auto-updates
Since WordPress 6.3, when an administrator is manually updating plugins, the plugin will not be reactivated if the update causes a PHP fatal error. During an auto-update, this reactivation check does not occur and the next time the site runs users will see the white screen of death (WSOD). To further protect websites and increase confidence in automatic plugin updates, 6.6 aims to include the ability to perform rollbacks when fatal errors occur during attempted plugin auto-updates by default. To learn more, please review the merge proposal for this feature.
Find something missing? Want to help?
If you have something you’re working on that you don’t see reflected in this post, please share a comment below so we can all be aware! If you’re reading this and want to help, a great place to start is by looking through each issue associated with each area or by diving into the Polish board where a curated set of issues are in place that anyone can jump in on.
You must be logged in to post a comment.