Drupal, WordPress And All The Rest – How To Choose a Web Platform

Uppdatering: den här artikeln är från 2013 och kan vara inaktuell. Du kanske skulle vara intresserad av att läsa Vi måste prata om det här med CMS.

På SthlmConnection hjälper vi våra kunder utvärdera sina behov och ta fram en lämplig plan för sin digitala närvaro. Därefter söker vi upp de bästa lösningarna för den tekniska implementeringen, det vill säga de verktyg som är mest lämpliga för projektet. Som ni kanske vet är Drupal vår vanligaste allt-i-ett-lösning – ett kraftfullt open source-publiceringssystem som har hjälpt oss under många år och i många av webbprojekten i vår portfolio.

Samtidigt är det viktigt att vara öppen för olika lösningar och inte välja en plattform bara för att den är mest välbekant. Man brukar säga att om allt man har är en hammare börjar till slut allt att se ut som spikar. Det är anledningen till att vi inleder nya projekt med att definiera mål och koncept, och först därefter börjar göra tekniska överväganden.

Men ibland kommer kunder till oss med en befintlig idé om vilket publiceringssystem de vill använda. Ibland är det Drupal (och vi håller oftast med), men ett annat vanligt önskemål är att vi ska bygga webbplatsen i WordPress. När det händer brukar vi oftast hävda att vad det än är som man är ute efter med WordPress så går det att få det med Drupal lika väl, samtidigt som man får ett antal andra fördelar.

Det här var egentligen ett långt sätt att introducera ämnet för den här artikeln, som är: vad är skillnaderna mellan Drupal och WordPress, vilka är fördelarna med respektive plattform, och hur ska man veta vilken man ska välja för sitt projekt?

Det är också viktigt att förstå att Drupal och WordPress bara är två alternativ bland många andra, och det finns definitivt projekt där det finns alternativ som passar bättre. Två lösningar som vi ibland rekommenderar för enklare projekt är Jekyll och Tumblr (kanske något överraskande). För projekt med väldigt specifika behov eller mer komplex funktionalitet är ofta Ruby on Rails ett bra val. Men mer om dessa senare. (Jag undviker att nämna några fler verktyg för att skydda läsarens sinnesro, men det finns många många fler, och några av er kommer säkert sakna sin favorit bland verktygen jag tar upp.)

Drupal och WordPress – grunderna

Drupal och WordPress har gemensamma drag: de är båda populära, mogna open source-publiceringsverktyg byggda i PHP. De har båda stora communityn med gedigen support och gott om tilläggsfunktionalitet. WordPress är absolut störst, men Drupal är också en av världens mest utbredda publiceringssystem.

Drupal föddes 2001 i form av ett diskussionsforum, medan WordPress släpptes 2003 som ett bloggverktyg. Detta säger något om skillnaderna mellan dem: Drupal har sin bakgrund inom communitybyggande, medan WordPress är optimerat för att publicera artiklar. Sedan dess har båda systemen breddat sitt användningsområde betydligt. Särskilt Drupal marknadsför sig som en generell publiceringsplattform sedan ett antal år tillbaka.

Komplexa och enkla projekt

Den viktigaste aspekten att ta hänsyn till när man ska välja ett publiceringsverktyg är omfattningen och komplexiteten på projektet. Illustrationen ovan visar ungefär vilka verktyg jag ser som lämpliga val för ett antal olika typer av webbprojekt, och resten av den här texten handlar om varför. (Kom ihåg att sådana här frågor handlar mycket om personliga åsikter. Tänk också på att illustrationen ovan ger en förenklad bild av hur det ser ut i verkligheten. Projekt kan vara komplexa på olika nivåer, och en mediesajt kan mycket väl vara mer komplex än exempelvis en communityplattform.)

De projekttyper jag använder som exempel är:

• Broschyrsajt – statiskt innehåll, oftast med en väl utarbetad design.
• Blogg – ett enkelt flöde av inlägg.
• Nyhets/mediesajt – artiklar, sektioner, olika skribenter, bloggar osv.
• Organisationswebbplats – presentationssidor, nyheter, medlemssidor, integration med externa system, flerspråkighet mm.
• Communityplatform – användargenererat innehåll, användargrupper, individuellt anpassat innehåll, integration med sociala medier osv.
• Webbtjänst – unik, skräddarsydd funktionalitet, starkt individualiserat innehåll, integration med e-post/sms/kalender/enheter, projektspecifika APIer, service oriented architecture, flera plattformar såsom mobilappar, osv.

Varför är då Drupal placerat mer till höger än vad WordPress är i illustrationen? Generellt sett är Drupal bättre än WordPress på att hantera komplexa projekt som kräver en hög grad av flexibilitet. Det finns många skäl till det, men i korhet går det ut på att Drupal har en mer generaliserad, abstrakt arkitektur, där olika funktionalitet och innehållstyper använder samma generella byggstenar. Det gör att möjligheterna att anpassa, kombinera och integrera dessa byggstenar i stort sett är oändliga.

WordPress gör det möjligt att anpassa och bygga egen funktionalitet ovanpå kärnan, men standardbyggstenarna är färre och mindre kraftfulla. Det betyder att olika tilläggsfunktioner ofta inte är integrerade med varandra, som i Drupal, om de inte har utvecklats specifikt för att fungera ihop.

Några specifika områden där Drupal har bättre funktionalitet än WordPress är:

• Det kraftfulla systemet för innehållsmodellering
• De flexibla presentationsfunktionerna som tillhandahålls av Views-modulen
• Användarrelaterade funktioner (roller, rättigheter, grupper)
• Flerspråkighet.

Enklare projekt som en broschyr-sajt eller en blogg är vanliga WordPress-projekt, och det är ingen tvekan om att det är ett bra verktyg för det området. Man kan använda Drupal för sådant också, men det kan vara overkill beroende på vad man vill bygga – särskilt om man inte redan kan Drupal.

Alternativen

Jekyll är ett av våra favoritverktyg när det gäller enklare projekt (även om Jekyll-projekt också kan vara komplexa.) Det kan ofta ses som ett alternativ till WordPress. Jekyll är en open source statisk webbplatsgenerator skriven i Ruby. Att den är statisk betyder att live-sajten alltid är snabb, säker, stabil och i stort sett underhållsfri. Nackdelen är att den inte har något onlinegränssnitt för redaktörer (men det finns lösningar – se nedan). Det finns inte heller någon användarinloggning, kommentarer, eller något annat som skulle kräva en serverapplikation. Tänk dock på att man kan göra väldigt mycket i klienten nu för tiden!

Tumblr är egentligen inte ett publiceringsverktyg som man kan ladda ner och installera själv. Det är en gratis bloggtjänst som erbjuder mycket trevliga innehållsfunktioner för sidor, inlägg och media. Den låter dig anpassa frontend-delarna av din blogg på valfritt sätt, vilket betyder att så länge innehållsstrukturen passar dina behov så kan du i stort sett bygga vilken sajt du vill på plattformen – särskilt som Tumblr tillåter att man använder sin egen domän. Fördelarna är lockande: ingen installation, inga utvecklingskostnader, inget underhåll – och gratis hosting. Vad man offrar är ägandet av plattformen. Tumblr skulle i teorin kunna stänga ner eller ändra sina villkor från en dag till nästa – men så länge man litar på dem (vilket många gör) och ifall det inte skulle innebära katastrof att behöva flytta till en annan plattform, så kan Tumblr vara ett mycket bra val.

Ruby on Rails skiljer sig från WordPress och Drupal på så sätt att det inte är ett publiceringssystem i grunden. Rails är ett applikationsramverk som låter dig utveckla skräddarsydda webbapplikationer med hjälp av ett kraftfullt och smidigt API. Man får betydligt mindre från start, men ramverket gör färre antaganden om din applikation, och det hjälper dig att snabbt bygga upp precis de funktioner du behöver. Det betyder att det är ett bra alternativ om man inte vill anpassa sitt projekt till standardbeteendet i någon av de andra lösningarna. Rails fungerar också mycket bra som backend till andra applikationer, såsom mobilapplikationer, applikationer i sociala medier och andra parter om behöver kunna integrera med din plattform.

Budget och utvecklingstid

Flexibiliteten och den relativa komplexiteten hos Drupal jämfört med WordPress betyder att det oftast tar längre tid att komma igång. Man kan starta en WordPress-sajte väldigt snabbt, särskilt om man använder färdiga teman och inte behöver göra någon egentlig egen anpassning. Med Drupal får man inte så mycket på köpet. Man måste oftast installera ett antal tilläggsmoduler, även för enklare sajter, och bygga ett eget tema för projektet. (Det finns dock ett antal Drupal-distributioner som är förberedda för specifika användningsområden. Med dem kan man definitivt komma igång snabbare.) Med ramverk som Ruby on Rails får man oftast räkna med ännu längre utvecklingstid, eftersom det är mer som att börja med ett tomt ark varje gång. Det här är inte en brist hos Drupal eller Ruby on Rails – det är en naturlig följd av de problem som verktygen är tänkta att lösa.

Det är viktigt att förstå att snabbheten med WordPress bara är en fördel om det faktiskt passar för de aktuella behoven. Om man behöver en helt egen design – inga problem. Man kan göra alla möjliga kreativa saker med frontend-utveckling och JavaScript. Att lägga till backend-funktionalitet är också fullt möjligt, men som jag skrev tidigare är det bara sant till en viss gräns. När applikationen växer riskerar den att bli alltmer svårhanterlig i takt med att du utvecklar dig bort från WordPress-kärnan. Som sagt, det handlar i slutändan om projektets behov – och att välja en snabb lösning kan visa sig bli dyrt i längden.

Om man har en tajt budget är det första man bör göra att begränsa projektets omfattning och fokusera på de viktigaste bitarna först. (Kanske är det faktiskt viktigare för ditt projekt med en aktiv närvaro på sociala medier än att bygga en ny webbplats?) Det är mycket viktigare att hitta rätt med de grundläggande delarna än att försöka få med så många funktioner som möjligt när budgeten är begränsad. Förutom det bör man också fundera över hur man vill att projektet ska utvecklas i framtiden. Om behoven är relativt avgränsade, både nu och i framtiden, så kan WordPress mycket väl vara rätt val. Kanske skulle Tumblr kunna funka lika bra, och det kan vara en mycket effektiv lösning. Med Jekyll handlar det oftast (inte alltid) om en mer specialbyggd webbplats, så det behöver inte vara snabbast i början, men när det väl är klart är kostnaderna för underhåll och hosting i stort sett noll.

Användarvänlighet

WordPress hyllas ofta för att det är så enkelt att använda för skribenter. Man har länge pratat om det som WordPress styrka och Drupals svaghet. Skribenter och redaktörer gillar oftast WordPress tack vare det smidiga och välbekanta gränssnittet som man hanterar innehållet med, och tack vare att man när man har lärt sig använda det kan administrera i stort sett vilken WordPress-sajt som helst. Det finns också mobil-appar för iOS och Android som gör det lätt att lägga upp innehåll på en WordPress-sajt när man är ute på språng.

Drupals administrationsgränssnitt för innehåll är habilt från start, men inte fantastiskt. (Drupal 8 lovar många förbättringar på det här området.) En viktig skillnad mot WordPress är att innehållshanteringen i Drupal beror så mycket på strukturen på den aktuella webbplatsen. Drupal gör färre antaganden om vilka typer av innehåll du kommer vilja använda, så innehållshanteringen är mer generaliserad, och ärligt talat lite klumpig ibland. Det är upp till den som bygger sajten att förbättra situationen genom att installera editor-pluginer, skapa egna adminsidor som visar olika typer av innehåll och så vidare. Det positiva är att det här är relativt enkelt att göra. (Det negativa är att det ofta prioriteras ner till förmån för de delar som besökarna ser.)

Tumblr har ett jättebra administrationsgränssnitt, och en snygg mobilapp för att hantera innehållet. Jekyll har inget gränssnitt över huvud taget – tanken är att man hanterar sitt innehåll som vanliga textfiler (vilket faktiskt är ett väldigt effektivt gränssnitt), men det finns ett projekt som heter Prose som erbjuder ett webbgränssnitt för att hantera Jekyll-innehåll via Github. Med Rails är gränssnittet helt och hållet upp till utvecklaren, men i praktiken löser man det ofta snabbt och enkelt med färdiga paket som RailsAdmin som ger ett enkelt, utbyggbart administrationsgränssnitt automatiskt.

Utvecklingsprocessen

Hur kraftfull en publiceringsplattform än är handlar webbygge i slutändan ändå alltid om programmering: att skriva källkod i olika programmeringsspråk för att etablera projektets struktur och funktionelitet. Precis som utvecklare i allmänhet använder webbutvecklare bra verktyg för att strukturera sin kod, förenkla samarbete med andra utvecklare och handskas med projekt som förändras kontinuerligt över tid. Exempelvis gör versionshanteringssystem som Git att team kan jämföra olika versioner av filer, arbeta med samma fil samtidigt oberoende av varandra och trycka ut ändringar till olika miljöer (såsom utveckling, testning och produktion).

Jekyll och Ruby on Rails är båda helt kod-drivna, vilket betyder att det är väldigt naturligt att använda den här typen av utvecklarverktyg. Både WordPress och Drupal bygger däremot på att man gör mycket av utvecklingen genom ett administrationsgränssnitt – utan att skriva någon kod. Webbplatsens struktur lagras i en databas, tillsammans med allt innehåll, användardata med mera.

Det här betyder att de i stor utsträckning går miste om de hållbara arbetsflöden som vanligtvis används inom programvaruutveckling i allmänhet. Det databasdrivna upplägget fungerar bäst när det är en enskild person som bygger en ny webbplats från scratch. Om man är ett team som bygger en sajt på det här sättet måste alla jobba mot en central kopia där slutgiltig konfigurering görs, och man måste samordna det så man inte kommer i vägen för varandra. Ett annat problem uppstår när man redan har en befintlig webbplats som man behöver göra omfattande förändringar på utan att ta den offline. Det är en utmaning eftersom sådana förändringar måste utvecklas och testas på en separat miljö innan man försöker applicera dem på livesajten.

För att råda bot på problemet har Drupal smarta sätt att samla in denna konfiguration och exportera den till kod automatiskt. (Drupal 8 har ett särskilt core-initiativ som jobbar med dessa frågor.) Ihop med manuellt skriven kod kan den sen tas in i versionshantering för att förenkla samarbetet inom team och för att göra det möjligt att snabbt sjösätta ny funktionalitet. Enligt min åsikt är det här en enorm fördel med Drupal jämfört med WordPress. Faktum är att det skulle vara svårt att utveckla stora, komplexa webbplatser utan denna möjlighet. (Å andra sidan lider inte WordPress lika mycket av att vara databascentrerad, eftersom det inte finns lika många byggstenar att jobba med i administrationsgränssnittet som i Drupal.

Det betyder dock inte att Drupal nödvändigtvis kan betraktas som en utvecklarvänlig plattform. Ruby on Rails och liknande system är framtagna med smidig utveckling som främsta mål, medan Drupal, precis som de flesta publiceringsplattformar, i första hand fokuserar på att erbjuda ett kraftfullt webbgränssnitt.

Den här typen av frågor är inget som slutanvändaren eller sajtägaren ser direkt, men de avgör ändå i vilken utsträckning man kommer kunna utveckla en webbplats kontinuerligt med en hållbar projektstruktur och ett bra arbetsflöde.

Drift och underhåll

Drupal och WordPress använder samma serverarkitektur – den mycket vanliga LAMP-miljön. Drupal kräver i allmänhet mer serverresurser, men det beror väldigt mycket på den aktuella webbplatsen. Utbudet av hosting-företag som har stöd för den här arkitekturen är dock enormt, så det går alltid att hitta prisvärda driftlösningar.

Jekyll behöver bara en webbserver som kan publicera statiska filer, vilket gör driften väldigt billig och enkel. Tumblr har gratis hosting. Ruby on Rails har generellt lite högre krav på servermiljön, men det finns många driftlösningar som specialiserar sig på Rails-support.

Att underhålla en webbplats kan inbegripa många olika saker, men de vanligaste arbetsinsatserna är övervakning och prestandaoptimering, samt säkerhetsuppdateringar av grundsystemet och tilläggsmoduler. Underhållsprocessen ser väldigt lika ut med Drupal och WordPress. En skillnad är att WordPress är mer exponerat för säkerhetproblem, så man måste vara särskilt noga med att hålla plattformen konstant uppdaterad med de senaste säkerhetsuppdateringarna. Ruby on Rails har liknande underhållsbehov som Drupal och WordPress, även om det är en väldigt annorlunda plattform.

Jekyll och Tumblr kräver i stort sett noll underhåll, eftersom den första hostas som statiska filer, och den andra sköts om av Tumblr-tjänsten.

Slutsatser

Att välja rätt platform för ett webbprojekt handlar om ett antal överväganden som jag har försökt beskriva i den här artikeln:

• Projektkrav och komplexitet
• Budget och tid för lansering
• Utvecklingsprocess och projektets hållbarhet
• Drift och underhåll

Förutom det måste man ta hänsyn till de färdigheter och den kunskap som man själv och teamet har. Att lära sig nya plattformar är roligt och viktigt, men om det finns budget- och/eller tidsramar är det förmodligen effektivast att använda ett verktyg man redan kan, förutsatt att det faktiskt lever upp till projektets krav.

Jag hoppas att den här genomgången har känts givande, och att den kommer att hjälpa dig att välja plattform för ditt nästa webbprojekt!

Mer läsning

Stort tack till Henrik Sjökvist, Per Sandström och Jacob Brydolf som har läst och gett sitt input!