Wat onderhoud van een Magento-shop inhoudt
Magento 2 is software die je moet blijven bijwerken. Het draait je kassa, je productcatalogus en vaak honderden uitbreidingen (modules) van verschillende makers. Elk onderdeel krijgt eigen updates, en die moeten met elkaar blijven samenwerken.
- Beveiligingspatches: kleine updates van Magento die bekende lekken dichten. Zonder die updates staat je shop open voor aanvallen die al openbaar beschreven zijn.
- Upgrades: de stap naar een nieuwere versie van Magento of van PHP, de taal waarin Magento draait.
- Bewaking: laadtijden, foutmeldingen en geplande taken in de gaten houden, zodat je het hoort voordat een klant het meldt.
- Back-ups: een kopie van je shop die je ook echt kunt terugzetten.
- Aanvallen afslaan: scrapers en bots die je shop zwaar belasten of proberen binnen te komen.
- Uitrollen: wijzigingen live zetten zonder dat de shop even stilvalt.
Ik doe dit werk zelf, op een Magento 2.4.7-shop met 328 actieve modules. Wat ik hier schrijf komt uit dat werk, niet uit een folder.
Beveiligingspatches en upgrades
Een patch kan botsen met een module die dezelfde onderdelen van Magento aanpast. Dan werkt de checkout niet meer of ontbreekt er iets in het beheerscherm. Daarom installeer je patches niet blind.
- Ik lees eerst welke onderdelen de patch raakt en welke modules daar ook aan zitten.
- Ik pas de patch toe op een testomgeving en loop de belangrijkste paden na: zoeken, winkelwagen, afrekenen en het beheerscherm.
- Conflicten tussen modules los ik op in de code, zodat de update erdoorheen kan.
- Pas daarna gaat dezelfde wijziging naar productie.
Zo heb ik patch-upgrades op een productieshop doorgevoerd, van de ene patchversie naar de volgende, inclusief het oplossen van conflicten tussen modules. Een grotere versiesprong werkt op dezelfde manier, met meer testwerk. Daarover staat meer op de pagina over Magento 2-upgrades.
Uitrollen zonder dat je shop plat gaat
Magento bouwt na een wijziging veel opnieuw op, en een verkeerde handeling op het verkeerde moment legt de shop stil. Op een shop met verkeer loopt er dan omzet weg.
Daarom ververs ik de cache (het tijdelijke geheugen dat pagina's snel maakt) op productie gericht en nooit helemaal in één keer. Een volledige flush zet alle pagina's tegelijk terug naar koud. De server moet ze dan allemaal opnieuw opbouwen terwijl er bezoekers op zitten.
Ik zet een wijziging eerst klaar op een testomgeving, controleer hem en zet hem daarna live in een volgorde waarbij de shop blijft draaien. Ik weet vooraf welke stap ik terugdraai als iets tegenvalt.
Bewaking en back-ups
Ik houd drie dingen in de gaten: laadtijden, foutmeldingen en geplande taken (cron-jobs, de taken die Magento zelf op vaste momenten draait, zoals indexeren en mails versturen). Wijkt een van de drie af, dan krijg ik een melding.
- Laadtijden: een shop die langzamer wordt, laat vaak eerder dan een foutmelding zien dat er iets misgaat.
- Foutmeldingen: een fout in het logboek die zich blijft herhalen is meestal een module die niet goed werkt.
- Geplande taken: als die stilvallen, lopen voorraad, zoekindex en mails achter zonder dat iemand het ziet.
Een beheerscherm dat fouten gaf, bleek door een verlopen licentie van een externe module te komen. Ik heb dat opgespoord en hersteld. Zoiets vind je alleen als je de foutmelding tot in de code volgt.
Een back-up is pas iets waard als je hem kunt terugzetten. Ik controleer dat ze draaien en dat je shop eruit terug te halen is.
Aanvallen afslaan
Een shop krijgt ook verkeer dat geen klant is. Sommige bots lezen je hele catalogus leeg, andere zoeken naar een lek.
De zoekfunctie is een bekend doelwit, omdat elke zoekopdracht de server werk geeft en vaak niet uit de cache komt. Ik schermde die functie af en filterde het verkeer, zodat echte bezoekers gewoon konden blijven zoeken en bestellen.
Een latere poging om via een lek code op de server uit te voeren heb ik tegengehouden en daarna onderzocht, zodat ik wist hoe de poging in elkaar zat.
Uit de praktijk
Een Magento 2.4.7-shop met 3.400 producten, dagelijks in beheer
Ik werk dagelijks aan een Magento 2-productieshop (versie 2.4.7) met ruim 3.400 producten, ongeveer 13.600 productpagina's over vier taalversies en 328 actieve modules. Patch-upgrades, bewaking, aanvallen afslaan en uitrollen horen daar allemaal bij.
Een scraper stuurde 2,3 miljoen zoekopdrachten vanaf 600.000 IP-adressen naar de zoekfunctie. De shop bleef overeind doordat ik de zoekfunctie afschermde en het verkeer filterde.
Dezelfde shop haalt op mobiel een LCP (de tijd tot het grootste element in beeld staat) van 2,14 seconden bij echte bezoekers, tegen 14 tot 16 seconden eerder. Alle Core Web Vitals staan op groen. Ook eigen modules horen bij het beheer: beveiligingsheaders (regels die de browser vertellen welke scripts mogen draaien, CSP met SRI-hashes), een canonical-fix voor CMS-pagina's (die zoekmachines vertelt welke versie van een pagina telt), uitgesteld laden van scripts van derden en een magazijnmodule in ontwikkeling.
Zo werk ik, en met wie je praat
Ik lees eerst hoe de bestaande code in elkaar zit. Daarna wijzig ik op een testomgeving, en pas dan op productie. Zo blijft een shop heel.
Je hebt één aanspreekpunt: de persoon die de code schrijft. Je praat dus met degene die de wijziging ook maakt. Wat onderhoud kost, hangt af van je shop. Dat bespreken we na een kennismaking.