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.
Want to use collaborative editing on a regular basis.
Enjoy being an early adopter.
Feel comfortable using the latest version 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/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..
Have the ability to participate through the 7.1 cycle (at least until 8/18/26).
Thanks in advance for helping shape the future of this feature.
Why now?
Collaborative features require an inherently collaborative way of testing. For the 7.0 cycle, a lot of time and effort was spent with more developer oriented testing, enterprise level testing, and deterministic testing with hosts. While incredibly useful, this effort broadens the scope of testing by bringing in passionate real-world early adopters across a range of hosting environments and backgrounds. For collaborative editing to truly succeed, it’s important to go beyond just getting stability, performance, and reliability right.
In running the FSE Outreach Program, I saw how powerful it was to have a dedicated space for folks to regularly interact with those building the feature for a faster feedback loopLoopThe 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 in the right direction. After the hard decision was made to remove collaborative editing from WordPress 7.0, the aim is that ahead of 7.1 the outreach program model provides enough structure to create meaningful feedback without being too overbearing or exclusive considering the timeframe. This was first discussed in #feature-realtime-collaboration before being brought to project leadership.
Who can join?
Anyone is welcome to join #collaborative-editing-outreach! Real Time Collaboration is included in the latest versions of Gutenberg, and can be enabled under `Settings > Writing` in the dashboard when the Gutenberg plugin is active.
It’s critical people from across different hosting environments and use cases are a part of this, from nonprofits to small businesses to newsrooms. If you have a large need for collaborative editing, enjoy sharing feedback, and are comfortable with using the latest Gutenberg plugin, this is an awesome way to contribute to the WordPress project. Test team badges will be given out at the end.
More about the effort
The aim is to engage passionate real-world early adopters across a spread of hosting environments in a dedicated slack channel throughout the release process to ensure a tight feedback loop for both bugs and feature requests. This will take a simple form: a dedicated slack channel (#collaborative-editing-outreach) where folks can get set up with collaborative editing, share ongoing feedback, and those working on the feature can open bugs/make fixes/share improvements/etc. Compared to the FSE Outreach Program, there won’t be ongoing themed calls for testing since they would end up being very repetitive. Instead, key updates will be shared in the slack channel to help inform folks as new fixes or features are added to give feedback on them. The latest updates for collaborative editing will be delivered through the Gutenberg plugin which is why using the latest version is a requirement for this channel. As discussed here, a featured plugin isn’t currently feasible.
Tied to this, outreach will be done to hosting companies to attempt to recruit participants for this outreach program. This is being done to help get as many different environments as possible represented.
Currently, @amykamala, @greenshady, and I will be acting as the small crew driving this forward in the slack channel, alongside the developers and designers working on this feature.
Real-time collaboration—the ability for multiple users to edit the same post simultaneously, similar to Google Docs—is being developed for WordPress 7.0, scheduled for release in 2026. Beginning in October 2025, WordPress VIP customers have had access to a 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. version of real-time collaboration to begin stress-testing the experience across different environments and use cases, informing the work as early as possible. The beta has provided valuable insights into how real-time collaboration performs with production WordPress sites and real editorial workflows. The response has been enthusiastic, with several organizations already enabling the feature in production. If you haven’t seen it already, here’s a demo of the feature in action.
About the research
This post summarizes feedback gathered from 45 beta participants between October and early December 2025. While the issues are being tracked individually under the [Type] Real Time Collaboration label, this summary centralizes the information for easier review and broader transparency. The insights come from:
Direct conversations with technical leads and editorial teams at participating organizations.
Recorded testing sessions and demonstrations.
Written feedback submitted through beta feedback channels.
Observations of production and staging deployments.
Participating organizations span industries including news and media, higher education, research institutions, and enterprise publishing; all are larger organizations with multi-person editorial teams.
Key insight: It just works with modern WordPress
The most consistent feedback: real-time collaboration works seamlessly when sites are built for modern WordPress. Organizations using 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 with native WordPress blocks and custom blocks developed using best practices reported smooth experiences with minimal issues.
One technical lead at a major research institution noted their team has invested in a deep understanding of 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, as a result, “… have not run into any issues.” Their editorial team described the feature as delivering “an amazing workflow change,” eliminating the frustration of kicking colleagues out of posts to make quick edits.
Multiple teams tested the limits by:
Adding dozens of blocks simultaneously.
Copying large amounts of existing content in parallel.
Having entire teams edit the same post together (one team specifically noted “this is so fun”).
In these stress tests with native blocks and modern custom blocks, real-time collaboration held up remarkably well.
Other insights
The value of Notes
The newly released Notes feature generated significant enthusiasm.
One communications team called it “revolutionary.” Teams particularly value the ability to leave contextual feedback directly in the editor without disrupting the editorial flow.
This feedback confirms that collaborative editing is a suite of tools that make it easier for you to create in WordPress from your very first keystroke, not a single feature.
Flexible workflows
Different organizations expressed distinct preferences for how collaboration should work within their editorial processes:
Some teams want flexibility: Publishers aggregating content from distributed teams appreciate the ability for multiple editors to work simultaneously across different sections of a post.
Others prefer predictability: Organizations with established “check-in, check-out” workflows expressed interest in mode controls that would allow them to programmatically determine editing permissions based on user roles and post status.
One organization specifically noted their less technical users might feel “uncomfortable with the shift to a fully collaborative environment, fearing they might step on each other’s toes.”
Teams want the ability to adapt the collaboration model to their existing editorial culture rather than completely restructuring workflows.
Attribution
Multiple organizations emphasized the need for better attribution tracking. Today, when a user saves a revision, you know they made all changes. With real-time collaboration, multiple users can make changes to the same version.
Contributors are working to address this feedback by adding “contributor” metadata for versions. You can follow that work in this GitHub issue.
Where things go wrong
The most significant compatibility issues emerged with blocks storing data in post 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. rather than block attributes, particularly when that post meta isn’t updated using modern methods.
Real-time collaboration works with any post meta that is registered with show_in_rest set to true. Metadata registered this way will participate in the data store that powers real-time collaboration. Legacy metaboxes update meta using other means.
This will be an important area to address for WordPress 7.0. 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 will want to know what work, if any, is required to ensure their code supports real-time collaboration.
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)
The current beta does not meet the accessibility standards expected for WordPress. Providing functional affordances in a real-time environment is challenging, but it is a challenge to be met.
This is an area where help is needed from the Accessibility team. You can report any accessibility issues you encounter on this GitHub tracking issue.
If you want to test the beta for real-time collaboration today, you can follow the instructions in this GitHub repository to set up an environment. You can test locally by editing content in two different browser windows.
Stay tuned for broader dedicated calls for testing and more summaries like this. The aim now is to get everything into Gutenberg trunktrunkA directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. to make it easier for more testing in different environments.
If you have feedback or questions, please comment here. Issues can be added with the [Feature] Real-time Collaboration label on GitHub.
A few weeks ago I put up a survey for each of the contributor teams, with the goal of identifying a rep (or reps) for each contributing group. In most cases I lined up a primary rep and a backup. For core contributorsCore ContributorsCore contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac.
https://core.trac.wordpress.org it was a little different, because we have sub-groups within our group (which is also about 5 times larger than the next biggest contributor group, the theme reviewers).
In the survey for core contributors, I asked how many reps you thought coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. should get to ensure that each core contrib constituency would be represented. Choices ranged from 2 to 4, in varying configurations. There was no overwhelming winner for this question. There were many votes for 4, 3, and 2, though some configurations had more votes than others. I removed the votes from people who have not actually contributed to core, but it was still a pretty even split. That said, across each of the configurations, the same people tending to be chosen for the 1 and 2 spots.
Based on the votes, I propose that the core team repTeam RepA Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. group be made up of Mark Jaquith, Andrew Nacin, Aaron Campbell, and Helen Hou-Sandi, with their backups being Ryan Boren, Daryl Koopersmith, Cristi Burca (scribu), and Mike Schroder (DH-Shredder) respectively.
The primary responsibility of being a rep will be participating in a monthly chat with other contributor group reps starting in May, and communicating things between that group and this one. Backup reps can attend the chat if they wish but are not obligated to do so, unless the primary rep says they can’t make it. Since the core team will have multiple reps, we can work out details later like who’ll post what where and how to get feedback from the people they’re meant to represent.
