why Wordpress?
The answer is mainly pragmatic. Wordpress is one of the most widely used CMS solutions in the world. As a digital agency you will sooner or later have to deal with a Wordpress installation, whether you like it or not. Many customers are used to working in Wordpress. In order to be able to serve all our customers as well as possible, we decided in 2012 - with some healthy reluctance - to expand our toolbelt with Wordpress. But then Wordpress à la us..
our Wordpress stack
For the connoisseurs among us; below is a brief overview of our Wordpress stack. We will explain a number of these components.
the basics
- PHP/Typescript/Sass
- Wordpress
- Plugin - Timber
- Plugin - Advanced Custom Fields
- Custom thema
In addition, we have chosen a number of plugins, which are only used when the need arises. Think of forms, multilingualism or better search functionality.
development environment
As a developer you will also utilize the tools below.
- Composer
- Docker (met Docker Compose)
- Weback/Gulp
- Sonar
better templates
Making page templates in Wordpress is done in PHP, resulting in logic and template rules becoming mixed up in the same file. Not very neat and difficult to read.
To solve this, we use the Timber library. This enables us to set up the templates separately in Twig files. This makes the templates easier to maintain and easier to exchange.
For us at us. there is another advantage: many of our projects run with Twig templates (including non-Wordpress projects). So once you learn to work with Twig, you can join us in multiple tech stacks.
file: base.twig
<!DOCTYPE html>
<html class="no-js" lang="nl-NL">
<head>
<title>{{ title }}</title>
<meta charset="utf-8" />
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<link rel="stylesheet" href="{{ '/assets/css/layout.css' | assets }}" />
{% block head %}{% endblock %}
</head>
<body>
<div class="site">
<header id="site-header" class="site__header">
{% include 'partials/site-header.twig' %}
</header>
<main id="site-main" class="site__content">
{% block content %}{% endblock %}
</main>
</div>
{% block scripts %}{% endblock %}
</body>
</html>
file: article.twig
{% extends 'base.twig' %}
{% block content %}
<article id="{{ post.htmlId }}" class="article {{ post.class | trim }}">
<div class="article__header">
<h1 class="article__title">{{ post.title }}</h1>
{% if post.subtitle %}
<p class="article__subtitle">{{ post.subtitle }}</p>
{% endif %}
</div>
<div class="article__content">
{{ post.content }}
</div>
</article>
{% endblock %}
custom functionality
Originally, Wordpress was intended to be a blogging platform, but our customers rarely use it as such. Which means we need additional logic in a theme.
Custom types / classes
In Wordpress it is possible to determine your own content types and in combination with Timber we expand the standard WP Post class with our own classes. That ensures a good split of logic (in the right place) and the frontend templating. See below a simple example for fetching an extra subtitle.
file: article.php
class ArticlePost
extends \Timber\Post
{
...
public function subtitle() {
$subtitle = $this->get_field(ACFField::ARTICLE_SUBTITLE);
return $subtitle ?: null;
}
...
}
file: article.twig
<article id="{{ post.htmlId }}" class="article {{ post.class | trim }}">
<div class="article__header">
<h1 class="article__title">{{ post.title }}</h1>
{% if post.subtitle %}
<p class="article__subtitle">{{ post.subtitle }}</p>
{% endif %}
...
CMS extensions
A commonly used plugin for this is ACF (Advanced Custom Fields). This plugin makes it easy for us to add extra fields in the CMS. For example, an extra field for a subtitle on the article page. The Timber plugin also comes into play here, because it is well integrated with ACF.
The configuration of ACF is then saved as JSON with the project. This makes it easy to check changes (via pull requests) and then deploy them to staging/production environments.
file: acf-counter.json
[
{
"key": "group_5f4d14de093e6",
"title": "Articel",
"fields": [
{
"key": "field_5f4d16018990c",
"label": "Subtitle,
"name": "article_subtitle",
"type": "text",
"instructions": "",
"required": 1,
"conditional_logic": [
[
{
"field": "field_60fec58dfb973",
"operator": "==",
"value": "forms"
}
]
],
"wrapper": {
"width": "",
"class": "",
"id": ""
},
"show_in_rest": 0,
"default_value": "",
"placeholder": "",
"prepend": "",
"append": "",
"maxlength": ""
},
...
hosting
For many of our customers, an online platform is hosted in a cloud environment. But Wordpress itself expects classic hosting. As a result, we had to take a number of extra steps.
CDN
To relieve the web server of serving files (think JS / CSS / Images etc.), you want to serve this content through a CDN. But Wordpress does not support this ‘out-of-the-box’.
In AWS we utilize an S3 bucket, CloudFront and a plugin. CloudFront is used for file retrieval from the S3 bucket (instead of the web server). And through the plugin we ensure that these files are uploaded to this S3 bucket.
Load Balancing / Multiple web servers
Some of our customers have a lot of traffic on their website. To be able to handle that traffic, we need multiple web servers (behind a load balancer). The previously mentioned CDN solution also ensures that the files that the customer uploads in the CMS also end up on the CDN. This ensures that we can easily replace web servers (and run multiple servers side by side), without data loss.
Imgix
Some client websites require additional optimizations. For example, by optimizing the serving of images. These must be responsive and can be of different types (such as jpg vs. png vs. webp).
For this, we use the Imgix service. The service Imgix connects with different hosting solutions (cloud / classic, etc. all no problem). And in our case via the same S3 bucket.
next steps for this stack
Technology evolves all the time, so our stack is always on the move as well. Below are a number of stack-specific issues that we are still dealing with and improving upon.
Wordpress Gutenberg
Wordpress itself evolves as well and receives updates all the time. The biggest change in recent years is the Gutenberg update. For this update we had to change a few things in our Wordpress setup. This is still in development, especially because Wordpress itself is still working on the different options within Gutenberg.
One of the bigger challenges for us is: do we move along with Wordpress and do we want to support all these new options (even if most clients don’t use most of them)? Or do we disable everything and only support our own blocks via ACF? We will continue to evaluate in which cases Wordpress is the best option, but remain critical and open minded when using a different stack is the better option.
to push away or to embrace
After about 10 years of Wordpress at us., a love-hate relationship between our developers and this CMS solution remains. There’s no point in pushing away, embracing works much better, we’ve figured that out by now. Ultimately, when the Client prefers or requires Wordpress, we found a solution to tweak it as described into a workable solution. We sometimes get a dirty look from new colleagues who hear that they will also be working with Wordpress with us. But once they have run a WP project, they see that Wordpress à la us. is really something different than the standard clicking together of a CMS.