WordPress 7.1 real-time collaboration: the second attempt, the FSE-style outreach program, and the eight-week deadline

Real-time collaboration is getting a second run at WordPress core. Two weeks before WordPress 7.0 shipped, the contributor team pulled what was supposed to be the headline feature of the release. The reason given at the time was database performance problems that the team could not commit to fixing inside the release window. Six weeks later, the same feature is back on the roadmap for WordPress 7.1, with an FSE-style outreach program kicking off and a release date of August 19 anchoring the calendar.

For agencies running editorial workflows on WordPress, this matters in concrete ways. Multi-author editing is the largest workflow change to core in over a decade. It changes the conflict surface on long-form content, redefines what a “lock” on a post means, and shifts what the block editor is for. The 7.1 attempt also signals how WordPress contribution is changing: an outreach program for what is fundamentally a database architecture question is a new shape for the project.

We watched the announcement, read the make.wordpress.org/core threads, and have been in two of the early outreach conversations. Below is what agencies should know going into the 7.1 cycle.

#What got pulled from 7.0 and why

Real-time collaboration in the block editor needs three things to work at scale: a low-latency presence and cursor channel, a conflict-free merging strategy for block changes, and a storage layer that can hold the merged history without breaking the existing wp_posts and wp_postmeta model.

The presence and cursor channel was solved during the 6.x cycle, using a combination of long-polling and an optional WebSocket transport for sites willing to run the infrastructure. The conflict-free merging strategy landed in the Gutenberg plugin in late 2025 using a CRDT-based approach. The third piece, the storage layer, is where 7.0 broke.

The 7.0 implementation persisted collaboration state in a new table tied to post revisions. On smaller installations, this worked. At the scale of an Automattic test environment running 50,000+ concurrent edits, the writes to the new table created replication lag and lock contention severe enough that the team flagged it as a release blocker. The decision to pull was made in mid-April, two weeks before the 7.0 GA date.

Anne McCarthy’s announcement of the new outreach program acknowledges that the database architecture is still the open question: the team has hypotheses for how to fix it but no committed implementation as of the 7.1 cycle start. That is unusual for a feature being targeted at a release.

#The chicken-and-egg problem

Hosting Team co-rep Amy Kamala summed up the situation in one sentence: “Need testing to make decision, need decision to do testing.”

The architectural choices for the storage layer have very different cost profiles for different hosting environments. A solution that works well on a single-server installation may not survive a load-balanced setup with read replicas. A solution that fits a single-tenant managed-hosting environment may not work on multisite at the scale WordPress.com runs.

The 7.0 cycle attempted to make the architectural decision in advance and then test it. That order failed because the test results invalidated the decision and there was no time to course-correct. The 7.1 cycle is attempting to flip the order: pick the testing scenarios first, validate which architectural variants survive them, and let the surviving variant determine the implementation.

This is the same pattern the Full-Site Editing team used during the 5.8 to 6.0 cycle, when the gap between contributor environment and real-world hosting environments produced repeated regressions. The FSE outreach program created a recruited population of testers running real sites with real plugins, and the program surfaced bugs the contributor team would not have caught in isolation.

Applying the same pattern to real-time collaboration is the new structural move. It is also why hosting companies are being asked to help recruit testers from their managed customer base.

#The outreach program shape

Anne McCarthy’s announcement positions the testing population in three layers:

1. Developer-oriented testing. The existing test cycle. Plugins, themes, REST API surface, performance regressions. Run by contributors and on Automattic infrastructure.
2. Enterprise and deterministic testing. Run with hosting partners on managed customer environments with controlled load. Designed to validate that the storage architecture survives database contention scenarios.
3. Passionate real-world early adopters. The new layer. Recruited from agencies, publishers, and content teams running production WordPress sites with editorial collaboration as a real workflow requirement.

The third layer is where most of the new testing throughput will come from. The outreach explicitly asks for sites where real-time collaboration solves a real problem, not for synthetic test installations.

What testers are being asked for:

• Active editorial workflows with more than one author working concurrently on long-form content
• Willingness to run a release-candidate build against staging environments
• Reporting cycle: weekly check-ins with a structured feedback form
• Bug reports that capture both editor behaviour and database-level metrics from the hosting layer

What testers get:

• Direct line to the contributor team running the feature
• Visibility into the architecture decisions as they are made
• Sponsor recognition for sites who run extended test cycles
• The earliest possible look at what real-time collaboration will mean for their editorial process

For agencies with publisher clients, this is the most direct way to be in the room when the feature is finalised. The agency benefit is not the recognition. It is the engineering preview.

#The August 19 date and why it matters

WordPress 7.1 is scheduled for August 19. That date is not arbitrary. It coincides with WordCamp US in Phoenix, where the release will be celebrated as part of the conference programming. The release date also anchors the entire 7.1 testing calendar.

Working backward from August 19:

• Late July: Release Candidate 1. Feature freeze. RTC must be stable enough for general testing audiences. Database architecture decision must be locked.
• Mid-July: Beta 3. Last opportunity for behaviour changes. Outreach program data should be informing decisions, not initiating them.
• Early July: Beta 2. Last opportunity for non-trivial architecture changes. Hosting partners’ testing data should be in.
• Late June: Beta 1. First broadly tested build. Storage architecture should be committed by now.
• Mid-June: Outreach program ramp. Recruited testers running staging builds. Initial feedback cycle.
• Now (early June): Recruitment. Hosting companies recruiting testers, contributor team scoping outreach material.

Eight weeks is enough time. It is not enough time for an architectural restart. The implication for agencies tracking this: assume the architecture decision will be made by the end of June. If you have a strong opinion or production data that would inform it, get it to the contributor team in the next three weeks.

#What real-time collaboration changes in agency workflows

Set aside the database question for a moment. What does WordPress with real-time collaboration actually look like for agencies?

Three concrete workflow changes that arrive with the feature:

• Editorial review loops collapse. The current WordPress editorial workflow is sequential. Author writes. Editor reviews after author finishes. Author addresses comments. Editor approves. With real-time collaboration, the author and editor can work concurrently. For agencies running editorial calendars for content clients, this reduces the per-article cycle time and changes what billable hours look like.
• Plugin compatibility becomes a live issue. Many of the most-installed editorial plugins assume single-author editing. ACF field saves, Yoast SEO analysis, Rank Math metabox updates, custom taxonomy meta boxes, and a long tail of agency-built plugins all need to be reviewed for concurrent-write safety. The Plugin Review Team has been clear that real-time collaboration will surface plugins with unsafe write patterns.
• The “post lock” UX is replaced. The familiar “this post is currently being edited by…” modal that has shipped since WordPress 3.6 is being deprecated in favour of presence indicators. Users who have been trained on the old behaviour over a decade will need to learn the new pattern. Internal communications and training materials need to be updated.

These changes are not edge cases. They are the day-one user-facing impact of the feature shipping.

#The database architecture question, simplified

The core engineering challenge is straightforward. WordPress stores post content in wp_posts.post_content as a single blob. Revisions create new rows. Real-time collaboration needs to merge concurrent edits into that blob without losing data and without creating runaway revision growth.

The three architectural variants currently under discussion:

1. Append-only operational log. A new table stores individual operations (insert, delete, format change) with timestamps and author IDs. The post_content blob is reconstructed from the operational log on save. Pro: clean conflict resolution. Con: heavy write volume to the new table.
2. Snapshot-plus-deltas. Periodic snapshots of post_content plus delta records between snapshots. Pro: bounded write volume. Con: snapshot timing logic is complex and recovery from missed snapshots is tricky.
3. In-memory merge with periodic persistence. Collaboration state held in memory at the application layer, persisted to post_content and a single revision row at intervals or on explicit save. Pro: low database write volume. Con: requires sticky sessions or a shared cache layer.

Each variant has implications for hosting. Variant 1 stresses the database. Variant 2 stresses the application layer with timing logic. Variant 3 stresses the cache and session infrastructure.

The 7.1 outreach program is being designed to test all three variants against realistic hosting configurations. Which variant survives is the architectural decision the team needs to make by end of June.

#What agencies should do this month

Three concrete moves for agencies running WordPress for publisher or editorial clients.

1. Audit your editorial plugin stack. Every plugin that hooks into save_post, wp_insert_post_data, or block editor meta saves is a concurrent-write candidate. List the plugins, note their authors, and check whether the authors have public statements on RTC compatibility. The ones without statements are the ones to plan around.
2. Volunteer a publisher client for the outreach program. If you have a client with two or more editors working on the same content surface, the outreach team wants that workflow. Volunteering puts your client in the test population and puts you in the room for the architecture conversation. Submission goes through the make.wordpress.org/core post linked from McCarthy’s announcement.
3. Prepare internal training for the post-lock UX change. Even if your clients do not actively use real-time collaboration, the visible change to the “post is locked” behaviour is going to surface support tickets in August. Have a one-page explanation ready.

#The bigger pattern: contribution shape is changing

There is a structural story behind the 7.1 cycle that goes beyond the feature.

For most of its history, WordPress core development has been driven by contributor decisions tested against contributor environments. The FSE outreach program in the 5.8 to 6.0 cycle was the first attempt to formally incorporate real-world testing into the core decision loop. The real-time collaboration outreach for 7.1 is the second.

The pattern is that the project is becoming more dependent on input from production environments and less able to land headline features on contributor environments alone. This is the same shift that mature open-source projects go through as their installation base diversifies. It also changes who has influence on direction. Agencies running real client sites with real editorial workflows are increasingly the people whose feedback shapes core. That is a legitimate seat at the table that did not exist a release cycle or two ago.

For Polish and European agencies, the implication is direct: WCEU in Krakow this week is going to host conversations about RTC testing partnerships in the hallway, between sponsored breaks, and over coffee. Show up to those.

#The bottom line

Real-time collaboration is not yet a shipped feature. The database architecture decision has not yet been made. The outreach program is still recruiting. None of this is a done deal.

What is decided: the feature is back on the roadmap, the August 19 release date is the working anchor, the testing strategy has been broadened beyond enterprise and contributor environments, and hosting companies are being asked to help recruit production testers. If the architecture decision lands by end of June and the outreach data validates it, WordPress 7.1 ships the feature at WordCamp US.

For agencies with editorial clients, this is the release cycle to participate in. The shape of multi-author editing in WordPress for the rest of the decade is being defined in the next eight weeks.

The make.wordpress.org/core announcement and outreach program details are at Make WordPress Core. Coverage continues on The Repository and on the WPPoland blog through the 7.1 release.

Last updated: 2026-06-06.