waarom Wordpress?
Het antwoord is vooral praktisch. Wordpress is een van de meeste gebruikte CMS’en ter wereld. Als web-agency krijg je vroeg of laat te maken met een Wordpress-installatie, of je wilt of niet. Veel klanten zijn gewend zijn om in Wordpress te werken. Om al onze klanten zo goed mogelijk te kunnen bedienen besloten wij in 2012 met lichte tegenzin onze toolbelt uit te breiden met Wordpress. Maar dan wel Wordpress à la Us Media.
onze Wordpress stack
Voor de kenners onder ons; hieronder een beknopt overzicht van onze Wordpress-stack. Een aantal van deze onderdelen lichten we toe.
de basis
- PHP/Typescript/Sass
- Wordpress
- Plugin - Timber
- Plugin - Advanced Custom Fields
- Custom thema
Daarnaast hebben we een aantal standaard plugins gekozen, die alleen worden gebruikt als de klant deze nodig heeft. Denk hierbij aan formulieren, meertaligheid of een betere zoekfunctionaliteit.
develop omgeving
Als developer kom je verder nog in aanraking met de onderstaande tools.
- Composer
- Docker (met Docker Compose)
- Weback/Gulp
- Sonar
betere templates
Het maken van pagina-templates in Wordpress doe je in PHP, met als gevolg dat er vaak veel logica- en template-regels door elkaar staan in dezelfde file. Niet zo netjes en lastig leesbaar.
Wij maken daarom gebruik van de Timber-library. Die stelt ons in staat de templates apart op te zetten in Twig-files. Dat maakt de templates beter te onderhouden en eenvoudiger verwisselbaar.
Voor ons bij Us Media is er trouwens nog een voordeel: veel van onze projecten draaien met Twig-templates (ook non-Wordpress projecten). Dus als je eenmaal leert werken met Twig, kan je bij ons meedraaien in meerdere 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 functionaliteit
Wordpress is van origine een blog-platform, maar onze klanten hebben vaak specifieke wensen. Daarvoor hebben wij extra logica nodig in een thema.
Custom types / classes
In Wordpress is het mogelijk je eigen contenttypes te bepalen en in combinatie met Timber breiden we de standaard WP Post-class uit met onze eigen classes. Dat zorgt voor een goede splitsing van logica (op de juiste plek) en de frontend templating. Zie hieronder een simpel voorbeeld voor het ophalen een extra subtitel.
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 uitbreidingen
Een veel gebruikte plugin hiervoor is ACF (Advanced Custom Fields). Deze plugin maakt het voor ons eenvoudig extra velden toe te voegen in het CMS. Zoals bijvoorbeeld een extra veld voor een subtitel op de artikelpagina. Ook hier komt de Timber-plugin meekijken, want deze is goed geïntegreerd met ACF.
De configuratie van ACF wordt vervolgens opgeslagen als JSON bij het project. Zo wordt het makkelijk aanpassingen te controleren (via pull-requests) en deze vervolgens te deployen naar staging/production omgevingen.
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
Voor veel van onze klanten wordt de website gehost in een cloud-omgeving, maar Wordpress zelf verwacht een klassieke hosting. Gevolg is dat wij een aantal extra stappen hebben moeten doen om hosting werkbaar te houden in een cloud-omgeving.
CDN
Om de webserver te ontlasten met het serveren van files (denk aan JS / CSS / Afbeeldingen etc.), wil je deze content serveren via een CDN. Maar Wordpress ondersteunt dit niet ‘out-of-the-box’.
In AWS realiseren we dit door middel van een S3 bucket, CloudFront en een plugin. In CloudFront configureren we het zo, dat alle files vanuit de S3 bucket opgehaald worden (i.p.v. de webserver). En via de plugin zorgen we ervoor dat deze files geupload worden naar deze S3 bucket.
Load Balancing / Meerdere web servers
Sommige van onze klanten hebben veel verkeer op hun website. Om die traffic aan te kunnen, hebben we meerdere webservers nodig (achter een load-balancer). De eerder genoemde CDN oplossing, zorgt er ook voor dat de files die de klant eventueel upload in het CMS ook op het CDN terecht komen. Dit zorgt er voor dat we webservers makkelijk kunnen vervangen (en meerdere servers naast elkaar kunnen draaien), zonder data verlies.
Imgix
Voor sommige websites zijn nog meer optimalisaties nodig. Denk aan het serveren van afbeeldingen. Deze moeten responsive zijn, maar ook eventueel van verschillende types (zoals jpg vs. png vs. webp).
De service Imgix koppelt lekker met verschillende hosting oplossingen (cloud / klassiek etc. allemaal geen probleem). En in ons geval via dezelfde S3 bucket.
next steps voor deze stack
De techniek staat niet stil, dus onze stack is ook steeds in beweging. Hieronder een aantal stack-specifieke vraagstukken waar we nog mee zitten.
Wordpress Gutenberg
Wordpress zelf staat niet stil en is voortdurend bezig met updates aan hun kant. De grootste aanpassing van de afgelopen jaren is de Gutenberg-update. Voor deze update hebben we in onze Wordpress setup een en ander moeten omgooien. Maar dit is nu nog in beweging, vooral omdat Wordpress zelf nog flink bezig is met de verschillende opties binnen in het thema.
De vraag voor ons is nu, gaan we mee met Wordpress en ondersteunen we al deze nieuwe opties (ook al gebruik je de meeste niet), of zijn het voor een website design misschien wel TE veel opties? Of disablen we alles en ondersteunen we alleen onze eigen blokken via ACF?
omarmen werkt beter
Na zo’n 10 jaar Wordpress bij Us Media blijft het een haat-liefde-verhouding tussen onze developers en deze CMS-oplossing. Wegduwen heeft geen zin, omarmen werkt veel beter, daar zijn we inmiddels wel achter. Uiteindelijk biedt Wordpress ons als developers voldoende flexibiliteit om het te tweaken. Van nieuwe collega’s die horen dat ze bij ons ook met Wordpress gaan werken, krijgen we nog wel eens een vieze blik. Maar als zij eenmaal een WP-project gedraaid hebben, zien ze dat Wordpress à la Us Media echt iets anders is dan het standaard bij elkaar klikken van een CMS.