Een migratie naar een hoofdversie speelt zich niet af in de kern van PrestaShop, die in de meeste gevallen correct bijwerkt. Ze speelt zich af in uw modules. Op een webshop met veertig modules volstaat het dat één enkele het bestelproces raakt en niet meer compatibel is om de migratie te blokkeren.
De moduleaudit moet dus aan al de rest voorafgaan, offerte inbegrepen.
Wat er daadwerkelijk verandert
PrestaShop 9 steunt op recentere versies van PHP en Symfony, wat drie families van breuken meebrengt.
De breuken door PHP. Striktere typering, gedeprecieerde dynamische eigenschappen, verwijderde functies. Een module die vijf jaar geleden is geschreven en nooit herwerkt, produceert fatale fouten, geen waarschuwingen.
De breuken door het framework. Modules die Symfony-controllers uitbreiden of services declareren moeten de nieuwe versie volgen. Dat geldt voor recente en goed gebouwde modules, paradoxaal genoeg meer blootgesteld dan puur legacy modules.
De breuken eigen aan PrestaShop. Verwijderde methodes uit de historische klassen, geschrapte of hernoemde hooks, wijzigingen in de templates van het standaardthema.
De inventaris, eerste deliverable
Maak vóór elke handeling een tabel met één regel per module en zes kolommen.
- Technische naam en geïnstalleerde versie.
- Leverancier, en zijn huidige bestaan. Een verdwenen leverancier is een veroordeelde module.
- Datum van de laatste beschikbare update. Boven achttien maanden zonder publicatie beschouwt u de module als verlaten tot bewijs van het tegendeel.
- Aangekondigde compatibiliteit met de doelversie, met onderscheid tussen wat op de productfiche staat en wat daadwerkelijk getest is.
- Kriticiteit: raakt de module aan de betaling, het bestelproces, de catalogus, of alleen aan een secundaire weergave?
- Aanwezigheid van overrides, zichtbaar in de overridemap. De beste indicator van fragiliteit.
Deze tabel is in een halve dag ingevuld en bepaalt heel de rest van het project.
De vier categorieën
Elke module valt in een ervan, en de behandeling verschilt.
Compatibel en onderhouden. U werkt bij en test. Het eenvoudigste geval, en zelden de meerderheid.
Compatibel aangekondigd maar niet geverifieerd. De vermelding op de productfiche geldt niet als test. Deze modules moeten prioritair worden getest, want een laat ontdekte incompatibiliteit kost een uitstel.
Verlaten. Twee uitwegen: een vervanger vinden, of de code laten overnemen. De overname heeft alleen zin als de functionaliteit specifiek is voor uw activiteit.
Vervangbaar door native functionaliteit. Systematisch onderschatte categorie. Elke hoofdversie integreert functies die voordien als module bestonden. Een migratie is het juiste moment om te deïnstalleren wat niet meer dient.
Op concrete audits haalt deze laatste schifting vaak vijf tot tien modules van de lijst, wat het project evenveel verlicht.
Dode Links Checker PrestaShop 8 & 9 - Gebroken Links & Ontbrekende AfbeeldingenVind dode links en gebroken afbeeldingen voor uw klanten dat doen€59,00
De meest voorkomende technische valkuilen
Voor ontwikkelaars en agencies komen vier breuken voortdurend terug op de te herwerken modules.
De vertaalmethode die rechtstreeks op de controllers beschikbaar was, is verdwenen: het moet via de module-instantie. Overrides van methodes waarvan de signatuur is veranderd, produceren compatibiliteitsfouten, met name op de rendermethodes voor asynchrone antwoorden. De asynchrone aanroepen naar de historische beheercontrollers zijn van vorm veranderd en vereisen dat de parameters anders worden doorgegeven. En modules die rechtstreeks in kerntabellen schreven, botsen op de schemawijzigingen.
Geen van deze correcties is op zich complex. De kostprijs komt van het aantal.
De testomgeving
Niet onderhandelbaar, en toch regelmatig overgeslagen.
Ze moet steunen op een recente kopie van de productiedatabase, niet op een demodataset. De meeste incompatibiliteiten verschijnen op concrete data: producten met honderd varianten, klanten met onvolledige adressen, bestellingen in vergeten statussen.
Twee voorzorgen: anonimiseer de klantgegevens voor het kopiëren, en schakel elke e-mailverzending vanuit deze omgeving uit. Een migratietest die tweeduizend statuswijzigingsmails naar echte klanten stuurt, is een waargebeurd en frequent verhaal.
Het testplan
Test trajecten, geen pagina’s. Zes trajecten dekken het essentiële.
Een volledige bestelling als niet-ingelogde bezoeker, met echte betaling in testomgeving. Een bestelling met een bestaand account en een opgeslagen adres. Een toevoeging aan de winkelwagen vanaf een categoriepagina met actieve filters. Een interne zoekopdracht gevolgd door een aankoop. Een retour of een after-salesaanvraag. En aan beheerzijde de aanmaak van een product met varianten en de validatie van een bestelling.
Elk traject moet op desktop en op mobiel worden gespeeld. Reken een dag voor het geheel, opnieuw te doen na elke significante correctie.
De overstap en erna
Plan de migratie buiten de commerciële periodes, met een gedefinieerd en getest rollbackvenster. Een back-up die nooit is teruggezet, telt niet.
De dagen erna dringen drie controles zich op. De foutlogboeken van de server, die de incompatibiliteiten onthullen die de test niet is tegengekomen. De kapotte links en afbeeldingen, want een versiewissel kan de afbeeldingspaden en de herschreven URL’s raken. En de opvolging van de bestellingen, te vergelijken met het gebruikelijke niveau: een plotse daling wijst op een blokkade in het bestelproces die niemand heeft gemeld.
Op dat laatste punt is de Dode Links Checker voor PrestaShop nuttig in de testfase en na de overstap: hij detecteert de kapotte interne links en de ontbrekende afbeeldingen die de migratie kan hebben veroorzaakt, op PrestaShop 8 en op PrestaShop 9.