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.
About a year ago, some early notions of how we could evolve the admin experience were shared. The site editor, and the foundation set by its fluid browsing and editing flows, provides a pathway for revitalising the adminadmin(and super admin) experience. Given all the workflows and collaboration requirements through the upcoming phase 3 projects, it’s time to look more in depth at these ideas and where they might lead.
There are multiple goals to account for with this effort. The state of the art and user expectations for digital software are constantly changing and there’s a tangible need to revitalize the wp-admin design, improve its visual clarity, reduce cognitive weight, better support user workflows, and expand the personalization of the interface. WordPress thrives within its flexibility and its 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 ecosystem. The counter part to that can often be a complicated information density, particularly at the top level navigation, which can negatively affect the user experience — we’ve all seen admin dashboards with very long and daunting sidebars!
As WordPress turns twenty years old, the overall aim of this work is to improve upon this experience at a foundational design level, giving plugins and users more control over the navigation while ensuring each WordPress experience is recognizable, intuitive, accessible, and delightful.
So how can we design the overall admin in such a way that it can be shaped to any need, regardless of their simplicity or sophistication? How can we then manage complexity without being complicated? How can we make designing and building great interfaces on the platform easier and more expressive to usher it through the next two decades? This balance cannot just be achieved with good practices but needs to be reflected in the semantics and the design of the software itself. For example, offering a way to customize the most important menu items at the highest level might allow both a blogger and a commerce store manager to have the best possible experiences, without trading compromises. Shaping WordPress to the particular needs of each person and project can be a large part of ensuring its continued long term success as the operating system of the web, democratizing access, and championing a diversity of experiences. The challenge is doing it without sacrificing the important aspect of good defaults and the “it just works” ethos.
In order to achieve this we’d want to clarify some of the main extension points as semantically as possible. What structures and surfaces does WordPress provide so that plugins and platforms can make use of them to achieve their visions? What does it mean to register settings, sections, or to add blocks? What elements of the interface are relevant? How can they be navigated? This is crucial to establish not just for ease of development but to ensure a usable and accessible experience for all.
This effort is also an opportunity to formalize the design primitives and interaction paradigms that are part of the UIUIUser interface component system begun in wordpress/components. A crucial aspect is to ensure WordPress itself is built with the same pieces and APIs that plugin authors can use. Aside from color themes, our set of primitive components also need to work in dense environments like the editor, as well as environments that need more breathing room and focus like admin sections. Density, clarity, usability, and accessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) are paramount. A related discussion can be found here. As part of leveraging the components across the admin interface, we need to address functional gaps (like table and list views, bulk editing operations, etc) and assist plugin needs for anything that might not be already addressed that should be addressed. Ultimately, the design library needs to be showcased in the wordpress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ website as a clear resource for people building upon WordPress. A great developer experience should naturally guide people to accomplish great and consistent user experiences.
Another primary goal is to achieve a cohesive experience between all editing and management activities. It goes without saying, but navigating through your tasks should feel seamless, whether editing with blocks or managing settings; going through default WordPress sections or plugin areas; or whether the user is operating as an author or an administrator. Considering the space afforded by a malleable browsing experience, combined with the collaboration work, it’s also a good opportunity to look at how offline support might work and its implication for handling optimistic interactive updates to user data. There are a lot of great efforts — from Playground to SQLite — that could also align to provide a fantastic platform experience with all the modern expectations for speed, access, and performance.
Scope
There remain a lot of open questions to work through before going into further technical details but the following should offer an outline of some concrete aspects to consider as more in depth design explorations are done:
Define the structural pieces of the admin experience, from a design and instrumental perspective. Formalize its semantic extensibility. What structures and surfaces does WordPress provide so that plugins and platforms can make use of them to extend and reduce what’s possible?
Restructure admin menu design to support a drill-down interactivity model. Leverage and augment existing APIs for maximum backwards compatibility. Explore using the frame as the encapsulated target destination for existing admin views.
Look into user personalization with the ability to reorganize top level admin menus. It could work in a similar fashion to “pinning” plugin sidebars in 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, where both plugins and users are in control. Also consider coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. sections on the same level so that they could be toggled on or off based on needs.
Deep accessibility support for navigating regions, tuning global preferences (like button text labels over icons across the UI, and other affordances) as part of further refining each user experience according to people’s needs and preferences.
Look at wider deployment of Command Palette across admin sections and formalize its APIs.
Introduce more semantic placement of quick actions: for example, organize all “add new” options and 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.; place notifications, user profile, other top level extension markers, and so on.
Work on completing and evolving the design system gaps. Develop set of components to handle table and list views. Introduce full theme color support. Consider what sort of requirements for SSR are relevant.
Revise the design of general settings views by applying and structuring these components.
Look at the current role of the dashboard home and perhaps embrace admin blocks for improving its widgetWidgetA WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user.-like personalization. Improve built-ins like quick posts, post formats, and title-less posts as outlined in the workflows project.
Connect with notifications project and a path for reducing ad hoc notices across the admin.
Look into the implications for multi-site networks and its navigation patterns.
Address the state of front-end admin bar or equivalent.
Contemplate solutions that maintain as much backwards compatibility as possible for admin sections that may never be updated by the original authors.
Get Involved!
Please, share any feedback, ideas, or requests you might have as we embark on this road. Every voice in the WordPress ecosystem should be reflected in this work as we balance all the different needs and expectations.
Now that blocks are able to model and express an entire site, it’s important to improve the way they can be organized, listed, and installed by users. The overall goal is to improve how 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. management works outside the editors — for example, by allowing the disabling of blocks globally across a site, not just as user preferences.
We should connect functionalities that might already exist but are not fully developed as user features yet. For example, the relationship between single blocks, post formats, and custom post types. There’s code built in that tries to coordinate what initial block to show on the editor canvas by checking what’s the default post format (paragraph for standard posts); if the default format was Image a user would see an image block placeholder when creating a new post instead of an empty text prompt. This kind of customization is currently a bit obscure and could be more powerful if it allowed to more easily configure default block type across post types. It should also connect with other workflows like “quick post” interfaces in the dashboard.
It also means introducing more robust permission handling across the various capabilities (block registration, locking, etc) so administrators can define what blocks are available for different user roles (or even what capabilities of individual blocks are to be exposed). The fact that theme.json files are inherently composable should allow for more granular handlings of capabilities in a systematic way. For example, consider a fictional author.theme.json that sets, disables, and controls what tools and settings are available for authors over the root config file.
There are a couple important block API items to list that can have consequences on user flows as well. One example is to introduce an auto-insert mechanism so that plugins can better interact with the site document (and block trees) in a way that respects user control.
Furthermore, as part of the ongoing work on patterns, it’s time to start formalizing a connection between blocks and meta fields to empower building flexibility while retaining user clarity. For example, it should be possible for an administrator to set up a custom post typeCustom Post TypeWordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept., powered by a block pattern, where each individual block has content attributes connected to a specific metaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. field rather than post content. All could be accomplished within the block editor interface.
Finally, it’s also important to improve how installing blocks from the directory works, how we handle missing block types and reinstallation, how themes and patterns could reference third party blocks, etc. This also implies better visualizations of blocks introduced by larger plugins.
Scope
This is a summary of the broad tasks we need to look into:
Add a section next to, or under, plugins to manage blocks globally. This means expanding the current block manager to allow enabling and disabling blocks across a site.
Introduce more robust permission handling so administrators can define what blocks are available for different user roles.
Create auto-insert 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. and 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. flows for block types. This is a developer tool with user flow implications.
Improve the mechanics of the block directory with better visualization of blocks bundled in plugins and better flows for themes and patterns using third party blocks on templates.
Develop API integrations for mapping attributes to custom fields using the editor interface. The idea being blocks can provide a native UIUIUser interface for managing and introducing meta data through its attributes layer.
Allow managing categories for saved patterns. Expose other pattern APIs, like block type or parent dependencies in the user flows.
Develop the concept of “partially synced patterns”. These allows the design layout and the style properties to remain global while the content can be locally customized.
Extensive application of 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 on groups of blocks (control settings and styles on specific templates, parts, patterns). Explore full theme.json settings objects on a per user role.
Get Involved!
Join the conversation if you have thoughts or feedback about ways to improve the workflows around blocks.
The media library has been an area of slow iteration during the first phases of 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. It’s time to put more focus on it. The main goals are to expand the media management capabilities, unify the block edit and single media interfaces, and improve upon the major media flows.
On the management side, it’s time to look at categorization and tagging, better handling of attached media, design improvements to the library views and filtering. Several important functionalities are already present but not presented in the best way. For example, media attachment functionality (items anchored to a specific post) is often hard to discover, the interface is not the most intuitive, and the connection doesn’t necessarily carry through other editing flows in a clear way. For larger teams, media ingestion can often be an entirely separate process from writing posts. The ability to bulk attach media files and connect them to the relevant content pieces is thus an important part of the collaborative process.
We should also revamp the image editing interface and align with the current block editor tools. Cropping tools in particular need to be unified and further improved. Iterate on how users can visualize and toggle between different thumbnails, while reducing the burden on picking the right file size (WordPress should determine that for you at runtime). Review default thumbnail sizes to accommodate current screen sizes distribution. It should also be possible to set a non-destructive duotone effect directly in the library. It’d be nice to bring UIUIUser interface tools like focus point control to the library flows, so that media objects can store that information and be leveraged automatically when inserting on a cover block, or when using an image on a cropped featured media container.
When managing the media library, it should be easy to check and keep track of attribution. As we look into expanding the presence and touch points of Openverse, it’d be interesting to see how contributions to the commons could work directly from a user’s WordPress install. Another area to look at is improving handling and presentation of other media types (audio, video, files) and their connection with blocks and the block APIs. We should resurface work on a native Playlist block, ideally powered by the Interactivity API.
Finally, we should take a look at the publishing flows for media and format driven posts (where only one block type is present) to allow more expressive freedom.
Scope
Tackle design improvements of the media library elements and see about a path to migrate to wordpress/data and newer UI components. Make it even easier to reuse and connect the media experience anywhere on the adminadmin(and super admin) and blocks plugins.
Look into adding categories and tags support. Explore better browsing organization (for example, date headings and other improvements to the filtering UI).
Improve inline and freeform cropping across block editor and standalone image editing. Connect cropping variations with defining custom aspect ratios across the block UI.
Explore how patterns could be incorporated into media flows. For example, being able to preview a selection of media (or all attached media) within different media patterns quickly.
Connect with Workflows: for example, to require certain steps, such as adding a caption, attribution, alt text, or prevent things like publishing with external images.
Media flows and block integration should be excellent. For example, make blocks aware of attached media so that inserting an image block could automatically display unused media or allow an author to cycle through those without opening the full media library or browsing through an entire collection.
Expose relevant media tools and actions in the command center.
Improve presentation of media in other editing contexts, like showing small media previews in the block list view.
Incorporate featured imageFeatured imageA featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. in the canvas of the post editor when the single template uses a featured image block (this is a lingering task from the site and post editor interface work).
Look at the possibility of supporting other featured media types beyond images.
Improve upon bulk editing operations, including attaching already uploaded media to a post type.
Explore treating focal point as image data and make it available to plugins and blocks.
Allow operations like drag to upload media anywhere on the editor — and then maybe anywhere on the admin.
Follow through on updates to the attachment theme template and single image expand functionality.
Review outstanding tasks on main media blocks (image, gallery, cover, video, audio, file, etc) for enhancements and 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.
Get Involved!
What other improvements would you like to see around the media library experience?
Collaboration workflows require revisionsRevisionsThe 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. It should offer better visual comparison capabilities beyond the classic HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. code diffing, which is getting less and less adequate for illustrating 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. modifications. It should provide easy mechanisms for spotting changes regardless of the content type being shown.
As part of improving the overall experience, we should also go beyond document level history and explore how the interface could let users browse through single block changes and offer the ability to restore them individually rather than requiring full post restores. For global styles, we should evolve the revisions panel to allow comparing two revisions side by side. For synced patterns, we could allow browsing edit history with side by side and overlay comparison tools.
There’s also a semantic overlap between conflictconflictA conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. resolution in real-time collaboration, offline reconciliation, and restoring or managing edit history. At the same time, internal revisions in WordPress are not a replacement for version controlversion controlA version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories. systems, so there has to be points of contact to ensure developers can lift from or deployDeployLaunching code from a local development environment to the production web server, so that it's available to visitors. changesets down to the filesystem as needed. Plugins should also be able to extend the capabilities and develop more advanced integrations on top of what CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. provides. For example, consider the case of using all the site editor tools but ensuring user modifications are saved back into files so they can be managed by git or svn workflows, including wp-cli integrations. Exploring some of these problems should also help outline what architectural considerations multi-lingual would present in Phase 4 when managing content over all possible site objects.
Finally, we should investigate if we can adapt customize_changeset to orchestrate revision grouping across all new entities and requirements — such as grouping multiple revisions together, reference and orchestrate changes to entities, etc.
Scope
This is a summary of the broad tasks we need to look into:
Design a revisions interface that can better highlight visual differences beyond markup diffing. Align presentation of added & removed content with how edit suggestions might be presented in the other collaborative workflows.
Integrate with blocks. Allow selecting a block (like an image) and see all changes that have occurred to it. It should work out of the box with nested contexts, so if you select a parent it tracks and shows changes across all its children as well. Users should be able to focus at any level within a document.
Make it easy to restore changes on a document or per block basis. For example, reverting some design changes to an embedded pattern but keeping the rest of the post as is, even if the pattern is not synchronized separately. The flows for restoring should be connected with the flows for publishing, so a revision can be made the currently published view.
Explore ways in which branching could work for multi-entity history. For example, site title changes won’t be naturally covered in the edit history of a template that contains a site title block, but it could be referenced through a customizerCustomizerTool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. changeset that connects template revision and discrete entity values. The multi-entity saving flow should evolve to take this into account.
Evaluate any possible shortcomings in storage and performance of the various revision systems if they are to be used broadly (for example, everything going through posts tables).
Improve the visual comparison tools so a user can check their content side by side or using overlays to spot differences. This can be rehearsed on the global styles revisions history and focused pattern views.
Develop more immediate clarity over what properties were changed on certain revisions. For example, on style revisions list if there were changes to color palettes, to typography, etc, to improve the browsing experience.
Explore viability of naming or grouping revisions, particularly for staging changes in the future. Connect “save” area in site editor flows with customize_changeset or equivalent. Keep track and list entity modifications.
Review the revisions extendedpluginPluginA 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 for scheduling updates to already published posts.
Get Involved!
If you are interested in helping improve the revision interfaces and architecture, please join in.
Provide seamless collaboration during the entire editorial process, from draft to publication. Allow users to add comments, suggest edits, and tagtagA directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) other users for peer review. Ensure the interface remains focused on a smooth experience for writers and editors.
Improve the publishing flow by customizing the review process, establishing what needs to be done before a publication is ready. For example, an author could leave empty media blocks in a story they are writing and mark them to be completed by another team member, ensuring the post cannot be published while empty placeholders are still there. This could also include other types of requirements, like word count, fields to be completed, and so on.
Make it straightforward to share different types of content, from posts to design changes, while controlling access through permissions. Connect with the adminadmin(and super admin) notifications project to capture comment reviews and mentions. Build upon improvements to the post revisionsRevisionsThe 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. interface to provide clarity over edit history.
The tools and infrastructure developed need to support simpler use cases (one author sharing previews with friends for feedback) all the way to larger editorial teams, managing deadlines, handoffs, and more sophisticated review processes. Plugins should be able to take it further.
While a lot of this work naturally aligns with unpublished content, it’s also important to consider workflows around already published content and pages.
Scope
This is a summary of the broad tasks we need to look into:
Introduce inline comments on blocks within the editor experience. Explore using comment types to store them. Allow marking comments as resolved. Status of comments also need to fold within individual revisions, so that it’s easy to see what specific edit state a comment refers to. Possible connection with “pending review” functionality.
Explore introducing support for “tasks” in publish flow. These would allow highlighting missing actions before a post is to be published. It can be connected to various post statuses (such as going from “pending review” to “publish” readiness, ability to have pending review status over already published content, or other custom statuses). Individual actions should be highly configurable by users and extensibleExtensibleThis is the ability to add additional functionality to the code. Plugins extend the WordPress core software. by plugins. Tasks can also go beyond publishing and be relevant for other plugins (like marking fulfilled orders in WooCommerce data structures).
Ability to share draft links with permission controls and clear revision browsing. This also extends to previewing and sharing design changes across the entire collection of features of the site editor.
Introduce extension points for in-app previewing. For example, a 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 might want to show how a post looks for subscribers and non-subscribers; with or without ad units; on an RSS feedRSS FeedRSS is an acronym for Real Simple Syndication which is a type of web feed which allows users to access updates to online content in a standardized, computer-readable format. This is the feed. or an email; etc. CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. should provide good mechanics for plugins to hook, control, and modify these views across editors in a way that integrates seamlessly with the editing flows.
Improve multi-entity saving to allow scheduling design changes on 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. themes that can be managed through the various revisions systems (styles, templates, patterns, pages, posts). Possibly allow naming future revisions to better manage and orchestrate changes throughout a site. Preview snapshots of a site before they go live.
Explore hook points for version controlversion controlA version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories. systems to smoothly take over internal revision systems if desired.
Control access with granular permissions for patterns and templates rather than general locking. For example, lock patterns to “content only” for author roles but leave it open for admins.
Consider multi-author support on posts or improve how it can be represented as a side effect of real-time collaboration and revision authorship.
Get Involved!
There’s been a lot of interest from users, developers, agencies, etc, about these set of features. Many have already reached out over the last year and months to share experiences, insights, or existing plugin work to reference. Let’s capture and highlight feedback to ensure all use cases are represented.
The primary aim of real-time collaboration is to build functionality into 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. editors so that concurrent collaboration, shared edits, and online presence of peers are possible. Supporting these workflows is not just about concurrency, though, but also about lifting restrictions that have been present in WordPress for a long time, such as locking a post when two people try to edit at the same time. There are various technical layers underpinning this functionality, so let’s quickly recap what they are and what we need to take into account to get started.
First, these capabilities should be available to the widest possible audience. That means using technologies that don’t rely on sophisticated server setups that would restrict the ability for people to collaborate within their WordPress sites, regardless of hosting infrastructure. This likely puts us on the path of building on top of open web standards like WebRTC where we can ensure deployment of these features without any special burdens on the backend. WordPress itself could provide an easy to scale signalling server, likely over REST endpoints, for authentication handshake.
However, we also want to ensure the system is flexible enough to extend with other server implementations for more advanced needs — such as a WebSockets service — in order to scale beyond current limits for peer-to-peer simultaneous browser connections, or for cases where peer connections cannot be established. This would naturally be 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 territory.
Outside of the peer sharing setup, we also need to establish the primitives for conflictconflictA conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. resolution that are going to be able to reason through our block data structures and orchestrate edits over time. For this purpose, it’s likely Yjs will come in handy, which is an amazing open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. library that implements conflict-free replicated data types (aka CRDTs) presented as shared types. This library has already been put to good success in most of the past explorations within the Gutenberg repo and related projects. The author of the library has also engaged directly in some of these iterations with suggestions and feedback. While it has worked pretty well with block data, it has not been paired with multi-entity documents yet. Furthermore, ongoing SQLite explorations might uncover other ideas and opportunities for wider offline-first experiences where CRDT needs to be handled at a different abstraction layer.
Scope
This is a summary of the broad tasks we need to look into:
Outline the set of 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. necessary to encapsulate collaboration features over block editor providers, like sharing edits and peer state across browsers.
Ensure capabilities build on top of the block 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. so that block authors don’t need to make modifications for their blocks to work in collaborative environments.
Design and represent “presence” of connected peers in the interface. Integrate selection state with other useful parts of the interface, like the block list sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme..
Lift concurrent editing restrictions. Right now WordPress locks a post to the current user that is editing it. Another user can take over, but it doesn’t allow two users working on the same post at the same time.
Review undo / redo stacks and resolution. It’s likely some modifications are needed here.
If employing CRDT, ensure its designed to work with multi-entity documents, which is a newer requirement from Phase 2 compared to just Phase 1.
Employ peer caret and selection primitives that work across block types and design their semantic and visual representation.
Consider offline a first-class use case of collaboration in orchestrating edits and transactions.
Explore the possibility of “following a user” as they work through a document.
Define authentication and messaging semantics. For example, the characteristics of a WebRTC handshake with a plain HTTPHTTPHTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. request to the backend. Provide answers to questions like read only sessions over peer-to-peer connections and cases where peer-connections cannot be established.
Structure WebRTC implementation as an adapter that could be swapped. The architecture should be pluggable so extenders can provide other solutions.
Outline error scenarios and functional overlaps with offline-first capabilities. For example, peers losing a connection while still making edits. We’d want to employ this for same-user resolution should you be editing across different devices as a single user. Handle saving and revision allocation.
Get involved!
If you are interested in the challenges of real time collaboration or want to leave any feedback on the project, please chime in.
Over the last few years, the WordPress project has been transforming the way users create and manage content on their websites. The introduction of blocks and the editing experience surrounding them has provided people with increased flexibility and expressive options.
The 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/ project has undergone several phases since its inception. It began with the introduction of 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 in WordPress 5.0, which allowed users to create and edit content using modular blocks. It then followed with a second phase, bringing the block editing experience to the rest of the site.
As the project evolved, new features were introduced to enhance the user experience further. Patterns, for instance, allowed users to reuse predefined block combinations and layouts, helping streamline the design process. Block themes enabled creators to fully embrace the blocks for an entire website, from headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. to footer. The community’s collaborative spirit has fostered an ever-growing library of resources that empower users to create stunning and highly functional websites.
We are now planning its third phase, which is going to be centered around fostering seamless collaboration, tying together the user experience, and streamlining the content management flows to improve the way creators and teams work together within WordPress.
To accomplish this, we’ll be looking beyond the editors at the rest of the adminadmin(and super admin) experience. This post provides a preliminary outline of the focus areas. These items are not set in stone, and your feedback and contributions are crucial to help shape the direction.
Real-time collaboration. Imagine being able to work together in real-time across all block editors, crafting content and designs seamlessly without being locked out of editing. The goal is to provide all the necessary infrastructure and UIUIUser interface to handle multiple users working together on the same content simultaneously, making it easier to create, edit, and customize web pages and posts as a team.
Asynchronous collaboration. While simultaneous collaboration is a crucial part to unlock, there are multiple workflows that rely on asynchronous collaboration that will also receive attention. Key features include draft sharing for content and design changes, inline block commenting, review assignments, improved version controlversion controlA version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories., and task management. The goal is to enable users and larger teams to collaborate on projects and its different parts at their own pace and based on their workflows.
Publishing flows. This includes the various processes, requirements, and steps involved in creating, editing, reviewing, and publishing content within WordPress. These flows could include features such as editorial requirements, customized goals (accomplish certain number of words or images), task completion prerequisites (set featured imageFeatured imageA featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts.; complete info on block x; etc; before publishing is unlocked), and support for multiple preview contexts (members vs no members, different context for stories, etc). CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. wouldn’t necessary add all the features but provide the necessary infrastructure to define flows that can integrate seamlessly with the editor.
Post revisions interface. Make them more visual, aware of individual blocks, and explore adding the ability to schedule revisionsRevisionsThe 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. across multiple parts of a site. For example, being able to target updates for an event or campaign that might require coordinating the scheduling of multiple content types and resources. This also overlaps with addressing theme switching flows and scheduling that leverage the flexibility of block templates and styles.
Admin design. Begin the process for an admin design update and navigation work, with plugins and customized user flows in mind. Admin notices and the UI 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.
Library. Introduce an admin section or “library” for managing blocks, patterns, styles, and fonts. As part of this work, also look at what improvements can be done to enhance the media library design, interactions, and extensibility.
Develop a global search & command component that’s extensibleExtensibleThis is the ability to add additional functionality to the code. Plugins extend the WordPress core software. and can accommodate navigating to content (example: edit About page); navigating to admin sections (example: go to WooCommerce orders); and running contextual commands (example: create new post; toggle top toolbar; insert pattern; etc). As AI tools are taking the world by storm, this could also play an important role in letting 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 authors integrate novel solutions that are prompt based in nature.
If there’s anything you were hoping to see addressed that’s not yet captured, please share your thoughts in the replies. Keep in mind that there are other active projects related to the prior phases that will continue alongside these newer efforts (i.e.: more blocks, footnotes, better tables, grid layout system, the block 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. roadmap, block development experience, performance, infrastructure like sqlite, playground, etc). For clarity, the phase 3 items shared above are not planned for 6.3.
The end of Phase 2 of the 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/ project is approaching! As we prepare to ship and wrap the final touches, I want to remind us all that this doesn’t mean work on customization is complete. In the same way the post editor continued to evolve after WordPress 5.0, there’s plenty that will get better through refinements and further feedback. However, the overall scope and product experience is coming into place and out of its betaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. state. 🌟
The goal is to approach this final episode in the next two major releases of WordPress, 6.2 and 6.3. For the upcoming 6.2 release, these are some of the major highlights that will get covered:
Add the ability to “Browse” between pages and templates without leaving the editor and allow editing the main site navigation from a high-level perspective without having to edit specific templates.
Overhauled navigation block with easier list-based editing, better fallbacks, and the ability to show dynamic page lists for subpages.
Big updates to Global Styles with the introduction of a mini-preview for each block type; a new Style Book to visualize customizations across the entire 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. library; design tools for editing box shadows; ability to push local block styles to global block styles; custom CSSCSSCascading Style Sheets. support for the whole site and per-block; allow copying (and pasting) block styles between blocks.
That’s on top of hundreds of 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, refinements, 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. improvements, UIUIUser interface component work, and performance enhancements across the board. We’ll follow up with a more in depth review of what’s to come in 6.2 shortly.
This work still leaves out a few important items that are being worked on but are not quite ready to make it into the 6.2 release and will instead move to 6.3 later in the year:
Introduce flows that clarify the Template / Content relationship.
Exposing revisionsRevisionsThe 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. across the full spectrum of tools (templates, parts, patterns, styles).
Access to high level settings (posts per page on relevant blogblog(versus network, site) templates; home page static page; and quick template switching).
Creating and classifying your own pattern library alongside reusable blocks.
Patterns where the content is configurable on a per-instance case but the design and layout is shared and can be globally updated.
It’s time to look ahead at the main areas of work for WordPress 6.1. The tune of the release will be to refine the experiences introduced in 5.9 and 6.0, weave the various flows into more coherent and fulfilling experiences for users, maintainers, and extenders, and close some gaps in functionality as we start to look towards Phase 3 of the 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/ roadmap.
Introduce the ability to browse, visualize, and edit the structure of the site. Provide more clarity between global elements (templates, template parts, styles) with the aim of unifying the template editor and the post editor experiences.
We should be better prepared to fully unlock the potential of patterns as outlined in “Building with Patterns”, which was put together a bit late in the 6.0 cycle. Allow patterns to be a central piece of the creative experience, including tailoring them for custom post types, 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. types, improving the locked down experience, manage saved patterns, etc.
Continue to make progress on the global styles interface while improving the support for restrictions, privileges, and curated presets. Allow managing webfonts, implement responsive typography, and expand the toolset available to blocks with an eye towards consistency, reliability, and delight.
Themes & Gradual Adoption
There are also several issues around the ability to adopt features like template parts gradually on existing themes, as well as the possibility of getting broader access to 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. editing. It’s also important to continue to look towards theme switching flows and how to best make use of the new possibilities of styles and templates.
Yesterday, WordPress 5.9 Joséphine was released with the help of hundreds of contributors and achieving a big milestone for WordPress. It’s now time to start thinking about next steps and the general scope for 6.0. As before, this is meant to be a high level overview of the different areas of focus, not an exhaustive list.
The overall aim is to consolidate and expand the set of customization tools introduced in 5.9 for creating themes with blocks, with a special focus towards usability and refinement. This new release could be considered a conceptual wrap for 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/: Phase 2. This doesn’t mean the customization phase would be concluded with it, but that its main features would have been established.
The introduction of the site editor marked a big milestone but also just a first step in the journey. There are various limitations that need to be lifted and features that didn’t make the cut that need to be revisited. We are also going to be learning a tremendous amount from users now that the initial work is out in the world to be experienced.
Refine the information architecture and template browsing experience. There’s work to be done to better organize the experience of interacting with the site editor, global styles, templates, and navigation as a whole. (36667)
Improve template creation (aiming at never showing disconcerting empty states) and allow the easy creation of more specific templates (i.e: category-$slug). The selection of new templates is artificially constrained right now in the interface. Opening that up should better express the power of the site editor as a web creation tool. (37407)
Expose site structure as “navigation” outside the navigation 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.. This is an important aspect to not limit site navigation editing exclusively to the site canvas, which for many reasons can be initially hidden from view. (36667)
Introduce browse mode to be able to conveniently follow links to different parts of the site. Conversely, the template editor that spawns when editing posts or pages also needs to establish better flows with the site editor. There’s a larger theme of connecting pages and templates to be explored. (23328)
Embrace style alternates driven by 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. variations. This was teased in various videos around the new default theme and should be fully unveiled and presented in 6.0. One of the parallel goals is to create a few distinct variations of TT2 made just with styles. (35619)
Improve post settings design and organization. The sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. has gone without many updates for a while and could use improvements in clarity and design.
Complete the scope of global styles. Introduce easy export & import; support for revisionsRevisionsThe 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.; etc. (27941)
Remove coupling of templates to specific themes. This is crucial for properly embracing the power of block templates. Switching themes should not cause the disappearance of your modified templates. This is also fundamental for offering more granular combinations instead of complete theme swaps, the ability to add new set of templates (relevant for plugins that introduce new templates), or changing individual parts of a site. (See also.)
Explore more advanced drafting and scheduling for the site editor. Some of this work is meant to happen more in depth during Phase 3, which will include more focus on editorial flows, but there’s still some paving steps to implement. (29575, 29388, 31456)
There should also be some room for some minor back to basics around the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. writing experience and further improvements to performance and usability. Areas to keep an eye on are the reliability of undo/redo, keyboard interactions, multi-selection, etc.
Patterns
It’s also time to expand the usability of patterns as a main ingredient when it comes to building pages and sites, now that most of the infrastructure has been established.
Prioritize pattern insertion on template building. This is a proposal to make patterns more central to the experience of creating theme templates and pages. (31153)
Simplify registration of patterns for themes. This might take the shape of a patterns folder with file headers that are automatically registered. All in all, it should be super easy for themes to provide a collection of patterns or to specify starter content as patterns. (36751)
Introduce page patterns for page creation. This has been on the horizon for a while and we should have enough building blocks to tackle it properly. It’s also an occasion to improve upon and align with the new “explore” modal that connects with the patterns directory.
Use patterns as possible transforms for offering “layout” options. Inserting new patterns is just a start, but often you want to change existing content or shapes into new ones. Patterns have some of those mechanisms but they need to be better presented and embraced. (27575)
Blocks
Finalize scope of navigation block and its overlay rendering. The navigation block introduced in 5.9 contains a whole world of customization and opportunities that needs to continue to expand and improve. In addition to the block itself, several flows need to be refined around transporting and initializing block menu data.
Introduce various new blocks to power the display of comments on themes. (34994, 38107)
Allow the featured imageFeatured imageA featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. to be an attribute of other blocks (like Cover, Media & Text, etc) to expand what designs can be achieved.
Allow Quotes and Lists to have child blocks. Some of the current limitations of the writing experience arise from this constraint. (25892)
Improve the Table block. There’s a good design direction to finally implement. (32400)
Explore the viability of inline tokens. This has come up repeatedly in the context of rendering dynamic strings (such as current date) in rich text blocks.
Migrate default block styles into proper style attributes. Continue the work put into global styles by making all systems understand each other.
Pick up the work done for a Table of Contents block.
A lot of progress was made in 5.9 around consolidating the set of design tools and introducing new ones to address major gaps in the experience and providing block authors with simpler ways to register them. For 6.0 there’d be a concerted effort around tightening consistency, introducing more responsive capabilities, and expanding the Supports & Elements 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.. Another important goal is to continue to make it easier for third-party blocks to adopt these tools.
Layout:
Address confusions and shortcomings of layout features (including mindbenders like “inherit layout”). (28356)
Explore more convenient direct manipulation for height and width (alignment distribution) of blocks.
Incorporate more definitive responsive handling (min/max containers) into the current flex-based tools. (34641)
Typography:
Introduce responsive fonts with good defaults. (33543)
Add a Web Fonts API connected with global styles. (37140)
Explore paragraphs with indents and justification with hyphenation as global styles settings.
Elements:
Introduce support for customizing block Captions.
Investigate hover / focus effects and related problems.
Gradual Adoption
Full block themes are at the avant-garde of the WordPress evolution, but work continues to happen to improve how all themes can interact with blocks and make use of the new tools gradually and at their own pace.
Continue to adopt theme.json configuration for non-block themes as it aims to simplify and consolidate support for block properties and their capabilities.
With the “focused template part” editor established there are new opportunities for non-block themes to start incorporating specific areas for blocks using the site editor interface in a more gradual way, when ready to do so. (37943)
Utilize what we have implemented for the navigation block and site structure as the interface to eventually replace the navigation screen.
Explore the flows for creating some dynamic templates with blocks (for example, just the archive), similar to the custom page templates support in classic themes.
Please, help define the work to be done by joining the conversations listed in the issues above or giving feedback!
You must be logged in to post a comment.