Syv år som fast teknisk partner for Body SDS

Jeg lærer siden at kende først

Når mange har bygget på den samme side, kan en lille rettelse ét sted give en fejl et helt andet sted. Så før jeg retter noget, finder jeg ud af, hvad hvert plugin gør, hvem der har skrevet koden, og hvad Body SDS faktisk bruger.

Eksempel Inden jeg overtog siden i 2019, lavede jeg på eget initiativ en analyse af den. Ca. 1.300 af 1.900 sider havde fejl. Bagefter gik jeg pluginsene igennem og fandt ca. 11, der kunne fjernes, og 45 døde sider, der skulle omdirigeres. Først derefter begyndte jeg at rette.

Det samme skal kun rettes ét sted

Skal en medarbejder huske at rette en dato to steder, bliver det ene glemt før eller siden. Det ville jeg selv også glemme. Derfor ligger oplysningerne ét sted, og resten af siden henter dem derfra.

Eksempel Kurser og events er produkter i webshoppen, og siden om intromøder og holdstarter henter datoerne derfra. De engelske sider linker til de danske skemaer og priser. I det nye design fra 2024 er sidemenuen og kontaktboksen en fast del af skabelonen, så ingen skal huske at sætte dem ind på hver side.

Jeg bygger til dem, der bruger siden

Der er to slags brugere: dem, der besøger siden, og medarbejderne, der arbejder i den hver dag. Begge skal have det let. Hvordan folk bruger siden, ser jeg i tallene i stedet for at gætte.

Eksempel I marts 2024 kunne vi se i Body SDS’ egne tal, at ca. 66 % af de besøgende kom på mobil, mens ca. 70 % af salget skete på computer. Den gamle side var lavet til computer. Den nye blev bygget til mobil først, men det skulle stadig være let at købe på computer. Medarbejderne havde også svært ved at oprette sider. Én side fyldte 526 rækker i databasen, hvor ca. 25 havde været nok.

Jeg retter selv fejl i plugins

Finder jeg en fejl i et købt plugin, retter jeg den selv med det samme og sender rettelsen til den, der har lavet pluginet. Der kan gå uger, før en opdatering kommer, og imens mister kunden tilmeldinger eller salg.

Eksempel I marts 2024 kom tilmeldingerne til nyhedsbrevet ikke igennem, og bureauet bag nyhedsbrevene kunne ikke finde årsagen. Den lå i formular-pluginet, som satte +1 foran danske telefonnumre i stedet for +45. Jeg rettede pluginet, så tilmeldingerne virkede igen, og sendte rettelsen til udvikleren.

Jeg vælger det mindste, der kan løse opgaven

Et stort plugin, man kun bruger lidt af, skal alligevel holdes opdateret, og det gør siden langsommere. Jeg spørger derfor, hvad der egentlig er brug for. Nogle gange er svaret, at jeg bygger det selv.

Eksempel LearnDash blev næsten kun brugt til eksamen, men skulle hele tiden vedligeholdes og gjorde siden tungere. Så jeg byggede et eksamenssystem, der kun kan det, Body SDS bruger, og flyttede de gamle eksamener over. I 2025 frarådede jeg et ekstra blok-plugin, fordi siden allerede havde to, der kunne det samme.

Jeg tjekker, hvad en ændring rammer

En lille ændring kan ramme noget, man ikke lige tænker på: placeringen i Google, gamle links, kassen i webshoppen eller en automatisk mail. Det tjekker jeg, før jeg ændrer noget.

Eksempel Da «præsentationsaften» og «infomøde» skulle hedde «intromøde» overalt, ville en automatisk søg-og-erstat i databasen have været det hurtigste. Jeg frarådede det og rettede det i hånden, og den gamle side blev omdirigeret, så links og placeringer i Google ikke gik tabt. Da gavekort fik en gyldighed på tre år, sagde jeg til, at kort købt online og kort indløst i klinikken lå i to systemer, der ikke talte sammen.

Jeg siger til, før det bliver et problem

Jeg holder øje med siden og siger til, når noget bør gøres, også når ingen har spurgt. Helst skal Body SDS slet ikke opdage, at der var et problem.

Eksempel Overvågningen sender alarmer til mig, ikke til Body SDS. Jeg har foreslået rolleprofiler i stedet for mange administratorer, PHP-opgraderinger og oprydning i gamle kladder. Kommer der en kritisk sikkerhedsopdatering, lægger jeg den på med det samme og fortæller det bagefter.