At arve en WordPress-installation

Opgaven lyder sjældent som et projekt. Den lyder som: “vores site er blevet langsomt”, eller “vi kan ikke opdatere, uden at noget går i stykker”. Bagved ligger en WordPress-installation, der har kørt i otte år, og som ingen har haft det fulde overblik over siden den udvikler, der byggede den, holdt op.

Det er en af de mere almindelige opgaver i WordPress-verdenen. Den bliver bare sjældent beskrevet, fordi den ikke er et nyt site med et før-og-efter-billede.

Det første skridt er ikke at rette noget

Fristelsen er at gå i gang: deaktivere plugins, opdatere kernen, rydde op i temaet. Det er også den hurtigste vej til at slukke for noget, der viste sig at være vigtigt.

Første skridt er at finde ud af, hvad der faktisk bliver brugt. Hvilke plugins gør noget, siden faktisk viser. Hvilke sidetyper findes der, og hvem redigerer dem. Hvad sker der ved en bestilling, en tilmelding, en formular – hele vejen fra klik til mail eller database. Det tager typisk en dag eller to, og det er den bedst brugte tid i hele opgaven.

Reglen, jeg arbejder efter, er enkel: rør ikke noget, før du ved, hvorfor det er der. Kode, der ser overflødig ud, er ofte nogens løsning på et problem, der ikke er dokumenteret nogen steder.

Hvad man typisk finder

Der er nogle mønstre, der går igen.

Plugins, der overlapper. To cache-plugins installeret af hver sin udvikler. En galleriløsning, der bruges på én side, som ingen har besøgt i to år.

Plugins, der udsender konkurrerende metadata. Den værste variant af overlappet, fordi den ikke gør noget synligt. To SEO-plugins skriver hver sin title, sin canonical og sine Open Graph-tags i samme sidehoved, og temaet lægger måske et tredje sæt oven i. Siden ser rigtig ud i browseren – men Google får modstridende signaler om, hvad siden hedder, og hvilken URL der er den rigtige. Det er ikke et plugin, der er i stykker. Det er to, der begge virker.

Ændringer i temaet frem for i et child theme. Det betyder, at temaet ikke kan opdateres, uden at ændringerne forsvinder – og derfor er det ikke blevet opdateret. Derfra breder det sig: når temaet står stille, tør man heller ikke opdatere WordPress eller PHP, og til sidst er hele installationen låst fast af noget, ingen kan huske.

Sporing, der kører uden om samtykket. Google Tag Manager installeret gennem et plugin, mens samtykket håndteres af et andet. Hver for sig virker de: banneret vises og gemmer valget, og GTM indlæser sine tags. De ved bare ikke nødvendigvis af hinanden, så brugerens valg i banneret bliver ikke omsat til den adfærd, man tror. Det er den slags, der ikke opdages ved almindelig brug af sitet, men først når man ser på, hvad browseren faktisk sender.

Kode, ingen tør røre. En functions.php på 1.000 linjer, hvor det meste er tilføjet af forskellige mennesker over flere år. Ingen kommentarer, ingen historik, fordi det aldrig har ligget i Git.

Hvad jeg gør ved det

Rækkefølgen betyder mere end værktøjerne.

1. En kopi og versionsstyring. Installationen skal ligge et sted, hvor man kan prøve noget af uden at ramme det, kunden bruger. Og koden skal i Git – ikke for at være moderne, men fordi det er forskellen på “vi ændrede noget, og nu virker det ikke” og “vi kan se præcis, hvad der skete”.
2. Det, der gør ondt nu. Er sitet langsomt, måler jeg hvorfor, før jeg optimerer. Er der en sikkerhedsopdatering, der er blevet udskudt i to år, er den vigtigere end oprydning. Kunden skal mærke en forskel, før man går i gang med det, der ikke kan ses.
3. Én ting ad gangen. Ét plugin fjernet, sitet testet, videre. Det tager længere tid end at rydde op i én omgang, men når noget går i stykker, ved man, hvad det var.
4. Det, der gør næste gang lettere. Et child theme, så temaet kan opdateres. Ændringer flyttet fra functions.php til et sted, de kan læses. En kort note om, hvad der er hvor.

Hvornår det ikke kan betale sig

Nogle gange er svaret at bygge nyt. Det er det, når temaet er så gennemhullet, at oprydningen bliver dyrere end en ny frontend, eller når indholdsstrukturen ikke passer til det, sitet skal kunne i dag.

Men det er sjældnere, end man tror – og det er værd at være opmærksom på, at den, der skal bygge det nye, sjældent er den mest objektive til at vurdere det. Et site med otte års indhold, indeksering og indgående links har en værdi, der ikke står i kodebasen.

Det, det egentlig handler om

En arvet installation er sjældent kun et teknisk problem. Det er også et spørgsmål om, at nogen skal kunne svare på, hvad der sker, og hvorfor.

Det er dét, arbejdet går ud på: at gøre et system, ingen forstår, til et system, nogen kan drive. Koden bliver bedre undervejs, men det er ikke pointen. Pointen er, at næste gang der skal ændres noget, er det en opgave og ikke en risiko.