DEV Community: Steven K

Wordpress - Why Clients Keep Asking “Where To Edit This?”

Steven K — Sat, 18 Apr 2026 11:43:39 +0000

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

Check out this Demo

Rethinking WordPress Editing: Inline vs ACF Workflows

Steven K — Tue, 14 Apr 2026 11:54:22 +0000

WordPress has evolved a lot—but one thing still feels surprisingly inefficient:

Editing content as a non-technical user.

If you’ve worked with clients, you’ve probably seen this:
• “Where do I change this text?”
• “Why are there 12 fields for one section?”
• “I updated it but it looks different on the page…”

Join our Discord

Even with tools like ACF or Gutenberg, the editing experience is still abstracted away from the actual page, especially for a content edtior/non-technical personals.

So I started exploring a different approach:

What if editing happened directly on the page, no need to access backend(Wordpress Dashboard), no field definitions?

The Problem with Current Workflows

Most WordPress setups today follow this pattern:
• Define fields (ACF / blocks)
• Map fields to templates
• Edit content in wp-admin
• Preview separately

This works well for structured content, but introduces friction:
• Editors don’t know where content lives
• Visual feedback is delayed (switch between live pages and WP dashboard)
• Developers must maintain field schemas

In client projects, this often turns into:

“Just tell me exactly where to click…”
The Idea: Inline Editing as the Default

Instead of defining fields in the backend, I tried flipping the model:
• Editable areas are marked directly in the template
• Users click and edit content on the actual page
• Changes are saved as structured JSON

No admin panel. No field mapping.

Just:

See it → Click it → Change it

Demo (Prototype)

I put together a small demo to test the UX:

👉 https://lcms-demo.vercel.app/

It’s a simplified version (no full WP backend), but it demonstrates the core interaction:
• Click text
• Edit directly
• Save instantly

⸻

Where This Might Work Well
• Marketing sites
• Landing pages
• Simple CMS use cases
• Client projects with frequent small edits

Especially when:

The priority is ease-of-use over strict content modeling

⸻

Where This Might Break

This is where I’m unsure and would love input:

Complex structured content
• Repeaters
• Relationships
• Nested fields
Content validation
• No schema enforcement
• Risk of inconsistent data
• Seachability
Team workflows
• Versioning?
• Collaboration?
• Permissions?
Maintainability
• Is HTML-comment-based mapping too fragile?
• Would this scale across large projects?

Comparison: Inline Editing vs ACF

Aspect	ACF / Traditional	Inline Approach
Setup	Field definitions required	No manual schema setup (auto)
Editing	Backend UI	Direct on page
Visual feedback	Indirect	Immediate
Flexibility	Structured	Structured
Dev control	High	High

Open Questions

I’m still exploring whether this is:
• A genuinely better workflow
or
• Just something that feels good in a demo

Would really value input from people who’ve built real WordPress systems:
• Does this approach make sense in production?
• What would break first?
• Would you trust JSON-based content storage?
• Is removing the admin layer actually a bad idea?

⸻

Closing Thought

WordPress has always been about democratizing publishing.

But editing still often feels like:

“Learn the system first, then change your content.”

Maybe it should be:

“Just click and edit.”

Curious to hear how others are thinking about this.

⸻

If you’re interested, Join our Discord.