Building a WordPress site for a client: hybrid, or full-site editing?

WordPress has been highly-customisable since its earliest days and that remains one of its great strengths. But the flexibility and range of options available to agencies or freelancers means that it’s important to have a plan before you start work.

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.

Once it’s clear what the content and topic of the website is going to be, the very first step before you start building a site is to work out how the content is going to be maintained. When I began building websites for clients using web-based content management systems instead of static code in the late 1990s, it was important to identify how much work the client wanted to do themselves. Nothing has changed in this regard: even before the arrival of the Block Editor in 2018 and the Site Editor in 2022, we developers needed to know which parts of the site need to be editable.

Just because WordPress allows a user to edit everything, doesn’t necessarily mean that the user must edit everything.

Perhaps the client just wants to add news entries or blog posts. Perhaps they want to edit page content, or change their product from time to time. At some point, we’ve all had to modify a part of the page template which was previously static, and make it editable. This is still true today.

With the Site Editor, we have the opportunity to make absolutely everything editable, be it the page content or the header, footer and navigation within one of the two editors ¹. But this editorial approach can be harder and more time-consuming. The code can be challenging to write, and we might find ourselves having to learn complex new tools and methods instead of devoting our time to the benefit of the project at hand.

When it comes to content management, the visual editor experience in WordPress can be overwhelming for some users, whilst being an amazing tool for others. Many ill-informed clients will want to be able to do everything themselves, without realising that, as Irina Spalko once found out, having everything is quite often too much to handle.

There’s also no point wasting budget and brainpower trying to create the world’s best editing experience for a part of the website which will never get touched by the client. The client won’t thank you for giving them the power and the responsibility for managing everything, when all they wanted was to be able to update their content and rename a new menu entry from time to time. However, if you are maintaining the site for them, you might be thankful you can modify or fix the page layout without having to spin up a development server and a whole load of technical tools.

Make decisions and provide only those options which are necessary.

In the WordPress world, there are two main ways to build a site: using the Block and Site Editors, or what has become known as the “hybrid” approach (in which “templates” mean PHP files). There are subsets even within these larger groups: the editor environment can the Block Editor, or an instance of a TinyMCE editor, or a page-builder-type interface built using the Advanced Custom Fields plugin.

(I’ll be going into more detail about each of these approaches in a future entry in the series.)

The first step of deciding which route to take is to discuss the project with the client, or with the users who will be working on the site. You don’t need to explain to them in detail at this point how the options differ: they will already be apprehensive and probably a little overwhelmed at the start of the project. Keep things simple for them, especially until they get into the swing of things.

The primary decisions at this stage are:

• Do they truly want to be able to edit every single part of the site, or do they just want to edit the content? If the work is for a partner agency, does that agency want their client to receive the tools to make potentially ill-judged design decisions?
• Are the users and the client informed about the process of maintaining site layouts? Does the project manager (or the CEO) want to allow their users to modify the site in any way they see fit, or is it important that design work and creative freedom is kept to a minimum?
• Is the client prepared for the amount of work that using a visual builder—be it the Site and Block Editors or a third-party tool—will entail? The more options you provide to a client, the harder the clients’ job becomes.

The newer approach isn’t always the better one. Assess the tools which are available to you, and choose the ones which allow both you and the client to achieve the best results.

Once you’ve discussed the primary topics, the next stage is to assess the practicalities of making the site yourself. It’s one thing for the client to have to learn a new editor, but you have to build it and make the site and the editorial experience work. It’s one thing to choose the Site Editor over a PHP-template-based solution for the sake of modernity, but do you have the know-how to build the site efficiently in this way? Does the project or company budget allow you to spend a lot of time learning new processes and new technology at every step of the way? I’ve spent five-and-a-half years working with the Block and Site Editors, and the code I often need to write for custom components is still one of the largest challenges I face in my job.

If you have the experience and the knowledge, or if you are able to set sufficient time aside for learning new tools and workflows, then the Site Editor will offer you a huge amount of satisfaction, allow you to work in line with the core principles of the current and future versions of WordPress, and allow both you and the client to benefit from the pure enjoyment of creating and managing content using the Block Editor. If you spend a fair amount of time creating content in the core WordPress editorial interface, it can be a pleasure in itself, not least because you can see precisely how the content will look when you hit publish.

The sites which I build most most efficiently are those which pragmatically use the correct tools for the job. Blocks were most often static and built with React five years ago; now they are almost always server-side rendered, with an editorial interface which allows the client to edit content efficiently. And not every project is built with the same stack.

There is a large number of different reasons to favour one way of building sites over another. You may be under pressure to build projects quickly because of client or company pressures. You may have the luxury of time, and the excellent approach of being able to reuse your components and blocks across multiple projects will help you to get faster and more efficient with every project you make.

That being said, the next stage is that you’ll have to decide not only how to satisfy the clients’ editorial requirements, but also your own.

• Complexity
  If you haven’t worked with the Site Editor, you will quickly come up against things which you don’t understand, or which don’t work in the way you expect (or need). Be prepared for this and plan accordingly. You will probably need to add third-party plugins for functionality which you expected to be in WordPress core. For example, you can work with fluid typography using theme.json, but there are no other responsive design controls at your disposal. (Layouts are responsive by default, but WordPress currently offers no onboard means of controlling the behaviour at each breakpoint.)
• Maintainability and flexibility for change
  Ensure that if the client wants changes later on, this work is achievable: both for the client and for yourself. Whilst Synced Block Patterns may sound like a good solution, their practicality is limited for professional agency projects, so make sure you tread carefully. What would happen if the client wants to completely revise the layout of hundreds of detail views a few weeks after launching the project, but all of the content is built specifically using static Blocks? The upcoming Pattern Overrides are a step in the right direction, but they are very limited in the first version and will only go a small way towards the flexibility which server-side rendered Blocks allow. Perhaps your own custom Block, which acts as a wrapper and contains a pre-defined and locked set of Inner Blocks, is the better approach.
• Ongoing cost
  No-one likes talking about costs later down the road. But the client will like it even less if they get additional costs sprung on them after you’ve spent time and effort building the whole site with the shiny new Site Editor. Follow-up costs are a part of pretty much every project I’ve ever worked on, and it’s my job to ensure that these are either kept to a minimum, or don’t come on top of project costs which have been stretched to breaking point for the first version of the site.
• Onward support
  As with all technology, WordPress moves ever-forward and so, whichever approach you take, don’t forget that the site you build should be maintainable and should continue to work (in principle) with new versions of WordPress and the plugins you’ve chosen. No-one wants to find out that their shiny new site will break with the next update of WordPress.

Next time

In the next post in the series, I’ll be explaining my workflow for building a site using the Site Editor: starting with a completely fresh WordPress installation, using the Site Editor tools to build out site templates and parts, adding styling, and working with content in the Block Editor.

If you’d like to receive an email when the next post in the series is published, please consider subscribing to my website’s newsletter, linked at the bottom of this page.