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 fieldsContent validation
• No schema enforcement
• Risk of inconsistent data
• SeachabilityTeam 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.













