Drupal

Drupal er en open source platform til content management og digitale oplevelser. Den bruges til at bygge hjemmesider og applikationer, hvor indhold, brugere, rettigheder, workflows og integrationer ofte skal struktureres mere detaljeret end på en helt enkel brochurehjemmeside. Drupal-projektet beskriver selv fleksibilitet og modularitet som centrale egenskaber.

Som andre CMS'er gør Drupal det muligt at oprette og redigere indhold uden at kode hver side fra bunden. Det særlige ligger især i den måde, indhold kan modelleres og genbruges på. I stedet for kun at tænke i “sider” kan man oprette indholdstyper med felter, relationer og visninger, som efterfølgende bruges forskellige steder på et site eller leveres videre til andre kanaler.

Drupal er open source og distribueres under GPL. Funktionalitet kan udvides med moduler, mens themes håndterer præsentationen. Drupal Core er selve fundamentet, og Drupal-projektet har desuden et nyere Drupal CMS-produkt oven på core, der samler flere funktioner i en mere færdig startløsning. Det er derfor vigtigt at skelne mellem Drupal som underliggende platform og den konkrete distribution eller installation, en virksomhed bruger.

Sammenlignet med WordPress bliver Drupal ofte valgt til løsninger med mere struktureret indhold, avancerede brugerroller, redaktionelle workflows eller mange integrationer. Det betyder ikke, at Drupal kun kan bruges til store organisationer, eller at WordPress ikke kan løse komplekse opgaver. Forskellen ligger i arkitektur, økosystem og den måde projekterne typisk bygges og vedligeholdes på.

Drupal kan også bruges som backend i en headless eller decoupled løsning. Her administreres indholdet i Drupal, mens frontend eksempelvis bygges i et separat JavaScript-framework og henter data gennem et API. Det giver fleksibilitet, men øger også antallet af dele, der skal udvikles, testes og driftes.

Et Drupal-projekt bør begynde med informationsarkitekturen. Hvilke typer indhold findes? En organisation kan eksempelvis have nyheder, medarbejdere, afdelinger, arrangementer, dokumenter og projekter. Hvis de oprettes som strukturerede indholdstyper med egne felter, kan de filtreres, genbruges og vises på flere måder uden at redaktøren skal kopiere det samme indhold manuelt.

Det er en af styrkerne ved Drupal. En medarbejderprofil kan eksempelvis indeholde navn, titel, afdeling, foto, telefon og fagområder. Den samme profil kan vises på medarbejdersiden, i en afdelingsoversigt og som kontaktperson på en projektside. Data ligger ét sted, mens præsentationen kan variere. Den type struktur kan være sværere at vedligeholde, hvis alt er bygget som frie tekstblokke.

Drupal udvides med moduler. Core indeholder centrale funktioner, mens contributed modules kan tilføjes fra Drupal-fællesskabet, og custom modules kan udvikles til virksomhedens særlige behov. Moduler kan håndtere alt fra felter og visninger til integrationer og workflows. Som med et WordPress-plugin bør et modul vurderes på vedligeholdelse, kompatibilitet, sikkerhed og behov — ikke kun på, om det kan installeres.

Themes styrer udseendet, men professionelle Drupal-løsninger indeholder ofte også frontend-komponenter, templates og build-processer. Designændringer kan derfor kræve mere end at vælge et nyt theme i administrationen. Hvis løsningen er specialbygget, bør designbibliotek og kodebase betragtes som en del af produktet.

Brugerroller og rettigheder bør planlægges tidligt. En redaktør behøver måske kun at oprette kladder, mens en fagansvarlig må godkende indhold, og en administrator håndterer systemopsætning. Drupal er velegnet til at modellere den slags forskelle, men mange rettigheder skaber også kompleksitet. Brug mindst mulige privilegier og dokumentér, hvorfor rollerne findes.

Driften kræver også disciplin. Drupal-projektets sikkerhedsvejledning understreger, at core, moduler og themes skal holdes opdateret. En løsning kan være teknisk solid ved lancering og alligevel blive sårbar, hvis ingen følger sikkerhedsmeddelelser eller har ansvar for opdateringer. Hosting, backup, staging og deploy-proces bør derfor være en del af projektet fra begyndelsen.

Mange moderne Drupal-projekter bruger Composer til at styre PHP-afhængigheder. Det gør opdateringer mere kontrollerbare, men stiller også krav til udviklingsworkflowet. En produktion bør ikke være det eneste sted, hvor kode og konfiguration findes. Kildekode, konfiguration og dokumentation skal kunne genskabe løsningen.

Integrationer bør beskrives som dataflows. Hvis Drupal modtager produkter fra et ERP-system eller sender formularer til et CRM, skal man vide, hvilket system der er master, hvilke felter der overføres, hvordan fejl håndteres, og hvad der sker ved ændringer. Ellers bliver integrationen let en skjult afhængighed, ingen tør røre efter to år.

En landsdækkende organisation har 40 lokale afdelinger. Hver afdeling har medarbejdere, arrangementer, dokumenter og egne kontaktsider. På den gamle hjemmeside er meget af indholdet kopieret manuelt, så telefonnumre og medarbejderdata ofte er forskellige fra side til side.

I en Drupal-løsning oprettes afdelinger, medarbejdere og arrangementer som separate indholdstyper. En medarbejder kobles til én eller flere afdelinger via relationer. Når et telefonnummer ændres, redigeres medarbejderprofilen én gang, og ændringen slår igennem alle steder, hvor profilen bruges.

Organisationen har samtidig et centralt nyhedsflow. Lokale redaktører kan oprette kladder, men kun regionale redaktører kan publicere. Rettigheder og workflow bliver derfor en del af CMS-modellen i stedet for en mundtlig aftale om, hvem der må trykke på knappen.

Et eksternt medlemssystem leverer basisoplysninger om afdelinger gennem et API. Drupal gemmer de data, der er nødvendige for hjemmesiden, mens medlemssystemet fortsat er master. Hvis en afdeling skifter adresse, ændres den ét sted og synkroniseres videre.

Projektet kunne i princippet også bygges i andre systemer. Drupal vælges, fordi struktur, relationer, roller og integrationer fylder meget i kravene. Den tekniske gevinst kommer altså ikke fra navnet Drupal, men fra at platformens styrker matcher opgaven.

Den første faldgrube er at vælge Drupal, fordi projektet lyder “enterprise”. En avanceret platform er ikke automatisk den rigtige løsning. Hvis behovet reelt er ti informationssider og en kontaktformular, kan udviklings- og driftsapparatet blive større end opgaven kræver.

Den modsatte fejl er at undervurdere et eksisterende Drupal-site. Mange løsninger indeholder specialmoduler, særlige indholdstyper, migrationer, integrationskode og konfigurationsstyring. Man kan ikke nødvendigvis flytte siden ved at eksportere brødtekster og billeder.

En anden faldgrube er for mange modules. Drupal er modulært, men hvert ekstra modul giver afhængigheder og vedligeholdelse. Officiel dokumentation peger også på, at installerede moduler kan påvirke den tid, der bruges på at generere sider. Installer derfor ikke funktioner “for en sikkerheds skyld”.

Pas også på med rettigheder. Et fleksibelt adgangssystem kan ende i en uoverskuelig matrix, hvor ingen ved, hvorfor en bruger kan redigere én sektion men ikke en anden. Roller bør beskrive reelle arbejdsfunktioner og testes med rigtige brugerprofiler.

Ved redesign er det fristende kun at skifte frontend. Hvis indholdsmodellen nedenunder er blevet rodet gennem mange år, flytter problemet bare med. Brug et større redesign til at gennemgå felter, relationer, gamle content types og moduler, som ikke længere har et formål.

Endelig er der opdateringerne. Sikkerhedsopdateringer til core og contributed projects skal håndteres løbende. En løsning, der kræver specialkode, bør have en aftalt proces for test og deployment, så opdateringer ikke udskydes, fordi alle er bange for at ødelægge produktionen.

Drupal-projektet skelner i dag mellem Drupal Core og Drupal CMS. Core er det underliggende framework og CMS-fundament, mens Drupal CMS er en mere samlet løsning bygget oven på core med fokus på hurtigere site-building. Begge bygger på samme open source-grundlag.

Drupal er API-first orienteret og bruges derfor ofte i løsninger, hvor samme indhold skal ud på flere kanaler. En artikel kan eksempelvis administreres centralt og leveres til website, app eller andre interfaces. Det kan være en fordel, men en headless arkitektur bør vælges, fordi der er et reelt behov — ikke fordi den lyder moderne.

Modulariteten gør Drupal fleksibelt. Core-moduler leverer basisfunktioner, contributed modules kommer fra fællesskabet, og custom modules kan udvikles til særlige behov. Denne fleksibilitet betyder samtidig, at dokumentation af afhængigheder er vigtig ved overdragelse.

Open source betyder, at virksomheden ikke er bundet til en proprietær CMS-licens for selve Drupal. Det betyder ikke, at projektet er gratis. Udvikling, design, hosting, integrationer, drift og support kan være betydelige poster, især på komplekse løsninger.

Hvis en eksisterende Drupal-løsning skal erstattes med en anden platform, bør migrationen starte med data og funktioner frem for design. Kortlæg indholdstyper, felter, relationer, URL'er, brugere, integrationer og workflows. Først derefter kan man vurdere, hvad der kan flyttes direkte, hvad der skal ombygges, og hvad der bør pensioneres.

For virksomheder, der ikke har behov for Drupals dybe struktur, kan en mere enkel hjemmesideløsning være lettere at administrere. Det er netop derfor, CMS-valg bør være en konsekvens af kravene og ikke omvendt.