Ændringerne i PrestaShop 9

PrestaShop 9.0 udkom 10. juni 2025, og 9.1 fulgte 23. marts 2026. Det er 9.1 de fleste bør sigte efter i dag.

Forskellen på 8 og 9 er ikke en stribe nye funktioner i butikken, og kunderne vil ikke kunne se forskel. Forskellen er at hele fundamentet under administrationen er skiftet ud, og at en række gamle ting er fjernet i samme ombæring.

Det gør opgraderingen til et teknisk projekt snarere end et designprojekt, og det gør den også til den opgradering hvor det er modulerne og ikke kernen der bestemmer tidsplanen.

Her er hvad der er ændret, og hvad det betyder i praksis.

PrestaShop 8 kørte på Symfony 4.4, og PrestaShop 9 kører på Symfony 6.4, som er den nuværende LTS-udgave med support frem til november 2027.

Det er to hovedversioner på én gang, og derfra stammer langt de fleste ændringer.

Controllere skal nu defineres som services, den gamle FrameworkBundleAdminController er afløst af PrestaShopAdminController, og services hentes ikke længere med $this->get() men gennem constructor-injektion eller som parametre.

En række biblioteker er skiftet ud undervejs. Guzzle er erstattet af Symfonys HTTP-klient, Swift Mailer af Symfony Mailer, og Tactician af Symfony Messenger. Har et modul brugt et af dem uden selv at kræve det i sin composer.json, holder det op med at virke.

Den gamle Context-klasse er delt op i egentlige services: EmployeeContext, ShopContext, CurrencyContext, LanguageContext, CountryContext og ApiClientContext. Det er en klar forbedring, men det betyder at kode der greb fat i Context direkte, skal skrives om.

En detalje der har bidt flere: trans() escaper ikke længere automatisk, og parametre som htmlspecialchars er væk. Det skal nu håndteres dér hvor teksten bruges, og det er nemt at overse, samtidig med at det er en sikkerhedsfejl hvis man gør.

PrestaShop 9.0 kræver PHP 8.1 som minimum og understøtter 8.2, 8.3 og 8.4. Med 9.1 er understøttelsen udvidet til og med PHP 8.5, og Node 20 er minimum hvis I bygger assets.

For de fleste butikker er det nok den bedste del af opgraderingen. En shop der kører på PHP 7.4 eller 8.0, kører på en udgave uden sikkerhedsrettelser, og den er samtidig markant langsommere end en moderne PHP.

Vi ser typisk 20 til 40 procent lavere svartid alene ved at flytte fra 7.4 til 8.3 på ellers identisk kode, og det er et af de få steder hvor man får hastighed uden at ændre noget.

Tjek dog jeres hosting først. Ikke alle danske udbydere har PHP 8.3 og 8.4 klar på alle pakker, og det er en dum ting at opdage midt i en migrering.

Det her er den liste der afgør om opgraderingen bliver let eller svær for netop jer.

To af dem gør mest ondt i praksis. Advanced Stock Management ryger, så bruger I det til lagerstyring på tværs af lagre, skal det erstattes af et ERP eller et lagermodul. Og den gamle produktside i administrationen er væk, så moduler der hang på den, har ikke længere noget at hænge på. Omkring tyve hooks relateret til den gamle produktside og til login er fjernet med den.

Gennemgå listen mod jeres egen butik før I gør andet, for bruger I noget af det, er det dér projektet ligger.

Temaer slipper ikke fri.

Kategori-, leverandør-, producent- og butikssider bruger nu Presenter-klasser, og det giver to konkrete ændringer som knækker temaer: producentbilleder er gået fra at være en streng med en URL til at være et array med flere størrelser og formater, og nb_products returnerer nu et heltal i stedet for en formateret streng.

Det lyder småt, og det er også småt at rette. Men det står ikke i en fejlmeddelelse der peger på hvad der er galt, for det giver bare en tom side eller et tal der ser forkert ud.

Har I et standardtema med få tilpasninger, er det en dags arbejde. Har I et købt tema, afhænger det af om udvikleren har lavet en 9-udgave. Har I et specialbygget tema fra 2019 som tre forskellige bureauer har rørt ved, er det dér budgettet ryger.

Modulerne er den reelle opgave, og vi regner med at de udgør omkring 70 procent af arbejdet i en typisk migrering.

Tre ting rammer dem.

De fjernede afhængigheder: bruger modulet Guzzle eller Swift Mailer, skal det nu selv kræve dem i composer.json, eller skrives om.

Den nye controller- og service-arkitektur: alt der brugte $this->get() eller arvede fra den gamle admin-controller, skal skrives om.

Reglen om følsomme filer: moduler må ikke længere kaldes ved at pege direkte på en .php-fil, men skal gå gennem en ModuleFrontController. Det rammer især ældre betalings- og fragtmoduler der har et callback-endpoint liggende som en løs fil.

Lav modulgennemgangen først. Træk listen over installerede moduler, og find for hvert enkelt om der findes en 9-kompatibel udgave, hvad den koster, og hvad der sker hvis den ikke kommer. Den liste er hele projektplanen.

I 9.0 var Hummingbird et alternativ, og i 9.1 er Hummingbird 2.0 standardtemaet for nye installationer, mens Classic stadig er tilgængeligt hvis I vil blive.

Hummingbird er bygget på Bootstrap 5 og er markant lettere end Classic. Det mest interessante for danske butikker er dog et andet tal, nemlig at PrestaShop oplyser at temaet opfylder over 95 procent af kravene i tilgængelighedsdirektivet.

Det er efter min vurdering ikke et nice to have. Tilgængelighedskravene gælder for e-handel i EU, og de bliver ikke mindre med tiden, så et tema der starter i mål, sparer et projekt I ellers skal lave separat.

Vores anbefaling: skal I alligevel røre temaet i forbindelse med opgraderingen, så skift til Hummingbird frem for at rette i Classic. Er jeres nuværende tema specialbygget og velfungerende, er det ikke en grund til at kaste det væk, men så skal tilgængelighed på listen som sin egen opgave.

To ting i 9.1 er værd at kende, fordi de ændrer den daglige drift.

Rabatsystemet er skrevet om. Hvor alt før lå i cart rules, er der nu fire typer: katalog, kurv, fri fragt og gavefri. Det er både hurtigere og nemmere at forstå, men det betyder også at komplekse kampagneopsætninger skal gennemgås ved migreringen, så regn ikke med at de flytter med uændret.

Fragt har fået en eksperimentel funktion til flere fragtførere pr. ordre, hvor forsendelser kan deles og samles. Det løser et reelt problem for butikker med varer fra flere lagre eller leverandører. Bemærk ordet eksperimentel, for det er ikke noget vi sætter i produktion på en butik i højsæson uden at have testet det grundigt først.

Vores svar afhænger af hvor I står.

Kører I PrestaShop 1.7, bør I planlægge det nu. 1.7 er gammel, PHP-versionerne under den er uden sikkerhedsrettelser, og springet bliver ikke mindre af at vente. Her er 9.1 målet og ikke 8.

Kører I PrestaShop 8 med få moduler og et standardtema, er opgraderingen overskuelig, og så vil jeg foreslå første eller andet kvartal, og ikke fjerde.

Kører I PrestaShop 8 med tredive moduler og et specialbygget tema, er det et projekt. Begynd med modulgennemgangen og lad den fortælle hvornår det giver mening, for det kan udmærket være om et år når leverandørerne er klar.

Er I midt i højsæson, så nej, ikke noget af det. Symfony 6.4 har support til november 2027, og der er ingen grund til at røre en butik der tjener penge, i november.

Én ting haster dog uanset: kom væk fra PHP under 8.1. Det kan I gøre på PrestaShop 8, og det bør ikke vente på version 9.

Regn med tre poster, og kun den ene er selve opgraderingen.

Selve migreringen af kernen og data er den mindste. På en almindelig butik er det dage og ikke uger, hvis der ikke er specialtilpasninger i kernen, og er der det, hvilket der overraskende ofte er, skal de findes først.

Moduler er den største. Enten køber I nye udgaver, eller også skal de skrives om, så læg licenspriser og udviklingstimer sammen for hele listen før I sætter en pris på projektet.

Temaet er det tredje og svinger mest. Standardtema tager dage, købt tema med en 9-udgave tager dage plus licens, og specialbygget tema tager uger.

Og læg tid til test ind der svarer til en tredjedel af udviklingstiden. Betaling, fragt, moms, rabatter, feeds og alle integrationer skal køres igennem på et staging-miljø med rigtige data. Det er den post folk skærer i, og det er den der giver de dyre fejl.

Der er fire mønstre.

Det første er at opgradere kernen først og se på modulerne bagefter, og så står man med en butik der ikke kan tage imod penge, og ingen vej tilbage. Modulgennemgangen kommer først, altid.

Det andet er at teste på en tom database. Alt virker på en butik uden data, for fejlene ligger i de ordrer der blev oprettet i 2019, i de kunder med specialtegn i navnet, og i de kampagner nogen satte op og glemte.

Det tredje er at glemme trans() og escaping. Det er den ændring der oftest bliver overset, fordi intet går i stykker, men der bliver åbnet et hul.

Det fjerde er at lægge go-live om fredagen. Læg den mandag morgen når hele holdet er på arbejde, og når der er fire hverdage til at finde det der ikke blev testet.