WordPress 7.1 Real-Time Collaboration

Real-time collaboration got a second run at WordPress core, and it missed again. Two weeks before WordPress 7.0 shipped, the contributor team pulled what was supposed to be the headline feature. The reason given was database performance problems they could not commit to fixing inside the release window. Six weeks later the same feature was back on the roadmap for WordPress 7.1, with an FSE-style outreach program and 19 August as the calendar anchor.

WordPress 7.1 Mary Lou shipped on 19 August 2026 without live multi-user editing. That is two consecutive major releases. The rest of this article is the cycle as it stood, plus what agencies should do now that the zip does not contain the feature.

For agencies running editorial workflows on WordPress, the miss matters in concrete ways. Multi-author editing would still be the largest workflow change to core in over a decade. It would change the conflict surface on long-form content, redefine what a lock on a post means, and shift what the block editor is for. None of that arrived in 7.1. Do not train clients on a post-lock replacement that is not there.

#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 19 August date, and what it actually delivered

WordPress 7.1 Mary Lou shipped on 19 August at WordCamp US in Phoenix. The date held. Real-time collaboration did not. The testing calendar below is the cycle as it was planned in June, kept here because it shows how little room an architectural restart ever had.

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.
• Early June: Recruitment. That was the plan. Hosting companies were asked to recruit testers. The feature still missed the zip.

Eight weeks was enough time for a locked architecture. It was not enough time for an architectural restart. The architecture decision was still open when the cycle started. 7.1 shipped without the feature. 7.2 is currently targeted for 9 December 2026. Treat that as a planning date, not as RTC.

#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 would be replaced. The familiar “this post is currently being edited by…” modal that has shipped since WordPress 3.6 would give way to presence indicators. That did not happen in 7.1. The old modal is still what users see.

These changes are not edge cases. They are the day-one user-facing impact if the feature ever ships. It did not ship in 7.1, so none of this is a 19 August support ticket. Keep the plugin audit. Do not rewrite training materials for a UX that is not in core.

#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 was meant to test those variants against realistic hosting configurations. The architectural decision was supposed to land by the end of June. It did not land in time. 7.1 shipped without RTC.

#What agencies should do now

Three concrete moves after the 7.1 miss.

1. Do not promise clients live multi-user editing on 7.1. It is not there. Sequential editorial workflow is still the product.
2. Audit your editorial plugin stack anyway. Every plugin that hooks into save_post, wp_insert_post_data, or block editor meta saves is a concurrent-write candidate for whenever RTC returns. The list is useful even if the feature is a cycle away.
3. Do not rewrite post-lock training for August. The “this post is currently being edited by” modal is still the 7.1 behaviour. Save the one-pager until a field guide says presence indicators shipped.

#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 WCEU hallway conversations in June were the testing-partnership pitch. That pitch did not produce a 7.1 ship. The next date on the calendar is 7.2, currently targeted for 9 December 2026 alongside State of the Word. Show up to those conversations with production data, not with a sales slide that says RTC is in core.

#CRDT vs. Operational Transformation (OT): The Core Dilemma

The technical roadblock stalling real-time collaboration centers on fundamental algorithmic models:

• Conflict-free Replicated Data Types (CRDT): Frameworks like Yjs and Automerge resolve concurrent textual edits deterministically without a central orchestrator. While ideal for peer-to-peer applications, CRDTs incur non-trivial memory overhead when tracking extensive character histories in browser contexts.
• Operational Transformation (OT): The centralized approach pioneered by Google Docs relies on a single authoritative server to transform operations chronologically. This aligns poorly with shared PHP hosting environments lacking persistent execution daemons.
• Mapping to WordPress MySQL schemas: Reconciling fine-grained delta operations with the monolithic post_content text blob without inducing revision table bloat proved impossible to finalize before the 7.1 feature freeze.

#Infrastructure Strain: WebSockets vs. PHP-FPM Concurrency

Standard WordPress hosting architecture is ill-equipped for persistent socket connections:

• Synchronous lifecycle bottlenecks: PHP-FPM processes terminate immediately upon sending responses. Maintaining thousands of concurrent WebSocket connections for real-time presence indicators necessitates asynchronous sidecars (Node.js, Go, or Cloudflare Workers).
• Presence and awareness broadcasting: Streaming cursor coordinates and active block selections generates continuous telemetry that overwhelms unoptimized database backends.

#The Third-Party Plugin Concurrency Challenge

Extending real-time collaboration beyond core blocks exposes systemic vulnerabilities in popular ecosystem plugins:

• Metabox race conditions: When two authors simultaneously modify an article containing Advanced Custom Fields or Rank Math metaboxes, standard full-payload form submissions overwrite concurrent mutations. Ecosystem plugins must transition toward granular, field-level REST endpoints.
• Offloading parsing to Web Workers: Heavy algorithmic tasks—such as live readability grading or automated link suggestions—must be decoupled into dedicated Web Workers to ensure input latency remains under 16ms during fast-paced collaborative typing sessions. Rigorous engineering standards protect data integrity and empower modern editorial workflows.

#Strategic Outlook for WordPress 7.2 and Beyond

The delay of real-time collaboration into the WordPress 7.2 release cycle underscores the architectural maturity of the open-source governance process:

• Prioritizing stability over hasty release dates: For enterprise publishing platforms, an unhurried, thoroughly audited synchronization engine is vastly preferable to an unstable feature causing data loss or database corruption in production environments.
• Collaborative standards for the open web: As distributed development progresses toward State of the Word 2026, continuous contribution from hosting providers and agencies ensures that real-time multi-user editing will launch with the resilience enterprise clients demand. Investing in patient, rigorous systems engineering safeguards the foundational integrity of the world’s most widely adopted content management platform. Professional software craftsmanship guarantees lasting digital success across global markets.

#The bottom line

Real-time collaboration is not a shipped feature. It missed 7.0 and it missed 7.1. The database architecture decision was not locked in time. The outreach program did not get the feature over the line.

What is decided: 7.1 Mary Lou shipped on 19 August without live multi-user editing. Sequential editorial workflow is still what you run. Watch Make WordPress Core for whatever 7.2 actually lists. Do not treat a December target as a ship date.

The make.wordpress.org/core threads remain the primary source. Coverage of what 7.1 did ship is on the 7.1 roadmap note.

Last updated: 2026-06-06.