WordPress driver cirka 43% af alle websites på internettet. Det tal citeres som bevis på at WordPress er det rigtige valg - men det er omtrent lige så meningsfuldt som at argumentere for at Excel er det rigtige værktøj til alt, fordi halvdelen af verden bruger det til budgetter, projektstyring og ting der burde have været en rigtig database.
Sandheden er at WordPress bruges til en masse projekter der aldrig burde have været WordPress. Og der er nogen - bureauer, freelancere, hostingudbydere - der tjener gode penge på at du ikke ved det. Ikke fordi de er onde, men fordi WordPress er hurtigt at sælge, nemt at demonstrere og enkelt at fakturere timer på.
Det her er ikke et angreb på WordPress. Det er et forsvar for at træffe et bevidst valg - fordi det valg holder i årevis.
Det ærlige udgangspunkt
Hverken Laravel eller WordPress er universelt bedre. De er bygget til fundamentalt forskellige formål, og problemet opstår ikke når folk vælger WordPress til en blog - det opstår når de vælger WordPress til et bookingsystem, en SaaS-platform eller et komplekst integrationsprojekt, fordi "det er nemmere at komme i gang med."
Nemmere at komme i gang med er ikke det samme som nemmere at drive, vedligeholde eller udvide. Det er en distinktion der koster virksomheder dyrt - typisk 12-24 måneder efter lanceringen, når systemet begynder at knage under sin egen vægt.
Valget mellem Laravel og WordPress er ikke et teknisk spørgsmål. Det er et arkitekturspørgsmål. Og arkitektur handler om fremtiden, ikke om hvad der er hurtigst at bygge i dag.
Hvad WordPress faktisk er godt til
WordPress er et CMS. Et rigtigt godt CMS. Og når det bruges som det, leverer det enorm værdi - hurtigt og til en rimelig pris.
Blogs og redaktionelle sites: WordPress er født til indhold. Editoren er moden, brugerroller er gennemtænkte, og der er et kæmpe økosystem af redaktionelle værktøjer. Et mediehus, en vidensbase eller et magasin-site er oplagt WordPress-territorium.
Brochuresider og marketingsites: Virksomheder der har brug for at opdatere tekst, billeder og kampagnesider uden at involvere en udvikler. WordPress med et godt page builder-setup løser det præcist.
Simple webshops: WooCommerce er et modent produkt til standardiserede webshops med normale produktstrukturer, standardiseret checkout og begrænset forretningslogik. Det virker - inden for sine grænser.
SEO-drevne sites: WordPress har et modent SEO-fundament, og med plugins som Signocore SEO eller dedikerede strukturerede data-løsninger kan du bygge teknisk stærke sites med minimal eller ingen kode.
Fællestrækket er: indhold i centrum, forretningslogik i periferien, og et team der ikke nødvendigvis er udviklere. Det er WordPress' hjemmebane.
Hvad WordPress ikke er skabt til
Her er det bureauerne ikke fortæller dig, når de pitcher WordPress til dit næste projekt.
WordPress er bygget på en datamodel der er designet til posts og pages. Alt andet - produkter, bookinger, brugerprofiler, ordrer, relationer mellem entiteter - er workarounds oven på den model. Custom post types, Advanced Custom Fields og meta-tabeller er geniale hacks, men de er stadig hacks. Når din forretningslogik er kompleks nok, begynder det at vise sig.
Kompleks forretningslogik som afhængige tilstande, avancerede brugerflows eller domænespecifikke regler er smertefulde at implementere i WordPress. Du ender med at skrive PHP der kæmper mod frameworket i stedet for at arbejde med det.
Skræddersyede workflows - tænk godkendelsesprocesser, multi-step formularer med betingede logikker, automatiserede notifikationer baseret på tilstandsændringer - kan teknisk set bygges i WordPress, men de kræver enten dyre plugins med begrænset fleksibilitet eller custom kode der ikke har noget naturligt sted at bo i arkitekturen.
API-first arkitektur er teknisk muligt med WordPress REST API, men WordPress er ikke designet til det. Du får en API der afspejler CMS-arkitekturen, ikke din forretningsdomænemodel. Hvis din frontend er en React- eller Vue-app der kalder en API, og backenden er WordPress - spørg dig selv om du egentlig bruger WordPress, eller om du bruger en database med en masse overhead.
Høj datakompleksitet med mange-til-mange-relationer, komplekse søgefiltre og rapportering på tværs af entiteter er WordPress' akilleshæl. Databasestrukturen er ikke designet til det, og du betaler performance-prisen.
Hvad Laravel løser - i praksis
Laravel er ikke et CMS. Det er et MVC-framework der giver dig et struktureret fundament til at bygge præcis den applikation din forretning kræver - uden at arve en andens antagelser om hvad du bygger.
Det betyder noget konkret i disse scenarier:
SaaS-platforme: En virksomhed der bygger et abonnementsbaseret produkt med brugerkonti, roller, betalingsintegration og tenant-isolation. I WordPress ville du lappe det sammen med plugins og custom kode i functions.php. I Laravel designer du datamodellen, definerer dine domæneentiteter og bruger Eloquent ORM til at udtrykke præcis de relationer din forretning har - ikke de relationer WordPress antager du har.
Bookingsystemer: Kompleks tilgængelighed, ressourcekonflikter, tidszoner, notifikationer og betalingshåndtering. Et bookingsystem er et tilstandsmaskine-problem - du har entiteter der bevæger sig gennem tilstande med regler for hvornår og hvordan. Laravel Queues, Events og Jobs giver dig det fundament. WordPress giver dig cron-jobs og hooks.
Integrationsplatforme: Systemer der skal tale med ERP, CRM, betalingsgateways og tredjepartsservices i realtid. Laravel er bygget til det - med en robust HTTP-klient, køsystemer til asynkron behandling og en arkitektur der gør det naturligt at isolere integrationslogik. Se mere om hvad det kræver under automatisering og integrationer.
Det afgørende er ikke at Laravel er "bedre" - det er at Laravel giver dig et blankt lærred med strukturerede værktøjer, hvor WordPress giver dig en halvfærdig tegning du skal arbejde inden for.
De skjulte omkostninger ved "bare brug WordPress"
Ingen fortæller dig om disse ved projektstart. De dukker op 18 måneder senere.
Plugin-afhængighed er den mest undervurderede risiko i WordPress-projekter. Hvert plugin er en afhængighed du ikke kontrollerer - med sin egen opdateringscyklus, sin egen kvalitet og sin egen forretningsmodel. Et projekt med 30+ plugins er ikke et WordPress-projekt, det er 30 tredjepartsprojekter der tilfældigvis kører på samme installation. Når to plugins konflikter, eller en plugin-udvikler opgiver sit produkt, er det din klient der betaler prisen. Du kan læse mere om disse dynamikker i artiklen om almindelige misforståelser om PHP og WordPress plugins.
Performance-overhead er reel. En standard WordPress-installation loader kode til funktioner du ikke bruger, forespørger tabeller på måder der ikke er optimeret til din specifikke datamodel, og kæmper med caching-strategier der er lavet til generiske CMS-sites. Det kan løses - med Redis, objekt-caching, CDN og optimering - men du bruger ressourcer på at reparere et fundament i stedet for at bygge features. Core Web Vitals bliver ikke bedre af sig selv.
Teknisk gæld akkumulerer hurtigere i WordPress end i et framework, fordi der ikke er en naturlig arkitektur der tvinger dig til at placere kode rigtigt. Forretningslogik ender i templates. Database-queries ender i shortcodes. Hooks og filters skaber usynlige afhængigheder der er umulige at debugge. Et Laravel-projekt kan sagtens akkumulere teknisk gæld - men det kræver en aktiv beslutning om at ignorere arkitekturen. I WordPress sker det af sig selv.
Beslutningstræet
Stil dig selv disse spørgsmål, i denne rækkefølge:
Er indhold det primære? Hvis systemets kerneopgave er at publicere, redigere og vise indhold - og forretningslogikken er enkel - er WordPress sandsynligvis det rigtige valg.
Har ikke-tekniske brugere brug for at administrere systemet? WordPress admin er gennemtestet og velkendt. Hvis dit team skal opdatere indhold uden udviklere, er WordPress-editoren svær at slå.
Er der komplekse relationer mellem entiteter? Hvis du har brugere, produkter, ordrer, bookinger, kontrakter eller andre forretningsobjekter med ikke-trivielle relationer og tilstande - start med Laravel.
Har du brug for en API som primær interface? Hvis din frontend er decoupled, eller andre systemer skal integrere mod din backend, er Laravel et langt mere naturligt valg.
Forventer du at forretningslogikken vokser? Hvis du bygger noget der skal understøtte en voksende forretning med nye regler, nye workflows og nye integrationer - byg på et fundament der er designet til at vokse.
Svarer du "ja" på punkt 1 og 2, og "nej" på resten: WordPress. Svarer du "ja" på 3, 4 eller 5: Laravel. Svarer du "ja" på alle fem: du har et komplekst projekt der fortjener en ordentlig arkitektursnak - og der er ikke et simpelt svar.
Daniels tommelfingerregel efter 15+ år med begge
Jeg har bygget WordPress-sites der burde have været Laravel, og Laravel-applikationer der burde have været WordPress. Begge fejl er dyre - bare på forskellig måde.
WordPress der burde have været Laravel: du mærker det i vedligeholdelsesbyrden, i den tid du bruger på at bekæmpe frameworket, og i den dag du indser at den næste feature kræver at du omskriver halvdelen af hvad der allerede er bygget.
Laravel der burde have været WordPress: du mærker det i den tid det tager at bygge en simpel indholdsopdatering, i den afhængighed af en udvikler til ting der burde være selvbetjening, og i den unødvendige kompleksitet der gør projektet svært at overdrage.
Min tommelfingerregel er enkel: Hvis du ikke kan besvare spørgsmålet "hvad er din datamodel?" med andet end "vi har posts og pages" - så er WordPress sandsynligvis rigtigt. Kan du derimod tegne et diagram over dine forretningsentiteter og relationerne imellem dem, og det diagram er mere komplekst end det WordPress er designet til - så byg i Laravel fra dag ét.
Det er billigere at vælge rigtigt fra starten end at migrere et halvfærdigt WordPress-projekt til Laravel to år inde. Spørg mig ikke om jeg ved det af erfaring.
Har du et projekt der balancerer på grænsen, eller er du i tvivl om hvad der er det rigtige valg til netop din situation? Det er præcis den slags sparring du kan få under teknisk rådgivning - eller du kan læse mere om hvad Laravel-udvikling og WordPress-udvikling konkret indebærer hos Kodesmeden.
Platformen er ikke målet. Løsningen er. Vælg det fundament der giver dig den bedste løsning - ikke det der er nemmest at sælge.
