Open source-CMS vs. WordPress

Två olika arkitekturer

För att förstå skillnaderna mellan WordPress och moderna open source-CMS behöver man först förstå den arkitektoniska skillnaden. WordPress är ett traditionellt CMS. Det betyder att innehållet, redigeringsgränssnittet och den publika webbsidan hänger ihop i samma system. Du skriver ett inlägg i adminpanelen, WordPress sparar det i databasen och genererar en HTML-sida som besökaren ser. Allt i ett paket.

Ett headless CMS fungerar annorlunda. Innehållet hanteras i ett system, men den publika webbsidan är ett separat projekt som hämtar innehållet via ett API. Ett API är i praktiken ett sätt för två system att prata med varandra. Frontenden frågar efter innehåll, CMS:et skickar tillbaka det i ett strukturerat format. Det låter kanske krångligare, men fördelen är att frontenden inte är låst till CMS:ets mallmotor. Du kan bygga webbsidan i Next.js, visa innehållet i en mobilapp eller skicka det till en digital skylt. Samma innehåll, flera kanaler.

Vad WordPress faktiskt är bra på

WordPress förtjänar inte det rykte det ibland får i utvecklarkretsar. Det är ett genuint bra verktyg för rätt uppgift. Det har en enorm gemenskap, miljontals teman och plugins, och är lätt att komma igång med även om man inte kan koda. För en blogg, en enkel företagssajt med ett fåtal sidor eller en mindre webbutik fungerar det ofta utmärkt. Har man redan ett team som kan WordPress och behoven är grundläggande finns det ingen anledning att krångla till det.

När plugin-beroendet blir ett problem

Problemen börjar när sajten växer. Säg att du driver en anläggning med stugor, aktiviteter och restauranger. Plötsligt räcker inte WordPress inbyggda sidtyper. Du behöver anpassade fält och installerar Advanced Custom Fields. Du behöver översättningar till tre språk och installerar WPML. Du behöver formulär, formulärvalidering och e-postnotifieringar och installerar Gravity Forms. Du vill ha SEO-optimering och installerar Yoast. En cache-plugin. En säkerhetsplugin. En bildoptimeringsplugin.

En WordPress-installation med tjugo plugins är inte ovanlig. Varje plugin är ett beroende, måste uppdateras, kan skapa konflikter med andra plugins och lägger till sin egen JavaScript och CSS på sidan. Resultatet blir en sajt som laddar långsamt och ett adminpanelsgränssnitt som känns som en lapptäckesamling av olika designers idéer om hur ett gränssnitt ska se ut.

Säkerheten är en annan aspekt. WordPress är världens mest attackerade CMS, för att inte tala om att 97 procent av nya säkerhetshål i WordPress-ekosystemet kommer från plugins, inte från grundsystemet. Varje plugin är en potentiell attackvektor, och med tjugo installerade ökar risken markant. Jag har själv varit med om plugins som har slutats att underhålla av skaparen vilket medförde ett säkerhetshål som utnyttjades av en kinesisk bot som placerade olämplig reklam på webbsidan. Webbsidan togs ner direkt för undersökning och det tog en bra stund att identifiera vad det var som orsakade problemet. Till slut upptäckte jag pluginet som hade blivit övergivet, tog bort det och ersatte det med ett annat. Säkerhetshålet var läckt, för stunden.

Ett plugin är ett beroende som behöver underhållas, en attackvektor som ska bevakas och en prestandakostnad som betalas vid varje sidladdning.

Vad headless CMS faktiskt innebär

Jag tror att headless CMS kan låta mer komplicerat än det är. I praktiken handlar det om att separera två saker som inte nödvändigtvis hör ihop, nämligen innehållet och presentationen av innehållet. Du skapar och redigerar innehåll i ett modernt webbgränssnitt. Det publiceras via ett API. En separat frontend, ofta byggd med Next.js, hämtar innehållet och bygger webbsidan.

Fördelarna är ganska konkreta. Prestandan blir bättre eftersom sidorna kan genereras statiskt vid publicering istället för att byggas om vid varje besök. Säkerheten blir bättre eftersom adminpanelen inte behöver vara tillgänglig från internet. Och flexibiliteten ökar eftersom samma innehåll kan användas på flera ställen. Ett hotell kan ha samma rumsbeskrivning på webbsidan, i appen och på en digital skärm i lobbyn. Man uppdaterar på ett ställe, och ändringen syns överallt, direkt.

Payload CMS

Payload CMS är ett open source headless CMS som på bara några år gått från uppstickare till ett av de mest omtalade verktygen i genren. Det är byggt i TypeScript och integrerat med Next.js, vilket gör att hela stacken är typad. Du definierar dina innehållstyper i kod istället för att klicka ihop dem i ett gränssnitt. Det låter kanske som en nackdel om man inte är utvecklare, men det betyder att innehållsmodellen är versionshanterad, testbar och går att återskapa exakt.

Payload har också några funktioner som sticker ut. Block Components låter redaktören bygga sidor med fördefinierade byggblock istället för att skriva allt i ett enda textfält. Live Preview gör att man ser ändringar i realtid utan att ladda om sidan. Lokalisering är inbyggt från grunden, så att översättning av innehåll inte kräver extra plugins. Systemet är självhostat, vilket betyder att du äger din data och inte är låst till en leverantörs molntjänst.

Nackdelen är att Payload kräver utvecklarkompetens för att sätta upp och konfigurera. Det är inget man installerar med ett klick och sedan väljer tema ur en meny.

Strapi

Strapi har funnits längre än Payload och har en större användarbas och community. Det är också open source och byggt på Node.js, men till skillnad från Payload är det inte lika intimt kopplat till Next.js. Strapi fungerar med vilken frontend som helst och erbjuder både REST- och GraphQL-API:er direkt ur lådan.

En av Strapis styrkor är adminpanelen. Den är betydligt modernare än WordPress och går att anpassa utan att skriva om hela gränssnittet. Content modeling görs via ett grafiskt gränssnitt, vilket kan vara en fördel om man inte har tillgång till utvecklare som är bekväma med att definiera modeller i kod. Strapi har också ett molnerbjudande, Strapi Cloud, för den som inte vill hosta själv.

Jämfört med Payload är Strapi något mer traditionellt i sin uppbyggnad. Innehållsmodeller definieras i adminpanelen snarare än i kod, vilket gör det snabbare att komma igång men mindre flexibelt för komplexa uppsättningar. Strapi har också haft en del växtvärk med stora versionsbyten som krävt omfattande migreringar. Flera utvecklare jag pratat med har gått från Strapi till Payload av just den anledningen.

Vad kostar det egentligen?

Kostnadsjämförelsen mellan WordPress och headless CMS är inte så enkel som den först verkar. WordPress core är gratis. Men en professionell WordPress-sajt kostar i praktiken en hel del. Hosting, premiumplugins och löpande underhåll tickar på månad efter månad. Ett typiskt premiumplugin kostar mellan 100 och 500 dollar per år, och har man tio sådana blir det snabbt pengar.

Ett headless CMS har generellt en högre initial utvecklingskostnad men lägre löpande kostnader. Du slipper pluginlicenser, säkerhetsuppdateringar av tredjepartskod är betydligt färre och mindre riskfyllda, och prestandan kräver mindre optimeringsarbete. Payload och Strapi är open source och gratis att använda, men du behöver hosting för CMS:et och för frontenden. Payload Cloud och Strapi Cloud finns som betalda alternativ för den som inte vill hosta själv.

När ska man välja vad?

Jag tänker så här. Är sajten enkel, statisk och ska upp snabbt? Kör WordPress. Har du redan ett team som kan WordPress och inga behov av avancerade funktioner? Kör WordPress. Är budgeten extremt begränsad? Kör WordPress, men var medveten om att de löpande kostnaderna kan äta upp besparingen över tid.

Ska sajten däremot vara en central del av verksamheten? Är prestanda och säkerhet affärskritiskt? Behöver innehållet publiceras på flera språk, i en app eller på andra plattformar? Då tror jag att Payload eller Strapi är det bättre valet. Payload om du har tillgång till utvecklare och vill ha maximal kontroll. Strapi om du vill ha en mjukare start och ett större community.

Att bygga ett eget CMS från grunden

Både Payload och Strapi är utmärkta verktyg. Men det finns en nivå till. Den nivån där verksamhetens behov är så specifika att även ett konfigurerbart open source-CMS blir en kompromiss.

Jag tänker på verksamheter som har många olika innehållstyper, komplexa relationer mellan data, flera språk och ett behov av specialverktyg som inte finns som färdiga plugins. En semesteranläggning med stugor, camping, restauranger, aktiviteter och evenemang. En kommun med hundratals olika sidtyper och integrationer mot externa system. Ett företag som behöver en kundportal, ett bokningssystem och en AI-assistent som alla pratar med samma data.

Ett skräddarsytt CMS är inte rätt väg för alla. Det kräver en betydande initial investering i utveckling. Du binder dig till en utvecklare eller ett team som kan systemet. Och du tar på dig ansvaret för drift, backup och uppdateringar själv, även om moderna verktyg som Docker och automatiserade backuper gör det betydligt enklare än för några år sedan.

Men för verksamheter med större behov av anpassningar är detta det bästa valet. Du får ett system som är byggt för exakt din verksamhet, inte för en generisk marknad. Inga plugins att uppdatera, inga licenskostnader, inga kompromisser med hur datamodellen ser ut. Varje funktion finns där för att den löser ett konkret problem, inte för att den råkade finnas som plugin.