Striking the Balance

I’ve been working on some updates to an old WordPress site that was originally built back in 2017, before the release of the Block Editor. As such, it uses PHP templates, with Advanced Custom Fields to build out the editing interface, and the Timber plugin which lets the site use the Twig templating language.

If I were to build that site from scratch today, I would obviously use the Block Editor, with a combination of native WordPress blocks, supplemented with custom-developed blocks where needed. However, time and budget didn’t allow for a full rebuild at the moment, so I was faced with trying to decide on the best ways to modernise the build, and set it up for additional work further down the line, while keeping the scope firmly constrained for now.

With no time to switch to blocks at this stage, the first decision was made for us: we had to stick to templates. I decided that a good first step would be to convert the Twig templates to standard PHP, returning the site to as close to native WordPress as possible, and reducing the reliance on third-party plugins. We’ll still be using Advanced Custom Fields, but I don’t think that’s a problem. ACF is so ubiquitous that it’s practically a default – at least for older, non-block-based themes.

So that’s what I have been doing this week. Going through the site, file by file, moving the template code from the .twig files it’s currently in, into WordPress’s standard arrangement of PHP template files. Once the code is moved, it’s a laborious process of searching for Twig template tags, and converting them to their PHP equivalents. Most of the time, this is things like:

{{ fields.title }} -> <?php the_field('title'); ?>

Or:

{{ site.url }} -> <?php echo esc_html(get_bloginfo('url')); ?>

There’s no denying that the Twig tags are much nicer and more readable, but the ability to remove the site’s reliance on the Timber plugin makes the loss more than worth it. Nothing wrong with Timber, but we’re aiming for a native experience.

During the next stage of development on the site, which will happen a few months from now, I plan to start migrating the theme, slowly but surely, over to a modern WordPress block theme. Adding a theme.json file comes next, and all the CSS changes that will entail. Then, the thorny business of splitting the templates themselves into individual blocks. ACF blocks first, probably, assuming the project continues to be one of small, incremental improvements. Ultimately, the goal is to have the site built entirely according to modern WordPress standards, using WordPress blocks built in React, and the bare minimum of third-party dependencies.

In an ideal world, every project would be a new build from scratch, using all the latest WordPress features and standards. In practice though, websites don’t become entirely obsolete just because the underlying platform has been updated, and there is value in keeping an existing, proven site, and incrementally updating it so that it stays – if not on the absolute bleeding edge – at least not too far behind.