NL
De meeste mensen die met een CMS moeten werken, hebben daar niet voor gekozen. Ze zijn communicatiemedewerker, HR-adviseur of officemanager, en er is nu eenmaal iets dat op de website moet. Umbraco heeft een prettige backoffice — maar élke backoffice vraagt dat je leert waar de knoppen zitten, en voor iemand die er twee keer per jaar komt is dat gewoon vervelend.
Sinds Umbraco 14 hoeft dat niet meer per se. Dit is het verhaal van vier vacatures die als Word-bestand binnenkwamen en op onze site terechtkwamen zonder dat iemand de backoffice in hoefde.
In Umbraco 14 is de backoffice volledig herbouwd, en dat had een gevolg dat technisch klinkt maar heel praktisch uitpakt: de nieuwe backoffice is zelf een client van een API — de Management API. Elk scherm dat een redacteur ziet, praat onder water met diezelfde API.
Daarmee verdwijnt een hele categorie discussies. Bij een CMS met een API die er achteraf bij is gebouwd, is de vraag altijd: zit dit veld er ook in? Bij Umbraco is die vraag beantwoord door de architectuur. Wat een mens in de backoffice kan doen, kan een programma ook — niet omdat iemand daar een koppeling voor schreef, maar omdat het dezelfde deur is. Umbraco levert er bovendien een machineleesbare beschrijving bij, een OpenAPI-specificatie, zodat je niet hoeft te gokken hoe een pagina in elkaar zit.
Umbraco 15 maakte het bruikbaar voor koppelingen. Daarin verscheen de API-user: een gebruiker zonder wachtwoord, die niet in de backoffice kan inloggen en alleen namens een systeem een token ophaalt. Voor de rest is het een doodgewone gebruiker — hij zit in een gebruikersgroep en heeft precies de rechten die je hem geeft, tot op paginaniveau.
Concreet: er kwam een verzoek om de vacatures op onze eigen site te vernieuwen. Vier stuks, aangeleverd zoals dat meestal gaat — als één Word-bestand, met per vacature een kop, wat lopende tekst en een lijstje.
De klassieke route: iemand opent de backoffice, dupliceert een bestaande vacature, plakt de tekst over, controleert de opmaak, en herhaalt dat vier keer. Een uur of twee werk, en precies het soort klus waarbij je bij vacature drie een blokje vergeet.
De route die we nu namen: het Word-bestand ging naar een AI-agent met toegang tot een API-user, met de opdracht om een bestaande vacaturepagina als voorbeeld te nemen. De agent leest het document, leest via de API hoe zo'n pagina is opgebouwd — welke blokken, welke velden, in welke volgorde — en zet de nieuwe vacatures in diezelfde structuur neer.
Hier zit wat ons betreft het mooiste stuk. Schrijven via de Management API is niet hetzelfde als publiceren. Werk je via de API een pagina bij die al gepubliceerd is, dan slaat Umbraco dat op als openstaande wijziging: bezoekers blijven de oude versie zien, en in de backoffice staat de nieuwe versie klaar ter beoordeling. Pas als een mens op publiceren drukt, gaat hij live.
Dat legt de rolverdeling precies goed. De machine doet het werk waar mensen slecht in zijn: nauwkeurig overnemen, structuur consistent houden, niets vergeten. De mens doet het werk waar machines slecht in zijn: beoordelen of dit is wat we willen zeggen. En omdat de API-user zijn eigen rol heeft, kun je hem opsluiten in precies dat hoekje van de site waar hij mag komen.
Eerlijkheid hoort erbij, anders wordt dit een folder. Drie dingen kostten alsnog aandacht:
Met andere woorden: dit is vandaag geen knop die iedereen in de organisatie zomaar indrukt. Het is een werkwijze die wij inrichten. Maar de richting is duidelijk, en de tijdwinst was niet subtiel.
Terechte vraag, want WordPress kan dit ook — tot op zekere hoogte. De REST API zit sinds versie 4.7 uit 2016 in de core, en sinds 5.6 zitten er applicatiewachtwoorden in. Wie zegt dat WordPress geen API heeft, heeft niet gekeken.
Het verschil zit in twee dingen. Dekking: de WordPress-API kent berichten, pagina's, media en gebruikers, maar juist de dingen die een site eigen maken zitten er standaard niet in. Custom velden via ACF staan standaard uit in de API. Eigen contenttypes moeten expliciet worden vrijgegeven. En een pagina die met een page builder als Elementor is gebouwd, staat als één dichtgetimmerd blok in de database: technisch leesbaar, praktisch niet te bewerken. Een agent loopt daarmee vast op precies het punt waar een site interessant wordt. Rechten: een applicatiewachtwoord erft altijd de volledige rechten van de gebruiker die het aanmaakt. Je kunt een koppeling niet inperken tot één contenttype; het gangbare advies is een aparte gebruiker met een zo laag mogelijke rol, en die rollen zijn grover dan wat je in Umbraco kunt instellen.
De volledige vergelijking staat in Umbraco vs WordPress: de eerlijke vergelijking.
Overal waar content uit een ander systeem of uit een aangeleverd document komt, is deze route interessant: vacatures, productinformatie, locatiegegevens, evenementen, prijslijsten. Het patroon is steeds hetzelfde — de bron bestaat al ergens, en iemand zit hem over te typen.
Draait je site op Umbraco 15 of hoger, dan heb je alles al in huis en hoeft er niets bijgekocht te worden. Draait hij op 13 of ouder, dan is dit een van de redenen om de stap naar de actuele LTS te zetten.
Benieuwd wat dit voor jullie site zou schelen? Laat het weten via het formulier hieronder, bel 010 270 75 75 of mail hallo@admix.nl.
Adres
Postbus
Benieuwd wat dit voor jouw site betekent? Laat je gegevens achter en vertel kort waar je tegenaan loopt, dan nemen we contact met je op. We reageren doorgaans binnen één werkdag.
Liever direct contact? Bel of mail ons gerust.
De Management API kwam in Umbraco 14: sindsdien draait de backoffice zelf op die API, dus alles wat een redacteur kan, kan een koppeling ook. Voor koppelingen zonder mens erachter heb je een API-user nodig, en die kwam in Umbraco 15. Draai je op 15 of hoger, dan zit alles er al in.
Een backoffice-gebruiker zonder wachtwoord, die niet kan inloggen in de backoffice en alleen namens een systeem een token ophaalt. Verder is het een gewone gebruiker: hij zit in een gebruikersgroep en heeft precies de rechten die je hem geeft — welke secties, welke pagina's, welke handelingen. Zo kan een koppeling die alleen vacatures mag bijwerken ook echt niets anders.
Nee, en dat is precies de veiligheidsklep. Werkt een koppeling een pagina bij die al gepubliceerd is, dan bewaart Umbraco dat als openstaande wijziging: bezoekers blijven de oude versie zien tot een redacteur in de backoffice publiceert. Schrijven en publiceren zijn twee aparte handelingen, en je kunt de API-user het recht om te publiceren onthouden.
Deels. WordPress heeft sinds versie 4.7 een REST API in de core en sinds 5.6 ingebouwde applicatiewachtwoorden, dus koppelen kán. Het verschil zit in dekking en rechten: custom velden (ACF) staan standaard uit in de API, eigen contenttypes moeten expliciet worden vrijgegeven, en content uit een page builder als Elementor staat als één blok in de database. Daarnaast erft een applicatiewachtwoord altijd de volledige rechten van zijn gebruiker, terwijl een Umbraco API-user een eigen, fijnmazige rol krijgt.
Jawel — maar wel het juiste. Het overtypen en de opmaak verdwijnen; het beoordelen blijft. In de praktijk verschuift het werk van invoeren naar controleren en publiceren, en dat is precies de verdeling die je wilt: de machine is nauwkeurig, de mens bepaalt of de boodschap klopt.