Johan Ronsse

Ik heb zitten nadenken over de veranderingen in WordPress 6 “Arturo”, met als nieuwigheid dat full-site editing gegeven.

Ik heb dat eigenlijk eerlijk gezegd nog nooit zien werken in de praktijk, dus ik sta daar wat skeptisch tegenover.

Voor een eenvoudige website zie ik het nog wel werken, maar ergens ook weer niet. Elke vrijheid die je krijgt in de editor heeft een “andere kant”, die voor mij in de weg staat van de finale kwaliteit.

Stel dat je bv. iets in 2 kolommen zet. Dan moet je eigenlijk ook weer een definitie hebben van wat er mee gebeurt op een klein scherm.

Stel dat je een knopje een kleur geeft. Oké, goed, maar wat met de hover, active, focus state enzovoort?

Als designer die let op elk detail wil ik een goed eindresultaat. Hoe geavanceerder de vorm van customization door de eindgebruiker, hoe meer “controle” je afgeeft. Of hoe meer werk je dan hebt om de oneindigheid aan variaties die dan mogelijk zijn te kunnen voorzien.

Ik besef wel dat het keurslijf waar je enkel een tekstveldje kan aanpassen een beetje 1997 is, en je als content editor wel wat opties wilt om de layout te krijgen die je wil.

Dat is altijd al een moeilijke balans geweest, sinds de eerste dagen als web designer. Vanuit technisch vlak moet je dan eigenlijk beslissen: wat is hardcoded, aanpasbaar, en indien aanpasbaar, in welke mate? Ik wil niet weten hoeveel werkuren er al verspild zijn in de wereld om iets aanpasbaar te maken, waar het dan in de praktijk nooit werd gedaan.

Ik gebruik WordPress al 16 jaar. Door de jaren heen heb ik vooral minimale thema’s geschreven die de standaard have_posts loop gebruiken, met volledige controle over welke HTML en CSS er allemaal binnen komt. Zo min mogelijk plugins en zo veel mogelijk gebruik makend van functionaliteiten zoals custom post types en de manier om in te haken op zaken uit het CMS zoals de navigatie (wp_nav).

Voor use cases waar ik mijn eigen klant ben, ben ik overgeschakeld op een systeem dat ik voor sommige pagina’s vooral statische content had.

Dat is echt doodeenvoudig, je maakt een nieuwe PHP file, en als die zo geformatteerd is, wordt die beschikbaar als template:

<?php
/**
 * Template Name: home
 */
?>

Omdat het toch vooral voor mezelf/mijn bedrijf was, en we als team de skills hadden om zo te werken was dat lang “the way to go”. Dan pasten we gewoon de template aan, hardcoded, en hup, deployen maar.

We hebben ook ooit eens een WP-expert ingehuurd om het allemaal wat properder te zetten, met een moderne PHP logica.

Aan de kant van het bloggen en websites beheren ben ik tevreden met WordPress omdat er effectief een CMS-kant is, en als ik in schrijf-modus ben dat ik écht niet naar mijn terminal wil gaan, een markdown file openen, de laatste git versie uitchecken etc…

De trend van static sites (onder devs) is misschien leuk als tech-demo en voor sommige mensen werkt het misschien (als je dat dev-gegeven toch al leeft), maar voor mij niet. Ik heb geen zin om mijn website elke 2 jaar te herschrijven in het laatste framework. De code van vandaag gaat al mee sinds 2015, en dat was dan weer een evolutie van code van daarvoor.

Af en toe schreef ik er een stukje bij als ik het nodig heb of motivatie heb, zoals dark mode of de code voor propere code-blokken. Maar eigenlijk is al die code al jaren vrij stabiel, en doet die wat het moet doen.

Ik ben ook eens erg onder de indruk geweest van Advanced Custom Fields, en heb dat onthouden als dé manier om iets geavanceerd en gestructureerd in WordPress te krijgen (samen met custom post types). Ik heb eens een heel portfolio systeem uitgedacht voor de Mono site, om dan erna een jaar gefrustreerd te zijn dat we bijna niks in ons portfolio mochten zetten.

Terug over full-site editing dan.

Ik heb er ook schrik voor dat die evolutie misschien zorgt voor een niet-juiste scheiding van de data en de layout.

Met het Gutenberg project (en in het algemeen de “blocks” trend in zaken als Coda, Notion etc.) krijg je eigenlijk data exports waar de metadata van de layout vervat zit op de plek van het “blokje” zelf.

Of situaties waar die informatie tout court niet aanwezig is, waardoor je export eigenlijk een onvolledig beeld geeft.

Dat wordt wel ingewikkeld om te onderhouden en te transporteren naar toekomstige systemen.

Ik ben in het algemeen toch een voorstander van iets dat jaren kan meegaan. Ook daarom hou ik niet zo van die headless CMS trend, waar ik weinig stabiliteit in zie.

Dus… ik ben eigenlijk niet geneigd om als ik een nieuw web project heb, mee te gaan met heel die nieuwe WP redenering.

Misschien is het dan toch tijd om eens een ander CMS te overwegen. Of misschien moet ik me openstellen voor deze manier van werken. Ik werk dagelijks als UI designer in een software context, met af en toe een front-end development uitstap.

Ik ben te weinig met web design in de praktijk bezig om er echt een mening over te formuleren. Misschien zit er in mijn lezerspubliek wel iemand die deze nieuwe problematiek beter beheerst. Wat denken jullie?