| active ongoing | Site Editor/Templates Experience [Phase 2] |
| The Site Editor/Template experience allows you to edit all parts of your site with blocks by offering access to various templates, a Styles system, navigation features, and more. The largest amount of remaining work is around clarifying the user experience of editing global concepts (styles, templates, navigation) from specific site content, aligning page editing features in the Site Editor and Post Editor, and ensuring simple site setup actions are properly surfaced. |
| active ongoing | Block Themes [Phase 2] |
| With the foundation of block Block 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. themes set, efforts are focused on improving theme switching, expanding design tools, and expanding functionality, like the ability to save drafts and schedule changes. |
| active ongoing | Navigation Block/Menu Management [Phase 2] |
| The Navigation block seeks to replicate and expand what’s possible for visually building your navigation for your site. Included in this effort is a way to preserve navigation while switching themes, the ability to set a custom menu for smaller devices, the option to style current menu item styles, more. |
| active ongoing | Query Loop Block [Phase 2] |
| The Query Loop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. block is an advanced block that allows you to display posts based on specified parameters; like a PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher loop without the code. Since it needs to balance both usability and functionality, work remains to refine and expand the current experience. |
| active ongoing | Styles Engine [Phase 2] |
| The goal of this project is to have a consistent API An 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. for rendering styling for blocks, across both client-side and server-side applications. Currently, it offers a single, centralized agent responsible for generating block styles, and, in later phases, it will also assume the responsibility of processing and rendering optimized frontend CSS Cascading Style Sheets.. The initial package was introduced in WordPress 6.1.For more information about the roadmap, please refer to Block editor styles: initiatives and goals and the Github project board. |
| active ongoing | Gradual Adoption |
| As folks step into site editing, various pathways need to be built to make it easier to adopt these new features. The work involved here is vast including offering more curation options (ex: Locking API), allowing classic themes to have access to Patterns, adding support for appearance tools, and more. |
| active ongoing | Fonts API [Phase 2] |
| This API’s job is to provide the backend capabilities to support the “font library” to include font management and dynamic building of the @font-face styles. The “font library” feature will continue to be built, refined, stabilized, and tuned over multiple WordPress releases. |
| active ongoing | Patterns [Phase 2] |
| Patterns are collections of predefined blocks that you can insert into posts and pages and then customize with your own content. Similar to blocks, they touch on many different parts of the current editor experience. As a result, this work includes exploring patterns as sectioning elements, scaling the experience of managing many patterns, leveling up WordPress.org patterns, pattern overrides (formerly referred to as “partially synced patterns”), unifying patterns and template parts, and more. |
| active ongoing | Design tools [Phase 2] |
| Design tools encompass all tools related to the appearance of blocks and ranges from colors, typography, alignments, and positioning, to filters like duotone, cropping, and background media. This work involves both the creation of shared tools and the consistent application across blocks, as makes sense. |
| active | Performance |
| The Performance Lab plugin from the core performance team is a collection of plugins focused on enhancing performance of your site, with the goal of eventually merging them into WordPress core. The plugin allows one to individually enable and test the plugins to get their benefits before they become available in WordPress core, and to provide feedback to further improve the solutions. Currently focused on JavaScript, Images, Infrastructure, Object Caching, Measurement, and Site Health. 2024 roadmap. GitHub Project. Make posts. |
| active experimental | Collaborative editing [Phase 3] |
| One of the pillars of phase 3 of the Gutenberg roadmap, there are a few aims in this effort: to allow multiple users to simultaneously collaborate on content, enable offline editing and synchronization of data, and offer a great developer experience where developers are freed from thinking about collaborative editing needs. An experimental and minimal sync package has been merged to further this work with the option to enable it as an experiment in the Gutenberg plugin. |
| active ongoing | Command Palette [Phase 3] |
| WordPress 6.3 introduced a global search & command component that’s extensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. and can accommodate navigating across the Site Editor (example: edit About page), Post Editor (example: toggle on distraction free mode), and running contextual commands (example: create new post; insert pattern; etc). Work remains to explore navigating to admin (and super admin) sections (example: go to WooCommerce orders) and expose the command palette across the WordPress experience. As AI tools are taking the world by storm, this could also play an important role in letting plugin authors integrate novel solutions that are prompt based in nature. |
| active in progress | Admin Redesign [Phase 3] |
| Early design ideas and thoughts have been shared to begin the process for an admin design update and navigation work, with plugins and customized user flows in mind. Admin notices and the UI User interface library of design components will be a major part of this effort to ensure use cases are supported while respecting the user experience. This work also includes improving the admin list views (those used in posts, pages, categories, templates, comments, and by hundreds of plugins) with a more modern design and refined extensibility support for interactivity. Efforts are underway to improve these views and provide customized flows, starting in the Site Editor and expanding outward from there. |
| active in progress | Media Library [Phase 3] |
| Another pillar of phase 3 of the Gutenberg roadmap, there are a few aims in this effort: Expand and improve media management capabilities, unify interfaces, and improve overall media flows. |
| active not started | Asynchronous collaboration & Workflows [Phase 3] |
| Work in this area of phase 3 centers around the need to provide seamless collaboration in the editorial process, from draft to publication, and currently exists in very early stages with key areas scoped out. This involves features like comments, peer review, and customizable publishing workflows, easy sharing of various content types while controlling access through permissions, and the ability to mark incomplete elements for team members. The tools developed should support a range of use cases, from individual authors seeking feedback to larger editorial teams managing complex workflows. Please read the introductory post about the scope of this effort for more information. |
| active not started | Revisions [Phase 3] |
| Collaboration workflows as part of phase 3 efforts require revisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. and edit history to be clear, usable, and performant. The design of the traditional post revisions interface needs to evolve to become fully aware of blocks with visual comparisons and easy mechanisms for spotting changes regardless of the content type being shown. The bulk of the work has not started beyond initial efforts to improve style revisions in the Site Editor. Please read the introductory post about the scope of this effort for more information. |
| active in progress | Block Library [Phase 3] |
| Building on phase 2 and the way blocks can be used to express all parts of a site, attention needs to turn for phase 3 to improve the way blocks can be organized, listed, and installed by users. The overall goal is to improve how block management works outside the editors — for example, by allowing the disabling of blocks globally across a site, not just as user preferences. This work also includes a current focus on formalizing a connection between blocks and meta fields to empower building flexibility while retaining user clarity. Please read the introductory post about the scope of this effort for more information. |
| active ongoing | Interactivity API |
| The Interactivity API aims to be a standard way to allow developers to add interactivity to the frontend of their blocks. A standard makes it easier for developers to create rich, interactive user experiences, from simple cases like counters or popups to more complex features like instant page navigation, instant search, or carts and checkouts. For more context on the API, please read the prior proposal. |
| active | Preferred Languages |
| The initial project will cover an extensible backend implementation as well as a single frontend use case. Lead: @swissspidy. Make posts. |
| active | WP Notify |
| The WP Notify project is working towards creating a new (better) way to manage and deliver notifications to the relevant audience. Traditionally, WordPress core and theme/plugin developers have been using the admin_notices hook for this purpose, but this solution is lackluster at best and comes with a lot of disadvantages. WP Notify strives to solve those problems. Lead: @psykro. Make Posts, #feature-notifications Slack channel |
| active | 2FA |
| Two-Factor Authentication is an exploration of how we can build a stable, extensible functionality for enhancing WordPress login pages via various providers. Lead: @georgestephanis. GitHub repo, Make posts, #core-passwords Slack channel. |
| active | Rollback Update Failure |
| When a core auto-update fails, core has long had the ability to automatically attempt a “rollback” to the latest stable release (in the branch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". that the site is running). Note: for core auto-updates, “rollback” is not attempted for certain failures (e.g. “disk full”). This project aims to extend this capability to be available for plugin and theme updates. Join the Call for Testing and check out ticket Created for both bug reports and feature development on the bug tracker. #51857. |
| active | Plugin Dependencies |
| Some plugins require other plugins. When the required plugin isn’t available/installed, site owners are often presented with notices or other indications. The implementation of these notices changes depending on the plugin author. This project aims to provide a unified approach to indicate plugin dependencies and any installed and active dependent plugins. Follow the development in ticket #22316. |