Migrering til PrestaShop 9: rækkefølgen, der afgør om det går galt

Vi har lavet nok af de her til at vide, at det ikke er svært at opgradere PrestaShop. Det er svært at opdage for sent, at et betalingsmodul ikke findes i en 9-udgave.

Derfor handler hele metoden om rækkefølge. Alt, der kan vælte projektet, skal findes i uge ét — ikke i uge seks, hvor pengene er brugt.

Planen her er den, vi kører efter. Den forudsætter, at I er på PrestaShop 8. Kommer I fra 1.7, gælder de samme trin, men der kommer et ekstra lag på, fordi springet over 8 indeholder sine egne ændringer.

Alt begynder her, og der er en grund til, at det ikke er "installer version 9 på et testmiljø".

Træk listen over installerede moduler. Ikke dem, I tror I bruger — listen fra administrationen, inklusive dem, der er slået fra.

For hvert modul skal tre spørgsmål besvares. Findes der en udgave, der understøtter PrestaShop 9? Hvad koster den? Og hvad sker der i butikken, hvis modulet ikke kommer?

Sorter dem så i fire bunker. Kritiske: betaling, fragt, moms, ERP-integration, feed. Uden dem er der ingen butik. Vigtige: dem der påvirker omsætning, men som man kan undvære en uge. Nice to have. Og dem, ingen har brugt i to år.

Den sidste bunke er større, end nogen tror. Vi finder typisk mellem otte og femten moduler, der kan afinstalleres uden at nogen opdager det. Hvert af dem er et modul, der ikke skal migreres, betales for eller testes.

Er der et kritisk modul uden en 9-udgave, stopper projektet her, indtil det er løst. Enten venter I på leverandøren, eller I finder et alternativ, eller I får det skrevet om. Den beslutning skal tages i uge ét.

Det næste, vi leder efter, er ændringer i kernen. Ikke moduler — rettelser i selve PrestaShop-filerne.

De er der overraskende ofte. En udvikler har haft travlt i 2020 og rettet en klasse direkte i stedet for at lave et override. Det virker, indtil man opgraderer.

Sammenlign filerne med en ren installation af samme version. Alt, der afviger, skal forstås: hvad gør ændringen, hvorfor er den der, og skal den med videre.

Samme øvelse for mappen med overrides. De er lovlige, men de er bundet til den kode, de overskriver, og den kode har ændret sig markant i version 9.

Det er også her, den fjernede funktionalitet skal holdes op mod butikken. Bruger I Advanced Stock Management? Levering til flere adresser? Tilpasningsantal? Hvis ja, er det ikke en migrering, det er en ombygning af den arbejdsgang, og den skal planlægges for sig.

Nu, og ikke før, tager I stilling til temaet.

Tre veje. Er I på Classic med få tilpasninger, kan I blive på Classic i version 9 og rette de steder, Presenter-ændringerne rammer: producentbilleder er nu et array, og nb_products er nu et heltal.

Er I på et købt tema, skal I finde ud af, om udvikleren har en 9-udgave, og hvad opgraderingen af temaet koster. Findes den ikke, og har temaet ikke fået en opdatering i halvandet år, så regn med, at den ikke kommer.

Er I på et specialbygget tema, er spørgsmålet, om I retter det eller bygger på Hummingbird. Vores tommelfingerregel: er temaet ældre end tre år og har været igennem mere end ét bureau, er Hummingbird billigere, også selv om det lyder dyrere.

Hummingbird har i øvrigt det argument, at PrestaShop opgiver, at det dækker over 95 procent af kravene i tilgængelighedsdirektivet. Skal I alligevel løse tilgængelighed, er det en post, der forsvinder af sig selv.

Først nu rører vi teknikken.

Staging skal være en kopi af produktionen, ikke en ny installation. Rigtige produkter, rigtige ordrer, rigtige kunder, rigtige kampagner. Anonymiser persondata, hvis miljøet ikke er lukket.

Grunden er enkel: alt virker på en tom butik. Fejlene ligger i de gamle data. Kunder med bindestreger og specialtegn. Ordrer fra en betalingsmetode, I ikke bruger mere. Produkter med kombinationer, ingen har rørt siden 2018. Kampagner med regler, der modsiger hinanden.

Staging skal også køre samme PHP-version, som produktionen skal ende på. Tjek det med hostingudbyderen, inden I begynder. Ikke alle pakker har PHP 8.3 og 8.4 klar.

Og lav en sikkerhedskopi, I rent faktisk har prøvet at gendanne fra. En backup, ingen har testet, er en formodning.

Selve migreringen er den korteste del, når de fire første trin er lavet.

Brug Update Assistant, og kør den på staging. Vær opmærksom på, at man ikke kan opgradere fra en beta- eller RC-udgave til den endelige version med den — er I havnet på en prerelease, skal det løses anderledes.

Installer modulerne i deres 9-udgaver. Genopbyg de overrides, der skal med, mod den nye kode. Ret temaet de steder, Presenter-ændringerne rammer.

Gå kodebasen igennem for de ting, der ikke fejler støjende: trans(), der ikke længere escaper, kald til $this->get() i controllere, brug af den gamle Context, og moduler, der peger direkte på en .php-fil i stedet for at gå gennem en ModuleFrontController.

Den sidste er værd at være grundig med. Den rammer typisk callback-endpoints i ældre betalingsmoduler, og den fejler ikke, før en rigtig betaling skal bekræftes.

Her er listen, vi kører igennem, og den er ikke til forhandling.

Betaling: hver aktiv metode, hele vejen til bekræftet ordre. Også den, der kun bruges af fem procent. Også 3D Secure-flowet. Også en afvist betaling.

Fragt: hver fragtmetode, hver zone, hver vægtgrænse. Og pakkeshop-valg, hvis I har det.

Moms og priser: B2B uden moms, B2C med, EU-kunder, tredjelande. Rabatter oven på rabatter.

Kampagner: alle aktive rabatter skal gennem kurven. Rabatsystemet er skrevet om i 9.1, og komplekse opsætninger flytter ikke altid uændret med.

Feeds og integrationer: Google Merchant Center, Meta-katalog, ERP, lager, mailplatform. Tjek at felterne kommer ud som før — ikke bare at feedet bliver genereret.

Ordreflowet bagud: ordrebekræftelse, faktura, kreditnota, returnering, mails til kunden.

Og til sidst: bestil en rigtig ordre med et rigtigt kort, og send den. Ikke i testtilstand.

Ved en almindelig opgradering skifter URL'erne ikke. Men de kan gøre det, og så skal det fanges før go-live.

Træk en liste over alle URL'er fra jeres sitemap og fra Search Console, og kør den mod staging. Alt, der ikke svarer 200, skal enten rettes eller have en 301.

De steder, vi oftest ser noget skride: kategorisider med ændret struktur, producentsider, filter- og facetsider, og billed-URL'er, hvis I ændrer på billedindstillingerne undervejs.

Tjek også de strukturerede data. Går der noget tabt i temaændringen, forsvinder jeres rich results i Google, og det opdager man typisk tre uger senere som et fald i klik, ingen kan forklare.

Har I skiftet tema, så sammenlign også de vigtigste sider på Core Web Vitals før og efter. Hummingbird er lettere end Classic, men et tema, der er bygget om i hast, kan sagtens være langsommere.

Læg den mandag eller tirsdag morgen. Aldrig fredag, aldrig i november, aldrig dagen før en kampagne.

Hav en tilbagerulning klar, som er afprøvet, og som I ved hvor lang tid tager. "Vi ruller tilbage fra backup" er ikke en plan, hvis ingen har målt, hvor længe det varer.

Sæt butikken i vedligeholdelse i det vindue, hvor der flyttes data, og hold det kort.

Hav hele holdet på arbejde, også kundeservice. De opdager fejlene først, fordi kunderne skriver om dem, før nogen ser dem i et dashboard.

Og kør den samme testliste igennem i produktion, efter at alt er oppe. Ikke hele listen — betaling, fragt, en rigtig ordre og de tre vigtigste integrationer.

De fleste fejl dukker ikke op på dag ét. De dukker op på dag tre, når en kunde gør noget, ingen havde tænkt på.

Hold øje med tre ting dagligt den første uge.

Konverteringsraten pr. trin i tragten. Falder den ét bestemt sted, ved I præcis hvor I skal kigge.

Fejlloggen, både PHP og butikkens egen. Nye fejl efter en migrering er ikke støj.

Ordrer, der sætter sig fast i en betalingsstatus. Det er det tydeligste tegn på et callback, der ikke kommer igennem, og det er den fejl, der koster mest, fordi ordren ser ud til at være gået godt for kunden.

Og spørg kundeservice hver dag i en uge, hvad folk skriver om. De ved det før dashboardet.

Fem ting, vi finder næsten hver gang.

Moduler, ingen bruger. Typisk otte til femten. Fjern dem, før I betaler for at migrere dem.

Rettelser direkte i kernen, som ingen kan huske hvorfor er der. Som regel en løsning på et problem, der forsvandt for fire år siden.

Et betalings- eller fragtmodul, hvor leverandøren ikke har lavet en 9-udgave. Det er den, der afgør tidsplanen, og den skal findes i uge ét.

Kampagner, der modsiger hinanden, og som kun virkede, fordi den gamle rabatmotor gjorde tingene i en bestemt rækkefølge.

En PHP-version, hostingudbyderen ikke har klar på jeres pakke. Ring til dem, før I planlægger noget som helst.