PrestaShop 9: hvad der faktisk er ændret, og om I skal opgradere nu

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

Forskellen på 8 og 9 er ikke en stribe nye funktioner i butikken. 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. 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. 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 det er derfra, langt de fleste ændringer stammer.

Controllere skal nu defineres som services. Den gamle FrameworkBundleAdminController er afløst af PrestaShopAdminController. 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. Parametre som htmlspecialchars er væk. Det skal nu håndteres, hvor teksten bruges. Det er nemt at overse, og 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. Node 20 er minimum, hvis I bygger assets.

For de fleste butikker er det 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. 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 er let eller svær for netop jer.

Advanced Stock Management er fjernet. Brugte I det til lagerstyring på tværs af lagre, skal det erstattes — typisk af et ERP eller et lagermodul.

Levering til flere adresser på samme ordre er fjernet. 9.1 har til gengæld fået en eksperimentel funktion til at dele og samle forsendelser i én ordre, som dækker en del af behovet på en anden måde.

Tilpasningsantal på produkter er væk og bruger nu almindelig kurvmængde.

High DPI-billeder som særskilt funktion er fjernet. Det samme er kategorimenuens thumbnails og det gamle fanesystem.

Den gamle produktside i administrationen er væk. Den nye har været der siden 8.x, men moduler, der hang på den gamle, har ikke længere noget at hænge på. Omkring tyve hooks relateret til den gamle produktside og til login er fjernet.

Gennemgå listen mod jeres egen butik, før I gør andet. 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. Det betyder 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. Det er også småt at rette. Men det står ikke i en fejlmeddelelse, der peger på hvad der er galt — det giver 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. Vi regner med, at det er 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. Det 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: findes der en 9-kompatibel udgave, hvad koster den, og hvad sker der, hvis den ikke kommer. Den liste er hele projektplanen.

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

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

Det er ikke et nice to have. Tilgængelighedskravene gælder for e-handel i EU, og de bliver ikke mindre med tiden. 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 daglig 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. 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: 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, skal 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, ikke 8.

Kører I PrestaShop 8 med få moduler og et standardtema, er opgraderingen overskuelig. Tag den i første eller andet kvartal — ikke i 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. Det kan udmærket være om et år, når leverandørerne er klar.

Er I midt i højsæson: 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.

En ting, der derimod haster uanset: kom væk fra PHP under 8.1. Det kan I gøre på PrestaShop 8 og 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, ikke uger, hvis der ikke er specialtilpasninger i kernen. Er der det — og det er der overraskende ofte — skal de findes først.

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

Temaet er det tredje, og det svinger mest. Standardtema: dage. Købt tema med en 9-udgave: dage plus licens. Specialbygget tema: 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.

Fire mønstre.

Det første er at opgradere kernen først og se på modulerne bagefter. 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. 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 — der bliver bare å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.