WordPress 7.0 introduces a major cornerstone of Gutenberg Phase 3: real-time collaboration.
At the center of it is real-time collaboration (RTC) — the ability for multiple users to edit the same page simultaneously, with live cursors, instant syncing, and inline comments.
It sounds fancy, reminds me Google Wave
But after digging into how this feature works—and how agencies actually use WordPress—
I keep coming back to a different question:
Are we solving the right problem?
The real workflow in agencies
In most real projects:
- Content is drafted in Google Docs - 95% the time
- Reviewed async (comments, Slack, email, Monday) - 99% the time
- Then pasted into WordPress
- Usually one person publishes
Even WordPress itself limits practical collaboration (often just a few users, with performance concerns)
What agencies actually struggle with?
Based on real workflows:
- Clients don’t know where to edit
- Devs spend time hand-holding minor updates
- ACF / Gutenberg creates a gap between:
- what you see
- where you edit
The key philosophical difference
WordPress 7.0 assumes:
Editing is already intuitive → let’s make it collaborative
Real-world workflows vs WordPress 7.0 “real-time collaboration”
On paper, it transforms WordPress into a multi-user, live editing canvas.
But when you map this idea against how websites are actually built today, a gap becomes obvious:
Most real-world workflows are not collaborative inside the CMS—
They are pipeline-driven across tools.
Where RTC doesn’t match reality
1. Design agencies
They already live in tools like Figma.
- Design happens in Figma, not WordPress
- Feedback loops happen in design tools, not CMS
- WordPress is only a handoff + implementation layer
👉 RTC inside WordPress doesn’t fit the design phase at all.
2. Freelancers
Most freelancers work solo or async with clients.
- No real need for simultaneous editing
- Content updates are sequential, not collaborative
- The real pain is client confusion, not multi-user editing
👉 RTC doesn’t solve their daily bottleneck.
3. Large media / enterprise teams
They do have collaboration needs—but their workflow is already structured:
Typical production pipeline:
- Strategy definition
- Content gathering
- Copywriting (often in Google Docs + AI tools)
- Design direction established
- Design mockups created (Figma)
- Stakeholder review cycles
- Design finalized
- Content placed into design files
- Developers translate design into WordPress templates
- Developers define editable areas (ACF / Gutenberg blocks)
- Fields mapped into PHP templates
- Content manually populated
- Staging deployment
- Review → revisions
- Repeat iteration cycles
- Final launch
- Post-launch: minor edits flood in
The real pain shows up after launch
This is where WordPress friction becomes visible:
- Clients request small text changes
- PMs urgently ping developers
- Clients don’t know where content lives
- Gutenberg / ACF feels unintuitive for non-technical users
- Developers become “content operators” instead of builders
And ironically:
The simplest edits become the most expensive operations in the system.
The core mismatch
WordPress 7.0 assumes:
“Editing happens collaboratively inside the CMS”
But real production systems look like:
“Collaboration happens outside WordPress — CMS is just the final delivery layer”
Sees the gap differently
Instead of optimizing WordPress into a collaboration tool, we may start from a different observation:
The biggest friction is not collaboration — it’s content accessibility at the point of need
So the real question becomes:
- Why must clients learn where content lives in the system? - Finding posts in WP admin is a headache for clients.
- Why is “editing” separated from “seeing”? - Gutenburg is OK for agencies, but can be scary to clients because the UI is nerdy and not intuitive (Animated contents look horrible).
- Why does a simple text change require a development cycle? - Seeing on live page is where to be edited is needed by clients
Stay Tuned
