I’ve now written at some length about my process developing websites using WordPress and its Block and Site Editors. The next in the series covers the topic of how the client can most easily manage the content of their site.
I offer technical, training, programming and conceptual support for partner agencies and freelancers through my agency Say Hello: either on-site or via email, Slack or video call. Get in touch if you’d like to discuss what options I provide. I am fluent in English, German and Swiss German, and my daily rate is means-adjusted for international work.
One of the best ways we can build on top of the experience of everyone’s contributions to WordPress is to think beyond the system which WordPress provides, and make the most of the features it provides as part of a solution.
In social media channels—admittedly, an environment which is often a place where frustrated people vent—there’s often discussion about “the best way” to build sites for clients. There’s a simple answer to this: there is no “best way”. There is a common basis of WordPress and the Block Editor, but each project is different.
Each agency or freelancer works differently, but content management boils down to one thing: the user has to create and manage content. It’s down to the project manager, the developer, or the team to decide how they can do that most efficiently. This can be with the Block and Site Editors, but (for many projects) equally well using a combination of common approaches in WordPress.
Combining two approaches in one process
My approach is the combination of two basics in WordPress: the Block Editor, which allows me to manage layouts, and the “post”. (Either the standard post type, which is classically used for news or a blog, or a custom post type.) The current version of WordPress allows me to add combinations of blocks (or “patterns”) and reuse them, or to add block bindings, or to filter and control the behaviour of core blocks and patterns.
While this focus on the full Block Editor approach can work well, it can often be unnecessarily hard to use as a content creator, and will most definitely make the developer’s life much harder than it needs to be.
Every project I’ve worked on over more than fifteen years has proven that it makes sense to use custom post types for content which is being displayed in various places across the website. I can quote my current project as an example: the client wants to display service offerings, projects, news, their team, and testimonials on their site. This could be achieved by some complex juggling by me and by the client in the Block Editor, but there’s no need for this juggling.
Over-stretching the technology in this way will lock the content into the design, which creates problems for every agency I’ve talked to at some point later on in the life of the website. Rather than trying to shoe-horn the newest features in WordPress, don’t forget that you can still use the pre-existing approaches which have worked perfectly well for millions of websites over many years.
Most of my clients want to manage the content of their site, not learn how to manage a design and layout system.
The separation of content and design
The output of content which the user has created should usually be kept separate from the content itself; the exception being what clients usually refer to as “landing pages”. (Pages which have little or no semantic content, with an almost exclusive focus on a one-off, visually-based layout of a topic.) Using the approach of separating content and design allows those who want to change the layout of the views to do so using the block editor, whilst allowing the basic content (or “data”) to remain unchanged.
By keeping the content and design separate, it’s possible to completely re-design the website later on without touching the content at all. This isn’t always a requirement, but if the content is separate from the design, then there are infinite possibilities for displaying it without requiring a potentially considerable amount of editorial work. The separation of content and design most often makes sense when there’s a logical grouping of content. Building what I refer to as a “brochure website” is most-often better achieved using a simpler block-based approach.
Just because we’re using the Block Editor now, there’s no need to change the principle of structured data when it makes sense. A web publisher with experience and skill can build and manage the frontend of the website, and choose exactly how each view looks. The project manager adds a new project, fills in some fields, and publishes the entry so that it appears automatically in the correct places in the website. The project manager doesn’t need to check what the output looks like… not least, because that’s not usually their responsibility.
Around fifteen years and again around ten years ago, I worked on projects where the content wasn’t even constrained to the same website: a custom API allowed me to pull in project and news content from one central website and use it on other websites and in other web apps. If the content had been locked together with the design, then this would have been impossible. More recently, the data of team members on a client’s microsite were drawn in from their main website and displayed in a completely different design.
In the previous example, I said that the project manager didn’t need to check what the output on the website looked like. A colleague from a previous employer managed a system for the parent group of the New York Times where not only did journalists not know what the output would look like, they didn’t even know which websites or apps used the content. That’s a true example of the separation of content and design, which can equally-well be achieved by WordPress if you take the correct approach when deciding how to manage data.
In 2017, I took advantage of the separation of content and design to build a small on-site dynamic webapp using Angular, which showed the current status of the opening times and available capacity of sports facilities in Bern, whilst working around a strict site caching policy. Fetching the content data for this view using the REST API was relatively simple because we’d had the foresight to ensure that the content was stored in a custom post type, not statically in the middle of other page content.
My current project is largely based on raw content which has been created and improved over ten years or longer. The requirement has remained unchanged in all that time. Before the Block Editor, the client edited the individual entries and managed the content using a range of fields: title; intro text; descriptive text; featured image; dates; quotes; categorisation. In the new site, the same content will be used, but the descriptive text will now be managed using Blocks and not just within a TinyMCE field. The remaining fields are kept simple, so that there is no opportunity to add the wrong information to the wrong entry.
The Block Editor, but not as you know it
Where some of the fields in my example are the plain text fields which WordPress has always used, we don’t have to think in terms of one solution or another. We can set up a custom post type featuring the basic fields I’ve mentioned, but instead of just providing a simple TinyMCE field for the description, we can provide a fully-fledged Block Editor.
This can either be achieved by allowing the regular Block Editor for the custom post type and adding separate meta fields to the custom post type, or by turning off the regular Block Editor and adding a Block Editor field as one of the meta fields to a classic editor screen.
The easiest example of how to achieve this is the Block Editor field type in the “ACF Extended” plugin, which makes perfect sense if you’re using ACF to build your user interface. (It can also be achieved by attaching a raw Block Editor script to a classically-coded textarea, but that’s out of the scope of this article.)
This approach may sound as though you’re going to add a Block Editor within a Block Editor, but don’t worry: adding the Block Editor field type using ACFE is constrained to use within the classic editor view.
Using the data in the design
The most common use I have for using custom post types in a Block Editor environment is twofold: primarily using an archive-mycustomposttype.html template in the Site Editor which contains ancillary information (blocks) as well as a query loop block to output the relevant posts in the design I want.
Additionally, I can use the query loop block in the footer template in a completely different design to display the latest news entries. On the overview page of the client’s service offerings, a customised overview of some highlighted projects can be displayed. By adding a checkbox to the project entries, the client can choose which of them should be displayed across the site in those places which the designer has chosen.
In summary
The Block and Site Editors may be the future of websites built with WordPress, but the alternative simpler technology, which has been proven for use in millions of websites over many years, is still just as appropriate for many projects as it always has been.
Decide when starting a new project or overhauling an existing project which approach to content management better suits the client and the project: not just now, but in a year’s time, or in five years’ time.
Leave a Reply