Headless WordPress – Kip zonder kop of ei van Columbus?

‘Headless WordPress’… wat is dat nu weer?

WordPress is een zogenaamd ‘Content Management System’… een systeem wat bedoeld is om content voor het Internet te beheren. Beheren hoeft echter niet altijd gelijk te zijn aan ‘presenteren’.

Ik loop al weer heel wat jaartjes mee in de wereld van het Internet. En in het grijze verleden heb ik ook mijn bijdragen geleverd aan een aantal destijds belangrijke ‘Open Source’ projecten op het Internet.

In de negentiger jaren programmeerde ik in ‘Delphi’, een programmeertaal die destijds vooral op het Windows platform werd gebruikt (inmiddels bestaat het voor alle grote platforms) en via de ‘nieuwsgroepen’ op het Internet (kan iemand zich dit nog herinneren?) was ik in contact gekomen met een groepje andere Delphi programmeurs die eenzelfde idee hadden als het idee waar ik al een tijdje mee speelde.

Je moet begrijpen, dat in die tijd online databases als MySQL nog niet beschikbaar waren en PHP niet eens ‘in de kinderschoenen stond’, maar de maker nog volop bezig was de babysokjes te breien.

Kortom, we waren helemaal aangewezen op HTML voor het Internet, met af en toe een formuliertje op de achtergrond wat mogelijk werd gemaakt door PERL, een programmeertaal die op dat moment eigenlijk de enige optie was, maar een draak van een taal om een hele site in te programmeren.

Maar in die tijd werd het idee van het project ‘DeltaPlus’ geboren. Een Delphi applicatie waar je aan de ene kant HTML templates mee kon maken en aan de andere kant werden die pagina’s ‘gemerged’ met de gegevens uit een database.

Content en opmaak dus duidelijk gescheiden. Het ‘eindproduct’ van DeltaPlus was een serie HTML pagina’s die automatisch via FTP werden geupload naar je server op het Internet.

Een ‘content management system’ avant la lettre. Maar het werkte prima.

Met de komst van ‘echte’ content management systemen is DeltaPlus een zachte dood gestorven. Maar het idee hierachter bestaat nog steeds.

Waarom moet een website die hoofdzakelijk statisch is ‘het gewicht dragen’ van database en server operaties, en kunnen niet gewoon de HTML pagina’s worden doorgestuurd?

Het is bijvoorbeeld het hele idee achter WP2Static, een plugin die ik enkele maanden geleden heb besproken.

CMS als een monolithische applicatie

Met de komst van makkelijk toegankelijke programmeertalen als PHP en Open Source databases als MySQL werd het steeds makkelijker om ‘online CMS systemen’ te bouwen. Een systeem wat je volledige controle gaf over de inhoud van de webpagina.

Zelf ben ik in het verleden nauw betrokken geweest bij TikiWiki, een CMS wat vandaag ‘in de marge’ nog steeds voortleeft (maar waar ik al 15 jaar lang geen bijdrage aan heb geleverd) en osCommerce, één van de eerste e-Commerce open source projecten. Een project waar ik ook zo’n 15 jaar niet meer bij betrokken ben, en wat al ruim drie jaar niet meer geupdate wordt.

Maar zo rond 2005 waren dit soort applicaties ‘de toekomst’. En hoewel WordPress pas wat later om de hoek kwam kijken, is WordPress ook nog duidelijk een product van deze generatie.

Maar dit alles ging uit van het World Wide Web. En het World Wide Web is ook niet alles. Dat hebben we geleerd van onze smartphones.

Systeem integratie

Voor ik mij inliet met het Internet kwam ik eigenlijk uit een heel andere ICT wereld. Van 1992 tot en met 2002 heb ik mij voornamelijk bezig gehouden als technisch projectleider van grote projecten voor enkel van de top 500 bedrijven in Nederland met betrekking tot het koppelen van systemen.

Waar ik toen vooral mee bezig was was om de oude op mainframes gebaseerde systemen te koppelen met de ‘modernere’ Client-Server gerichte systemen gebaseerd op Windows (NT), of enkele jaren later, deze Windows systemen input te laten leveren voor de webportals van die bedrijven, waardoor jij bevoorbeeld jouw telefoon- of gasrekening online kon bekijken.

En eigenlijk verschilt dit niet zo gek veel van een ander projectje waaraan ik enkele maanden geleden voor mijzelf begonnen ben: De gegevens van jouw webshop zichtbaar te kunnen maken in een mobiele app. Opnieuw, het koppelen van ‘legacy technology’ aan modernere toepassingen.

Het bloed kruipt waar het niet gaan kan.

WordPress – De tijd ver vooruit!

Toen ik in september 2005 kennis maakte met WordPress was ik met stomheid geslagen. Niet over WordPress zelf, omdat ik op dat moment voor geen moment gedacht zou hebben, dat ik ruim 15 jaar later één van de populairste blogs over WordPress in het Nederlands taalgebied zou hebben, maar vooral vanwege de technologische aanpak.

Want hoewel we vandaag de dag het heel normaal vinden, dat we in een paar muiskliks een plugin kunnen installeren of verwijderen, was dat in die tijd niet zo vanzelfsprekend. Een ‘module’, of ‘component’ of ‘extension’ (zoals uitbreidingen in die tijd werden genoemd) waren alles behalve ‘plugin’. En nog veel belangrijker: Er was geen sprake van ‘plug out’. De meeste van dit soort uitbreidingen hadden namelijk een zogenaamde ‘patch’ file, die automatisch wijzigingen aanbracht in de oorspronkelijke code van het systeem.

Iets wat bij het deinstalleren, of bij een upgrade een ware nachtmerrie was. Bij iedere upgrade moest uitgebreid getest worden of het systeem na de uitbreiding nog wel wilde werken. Wat vaker niet dan wel het geval was.

Maar WordPress had een heel andere manier van plugins.

Custom Post types

En WordPress heeft vaker in de loop van haar geschiedenis de gelederen van de ICT-ers weten te verbazen. Of in ieder geval een flinke indruk weten te maken. Ik ben er zeker van dat één van de grote succesfactoren van WordPress -en de reden dat vandaag 40% van alle websites op het Internet WordPress websites zijn- ook te maken heeft met de ‘Custom Post Types’.

Wanneer je meerdere plugins gebruikt, dan is het je vast wel eens opgevallen dat de invoer- en edit schermen van het ‘gegevenstype’ wat die plugin je beschikbaar stelt toch wel sterk lijken op ‘Pagina’s’ en ‘Berichten’. Want alle informatie objecten in WordPress worden eigenlijk opgeslagen in twee tabellen. De ‘posts’ en de ‘post_meta’ tabellen. In de ‘Posts’ tabel wordt alles opgeslagen wat alle ‘post types’ gemeenschappelijk hebben en in de ‘post_meta’ tabellen worden al die extra gegevens opgeslagen. En dat is precies waarom het voor een programmeur zo makkelijk is om ‘zomaar’ gegevenstypen toe te voegen aan WordPress. En dank zijn plugins als PODS, ACF en Toolkit is het allemaal nog makkelijker geworden.

Headless WordPress – WordPress zonder WordPress

En zo komen we langzaam aan bij het fenomeen van ‘Headless WordPress’. Headless WordPress is de term die er gebruikt wordt, wanneer we te maken krijgen met een situatie waar WordPress niet gebruikt wordt voor een website maar voor een data entry applicatie. Stel. Ik wil een recepten app voor de mobiele telefoon ontwikkelen. Behalve die telefoon app, zal ik ook iets nodig hebben om de gegevens voor die app in te kunnen voeren.

Moet ik hier opnieuw investeren in een ‘invoer toepassing’ die ervoor zorgt, dat ik die gegevens in kan voeren? Of zijn er makkelijkere oplossingen. En je raadt het al. Er zijn makkelijkere oplossingen.

Ik kan namelijk een ‘Custom Post Type’ aanmaken in WordPress en WordPress uitsluitend gebruiken om de gegevens klaar te zetten voor de mobiele app.

Ik zou bijvoorbeeld de ‘Berichten’ kunnen misbruiken om hier geen blogposts, maar recepten in te schrijven. De ‘uitgelichte afbeelding’ is een fraaie manier om een foto van het gerecht te laten zien en met de ‘Categorieën’ en ‘Tags’ kan ik het zoeken naar de juiste recepten vergemakkelijken.

De titel gebruik ik natuurlijk voor de titel van het recept, en de ‘Tekst’ voor het recept zelf.

Wil ik meer en heb ik meer velden nodig, dan kan ik dat bijvoorbeeld doen door een plugin als ‘Advanced Custom Fields‘ of PODS te installeren…

Het idee is echter, dat ik WordPress niet gebruik om een website te tonen maar om content te leveren aan een andere toepassing. Dat kan een mobiele app zijn, een website gebouwd met een totaal ander CMS dan WordPress of een ‘nieuws ticker’ op een andere site.

We hebben het over ‘headless WordPress’, omdat de installatie een compleet backend systeem neerzet, maar er aan de ‘visuele kant’ van de site niets getoond wordt. WordPress is een beheerstool voor content. Niets meer, niets minder.

WP REST

Headless WordPress wordt mogelijk gemaakt door ‘WP REST’. WP REST is een technologie waardoor via een speciaal protocol gegevens kunnen worden uitgewisseld. WP REST is een WordPress specifieke implementatie van het REST protocol. En hoewel het REST protocol oorspronkelijk is ontworpen om informatie in het XML formaat te delen, wordt het de laatste jaren vrijwel exclusief gebruikt om dit in het zogenaamde ‘JSON’ formaat te doen. Omdat dit weinig overheid heeft en door veel programmeertalen direct verwerkt kan worden.

Wanneer je bijvoorbeeld van jouw WooCommerce website een app zou willen (laten) maken, zou je gebruik maken van dit WP REST (of eigenlijk een uitbreiding hiervan, omdat WooCommerce het WP REST protocol sterk uitbreidt) protocol. Jouw app gaat ‘WP REST’ praten met je shop.

Maar hier hebben we het nog steeds niet over een ‘headless WordPress’, omdat je nog steeds een website hebt.

Maar wat nu als je helemaal geen website wilt? Je wilt alleen een applicatie voor het invoeren van je gegevens voor je app, of voor informatie op een al bestaande niet-WordPress site?

Dan hebben we het inderdaad over ‘Headless WordPress’. Je gebruikt WordPress als een invoerapplicatie voor data. En die data worden doorgegeven aan je telefonie app.

Verschillende manieren!

Bij een telefonie app is ‘snelheid’ natuurlijk een eerste vereiste. Helaas… zelfs wanneer we WordPress onthoofden zal dit ‘headless WordPress’ niet per se snelheid garanderen. Eén van de problemen is namelijk, dat PHP/MySQL en Apache als server alles behalve een garantie voor snelheid zijn.

Je zou hier bijvoorbeeld een tussenstap willen maken, waarbij je de informatie die je uiteindelijk aan de telefoon aan wilt bieden in een ‘makkelijker formaat’ voorbewerkt. Bijvoorbeeld -in het voorbeeld van onze recepten database- door de informatie die de app opvraagt op de server alvast te cachen. Niet als ‘webpagina’, maar als uitkomsten van JSON queries.

Of misschien wil je de informatie synchroniseren met een object georienteerde database als MongoDB. Minder mogelijkheden als MySQL, maar met ‘voorbewerkte informatie’ wel stukken sneller. Onder andere omdat de response uit deze database in een direct verwerkbaar formaat voor JSON wordt aangeleverd.

Denk jij aan de ontwikkeling van een app en heb je een ‘backend’ nodig om de informatie aan te leveren, dit inclusief een snelle, begrijpbare ‘REST’ interface? Neem dan eens contact op. Ik ontwikkel geen mobiele apps (met uitzondering van heel specifiek voor WooCommerce), Maar een complete invoer toepassing voor de informatie noodzakelijk voor jouw app? Sinds 1992 ‘knoop’ ik al systemen aan elkaar…

Blijf bij!

Sinds 2010 schrijf ik op de WordXPression blog over WordPress, marketing, e-commerce en e-learning. En niet zonder succes, want in het eerste kwartaal van 2021 had ik gemiddeld 32000 unieke bezoekers per maand. En daarmee is deze blog één van de populairste blogs voor ondernemers over WordPress binnen het Nederlands taalgebied.

Zorg ervoor, dat je geen artikel mis en meld je aan voor de browser pop ups door op de rode bel links onder op de pagina te klikken en de instructies te volgen.