An editor adding a new report should be thinking about the report. They should not need to decide how many columns its summary belongs in, whether the heading is the right size or which of six nearly identical cards to copy.
WordPress gives us a lot of flexibility. A good custom build turns that flexibility into an editing experience that makes sense for the organisation using it.
I want people to feel confident when they publish. That means making some decisions during the build, while there is time to discuss them properly, instead of passing every decision to whoever is updating the site on a busy Tuesday.
Name the things the organisation works with
Before thinking about page layouts, I like to think about the content itself. A report may have a publication date, an author, a subject and a download. An event has a start time, a location and a booking link. Treating both as an empty page with a large formatting toolbar asks editors to recreate that structure every time.
A clear content model gives those details a reliable home. It also makes reuse easier: the same event can appear on its own page, in a listing and alongside a related article without someone maintaining three separate versions.
This is one of the jobs PorterWP handles. It registers native WordPress post types and taxonomies from configuration kept in the theme. The project defines its content; the toolkit supplies a consistent way to connect that definition to WordPress.
The useful outcome for an editor is ordinary language and predictable fields. The machinery behind that outcome should rarely need their attention.
Give freedom where it helps
A campaign landing page might need several different sections. A staff biography might need much less freedom. Giving both the same unrestricted set of controls ignores the difference between the tasks.
WordPress already provides block locking and content-only editing. These let a developer preserve parts of a layout while leaving text and media editable. They are native WordPress features, and choosing where to apply them is a project decision.
I would use that control selectively. Locking everything can leave people unable to do perfectly reasonable work. Leaving everything open can turn a small text update into an accidental redesign. The answer depends on what the team publishes and who is responsible for the design.
A useful handover exercise is to ask an editor to create something typical from scratch. Watch where they hesitate, which labels need explaining and whether they reach for an old page to copy. Those moments tell you more about the interface than a tour of every available block.
Make the underlying project readable too
The editor’s experience is only half of this. The next developer also needs to understand where the content model, block templates and project logic live.
PorterWP’s developer workflow keeps configuration and project PHP in the custom theme, with related block files grouped together. It leaves the design and the site’s specific behaviour to the development team. That boundary matters: a toolkit can organise a project, but it cannot decide what a charity’s campaign team or a publisher’s newsroom needs.
I would judge the finished result by a few everyday tasks. Can someone publish a report without help? Can they correct an event date in one place? Can a colleague find and reuse the right content without remembering how the original page was assembled?
If those tasks are straightforward, the build is doing useful work. The best compliment for an editing interface may be that nobody has much to say about it: they opened WordPress, made the change and got on with the rest of their day.
