Sådan migrerer I til PrestaShop 9

Vi har lavet nok af dem til at vide at det ikke er svært at opgradere PrestaShop. Det svære er 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, og ikke i uge seks hvor pengene er brugt.

Planen her er den vi kører efter, og den forudsætter at I er på PrestaShop 8. Kommer I fra 1.7, gælder de samme trin, men så kommer der 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, og ikke dem I tror I bruger, men 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. De kritiske er betaling, fragt, moms, ERP-integration og feed, for uden dem er der ingen butik. De vigtige er dem der påvirker omsætning, men som man kan undvære en uge. Så er der nice to have. Og til sidst 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, og 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, men den beslutning skal tages i uge ét.

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

De er der overraskende ofte, fordi en udvikler har haft travlt i 2020 og rettet en klasse direkte i stedet for at lave et override. Det virker, lige 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 eller tilpasningsantal? Hvis ja, er det ikke en migrering men en ombygning af den arbejdsgang, og den skal planlægges for sig.

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

Der er tre veje. Er I på Classic med få tilpasninger, kan I blive på Classic i version 9 og rette de steder hvor Presenter-ændringerne rammer, altså producentbilleder der nu er et array, og nb_products der nu er 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 at hvis temaet er æ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, så 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 og ikke en ny installation: rigtige produkter, rigtige ordrer, rigtige kunder og rigtige kampagner. Anonymiser persondata hvis miljøet ikke er lukket.

Grunden er enkel. Alt virker på en tom butik, for 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, og kampagner med regler der modsiger hinanden.

Staging skal også køre samme PHP-version som produktionen skal ende på, så tjek det med hostingudbyderen inden I begynder, for 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, så 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, og ret temaet de steder hvor 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, for 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, og 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, og rabatter oven på rabatter.

Kampagner: alle aktive rabatter skal gennem kurven, for 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 og mailplatform. Tjek at felterne kommer ud som før, og ikke bare at feedet bliver genereret.

Ordreflowet bagud: ordrebekræftelse, faktura, kreditnota, returnering og 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, er 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, og aldrig dagen før en kampagne.

Hav en tilbagerulning klar som er afprøvet, og som I ved hvor lang tid tager, for "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, for 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, men betaling, fragt, en rigtig ordre og de tre vigtigste integrationer.

De fleste fejl dukker ikke op på dag ét, men 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, for falder den ét bestemt sted, ved I præcis hvor I skal kigge.

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

Og 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.

Spørg i øvrigt kundeservice hver dag i en uge om hvad folk skriver om, for de ved det før dashboardet.

Der er 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, og som regel er det 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.

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