Audit van Magento 2-modules: hoe controleert u welke extensies de webshop helpen en welke hem vertragen?

Magento 2 biedt veel vrijheid om een webshop uit te breiden, maar na verloop van tijd kan die flexibiliteit een probleem worden. Elke module voegt nieuwe functies toe, maar kan ook invloed hebben op prestaties, beveiliging, het updateproces en onderhoudskosten. Daarom zou een regelmatige audit van extensies een van de basisonderdelen van het beheer van een Magento-webshop moeten zijn.

In dit artikel laten we zien wanneer het zinvol is om een audit van Magento 2-modules uit te voeren, wat u precies moet controleren en hoe u beslist welke extensies u behoudt, bijwerkt, vervangt of verwijdert.

Belangrijkste conclusie: Magento 2-modules zijn alleen waardevol wanneer ze nodig, actueel en in lijn met de architectuur van de webshop zijn. Een extensie die niemand gebruikt of die niemand bijwerkt, wordt technische schuld.

Waarom is een audit van modules in Magento 2 belangrijk?

In veel Magento 2-webshops groeit de lijst met geïnstalleerde extensies geleidelijk. Eerst komt er een module voor reviews bij, daarna een integratie met een vervoerder, extra velden in de checkout, een SEO-tool, een productfeed, een nieuwsbrief, promotieautomatisering, B2B-functies, integraties met marketplaces en daarna nog meer oplossingen die snel worden geïmplementeerd.

Het probleem ontstaat na enkele jaren. Sommige modules blijven cruciaal voor de verkoop, maar andere:

• worden niet meer gebruikt,
• dupliceren functies van andere extensies,
• zijn niet compatibel met de huidige Magento-versie,
• vertragen het adminpaneel of de frontend,
• maken updates moeilijker,
• genereren fouten in logs,
• verhogen de onderhoudskosten van de webshop.

Een audit helpt modules die echt nodig zijn te scheiden van modules die alleen nog in het systeem staan omdat niemand ze eerder heeft beoordeeld.

Wanneer is een audit van Magento-extensies zinvol?

Een module-audit is vooral waardevol vóór grotere technische of zakelijke wijzigingen. De meest voorkomende momenten zijn:

• een update van Magento naar een nieuwere versie,
• migratie naar nieuwe hosting,
• implementatie van een Hyva-template of herbouw van de frontend,
• dalende prestaties van de webshop,
• problemen met de checkout,
• stijgende onderhoudskosten,
• overname van de webshop na een ander bureau,
• uitbreiding van de webshop met B2B, marketplace of internationale verkoop,
• voorbereiding van de webshop op het verkoopseizoen.

Een goed waarschuwingssignaal is ook een situatie waarin het technische team bang is voor updates omdat het niet duidelijk is wat er kapot kan gaan. Dat betekent meestal dat de afhankelijkheden in de webshop moeten worden opgeschoond.

Wat moet u controleren tijdens een audit van Magento 2-modules?

Een audit mag zich niet beperken tot alleen de lijst met modules uit de opdracht bin/magento module:status. Alleen de aanwezigheid van een module zegt nog niet of deze nodig, correct gebruikt en veilig is.

In de praktijk is het verstandig meerdere gebieden te controleren: het zakelijke gebruik van de module, de impact op prestaties, beveiliging, compatibiliteit met de huidige Magento-versie, afhankelijkheden in Composer en het risico bij volgende updates.

Hoe ziet een audit van Magento 2-modules er stap voor stap uit?

Een goede audit begint met een inventarisatie. Eerst moet worden vastgesteld welke modules actief zijn, waar ze vandaan komen en waarvoor ze verantwoordelijk zijn. In de praktijk is het zinvol meerdere bronnen te vergelijken:

• de lijst met actieve modules uit bin/magento module:status,
• het bestand app/etc/config,
• afhankelijkheden in composer.json en composer.lock,
• de mappen app/code, vendor en eventuele handmatig geïnstalleerde modules,
• configuratie in het adminpaneel,
• Magento-, PHP- en serverlogs,
• cron-taken en externe integraties.

De volgende stap is het toewijzen van een rol aan de modules. Een extensie die verantwoordelijk is voor de checkout beoordeelt u anders dan een SEO-module, en weer anders dan een integratie met ERP. Een module die het bestelproces wijzigt, heeft een veel groter regressierisico dan een extensie die een eenvoudig informatieblok op de productpagina toevoegt.

Het is ook de moeite waard te controleren of de module een zakelijke eigenaar heeft. Als niemand binnen het bedrijf kan uitleggen waarom een bepaalde extensie in de webshop actief is, is dat een signaal voor diepere verificatie. Dat betekent niet automatisch dat de module moet worden verwijderd, maar wel dat de rol ervan niet goed is gedocumenteerd.

Een praktisch auditproces kan er zo uitzien:

1. verzamel de lijst met modules en installatiebronnen,
2. beschrijf de functie van elke extensie,
3. controleer of de functie nog wordt gebruikt,
4. beoordeel de impact op frontend, backend, checkout, cron en integraties,
5. controleer compatibiliteit met de versie van Magento, PHP en het thema,
6. bekijk fouten in logs en meldingen van gebruikers,
7. geef de module een status: behouden, bijwerken, vervangen of verwijderen,
8. bereid een wijzigingsplan voor in een testomgeving.

Zo’n proces is eenvoudiger dan een volledige code-audit, maar levert al veel informatie op. Het laat snel zien welke extensies cruciaal zijn, welke slechts aanvullend zijn en welke onnodig risico creëren.

Beoordelingstabel voor een Magento 2-module

Bij een groter aantal extensies is het verstandig een eenvoudige audittabel bij te houden. Die hoeft niet ingewikkeld te zijn. Belangrijk is dat ze helpt bij het nemen van beslissingen en begrijpelijk is voor zowel de technische persoon als de eigenaar van de webshop.

1. Wordt de module daadwerkelijk gebruikt?

De eerste vraag is eenvoudig: gebruikt de webshop de functie van deze extensie nog?

Het is verstandig te kijken naar:

• configuratie in het adminpaneel,
• zichtbare elementen op de frontend,
• afhankelijkheden in de checkout,
• cron-taken,
• API-integraties,
• exports en imports,
• e-mailtemplates,
• verkoopregels,
• aangepaste product- of klantattributen.

Vaak blijkt dat een module is geïnstalleerd voor een test, campagne of oude integratie, maar al lang geen betekenis meer heeft voor de verkoop. Een typisch voorbeeld is een extensie voor een eenmalige data-export die na een migratie actief in het systeem bleef, hoewel niemand hem nog gebruikt.

Wees voorzichtig met modules waarvan de functie niet direct zichtbaar is op de frontend. Een extensie kan alleen op de achtergrond werken: voorraadaantallen synchroniseren, gegevens naar ERP verzenden, contractprijzen wijzigen of attributen toevoegen die door een integratie worden gebruikt. Daarom mag de beslissing om te verwijderen niet uitsluitend voortkomen uit het feit dat de module niet zichtbaar is op de pagina.

2. Dupliceert de module geen functie van een andere oplossing?

In Magento ontstaat gemakkelijk een situatie waarin meerdere modules verantwoordelijk zijn voor een vergelijkbaar gebied. Voorbeelden:

• twee SEO-modules die metadata aanpassen,
• meerdere extensies die ingrijpen in de checkout,
• aparte modules voor reviews, rich snippets en schema.org,
• verschillende integraties die productgegevens exporteren,
• meerdere tools die scripts aan de pagina toevoegen.

Zo’n overlap verhoogt het risico op conflicten. Zelfs als de webshop correct werkt, kan het probleem pas zichtbaar worden na een Magento-update, een wijziging van het thema of de implementatie van een nieuwe PHP-versie.

Een goed voorbeeld is het SEO-gebied. De ene module kan verantwoordelijk zijn voor metadata, de tweede voor canonicals, de derde voor gestructureerde data en de vierde voor de sitemap. Als elk van deze modules vergelijkbare HTML-elementen wijzigt, kan de webshop tegenstrijdige tags of onvoorspelbare resultaten na een configuratiewijziging genereren. De audit moet dan aangeven welke module de bron van waarheid is voor dat gebied.

3. Heeft de module invloed op prestaties?

Niet elk prestatieprobleem komt door de server. Modules kunnen de webshop op verschillende manieren belasten:

• ze voeren zware SQL-query’s uit,
• ze legen de cache te vaak,
• ze genereren onnodige blokken op elke pagina,
• ze voegen veel JS- en CSS-bestanden toe,
• ze vertragen indexatie,
• ze maken te veel cron-taken aan,
• ze belasten het adminpaneel,
• ze voeren externe API-aanvragen uit tijdens het laden van de pagina.

In de audit is het verstandig frontend, backend, cron, indexatie en checkout apart te controleren. Een module die geen zichtbare invloed heeft op de homepage, kan nog steeds problemen veroorzaken bij het plaatsen van een bestelling of bij massale productbewerking.

Bij prestatieanalyse is het niet voldoende om alleen de PageSpeed van de homepage te controleren. In een Magento-webshop zijn scenario’s relevanter: een categorie met filters openen, een productkaart met varianten, toevoegen aan de winkelwagen, door de checkout gaan, een product opslaan in het paneel, data importeren, indexeren en cron-taken uitvoeren. Pas dan wordt duidelijk of het probleem de frontend, databasequery’s, een externe API of de modulelogica betreft.

Als de webshop tools gebruikt zoals New Relic, Blackfire, de Magento-profiler of monitoring van SQL-query’s, is het zinvol de resultaten naast de lijst met actieve extensies te leggen. Een module die veel query’s uitvoert op elke categoriepagina kan een groter probleem zijn dan een extensie die visueel zichtbaar is op de frontend, maar correct in de cache wordt opgeslagen.

4. Wordt de module bijgewerkt en is deze compatibel?

Een Magento-extensie moet worden onderhouden. Als een module al meerdere jaren niet is bijgewerkt, moet deze als technisch risico worden behandeld.

Controleer bij voorkeur:

• compatibiliteit met de huidige Magento-versie,
• compatibiliteit met de gebruikte PHP-versie,
• beschikbaarheid van updates via Composer,
• wijzigingsgeschiedenis,
• beveiligingspatches,
• compatibiliteit met het huidige thema,
• compatibiliteit met Hyva, als de webshop deze frontend gebruikt of wil gebruiken.

Het ontbreken van updates betekent niet altijd dat een module onmiddellijk moet worden verwijderd, maar het moet wel de vraag oproepen: is deze functie belangrijk genoeg om verder te onderhouden?

In de audit is het goed drie situaties te onderscheiden. De eerste: de module is actueel en heeft duidelijke compatibiliteit met de gebruikte Magento-versie. De tweede: er zijn updates beschikbaar voor de module, maar de webshop draait op een oudere versie. De derde: de module wordt niet meer ontwikkeld of de leverancier verklaart geen compatibiliteit met de huidige Magento en PHP. Deze laatste groep vereist meestal een vervangingsplan of extra tests vóór elke grotere wijziging.

5. Is de module veilig?

Magento-modules kunnen klantgegevens, bestellingen, betalingen, formulieren, bestanden, API-integraties en het adminpaneel verwerken. Daarom is de beveiliging van extensies net zo belangrijk als de beveiliging van Magento zelf.

Tijdens de audit is het verstandig te controleren:

• of de module eigen endpoints toevoegt,
• of de module openbaar toegankelijke formulieren heeft,
• of de module gebruikmaakt van bestandsuploads,
• of de module API-tokens opslaat,
• of de module het beheerderspaneel uitbreidt,
• of de module eigen ACL-rechten heeft,
• of de module standaardvalidatiemechanismen van Magento niet omzeilt.

Besteed bijzondere aandacht aan modules die niet uit een vertrouwde bron komen of handmatig zonder documentatie zijn aangepast.

Controleer ook of de module geen gevoelige gegevens opslaat in logs of configuratie op een manier die toegangscontrole bemoeilijkt. Dit geldt vooral voor integraties met betalingen, ERP, marketplace, AI-tools, SMS-gateways en verzenddiensten. Een API-token dat op de verkeerde plek is opgeslagen, kan een groter risico vormen dan de functie van de module zelf.

6. Verhoogt de module de onderhoudskosten?

De kosten van een module zijn niet alleen de aanschafprijs. Bij de werkelijke kosten moet u ook optellen:

• tijd voor updates,
• regressietests,
• conflicten met andere extensies,
• aanpassingen na wijzigingen in Magento,
• afhankelijkheid van externe diensten,
• tijd voor configuratiebeheer,
• technische support,
• risico op downtime.

Soms blijkt een goedkopere module duurder in onderhoud dan een oplossing die beter aansluit op de architectuur van de webshop. Kijk daarom naar de totale eigendomskosten, niet alleen naar de licentieprijs.

De kosten stijgen vooral wanneer een module bij elke update handmatige workarounds vereist. Als een extensie regelmatig moet worden aangepast na een wijziging van Magento, PHP, ElasticSearch/OpenSearch of het thema, omvat de echte prijs ook de tijd van de developer en tester. In zo’n geval moet de audit laten zien of het voordeliger is de huidige oplossing te blijven onderhouden of vervanging te plannen.

Verschillende typen modules vragen om verschillende beoordelingen

Niet alle Magento-extensies hebben dezelfde impact op de webshop. Daarom is het tijdens de audit verstandig ze in enkele groepen te verdelen.

Frontend-modules beïnvloeden het uiterlijk van de webshop, de layout, .phtml-bestanden, JavaScript, CSS, blokken en elementen van de product- of categoriepagina. Hierbij moet u prestaties, compatibiliteit met het thema en impact op Core Web Vitals controleren.

Checkout- en betaalmodules zijn zakelijk het meest gevoelig. Elke wijziging op dit gebied kan invloed hebben op conversie en het plaatsen van bestellingen. Dergelijke extensies vereisen tests van aankoopscenario’s, verzendmethoden, betalingen, kortingen, belastingen en gastbestellingen.

Backend-modules hebben vaak geen directe invloed op de klant, maar bepalen wel de efficiëntie van het team. Als een module het bestelgrid, het opslaan van producten of bulkacties vertraagt, ontstaat de kost elke dag in het werk van beheerders.

Integratiemodules verbinden Magento met ERP, PIM, WMS, marketplaces, vervoerders, facturatiesystemen of marketingtools. Hierbij zijn logs, retries, foutafhandeling, wachtrijen, API-limieten en weerstand tegen onbeschikbaarheid van het externe systeem cruciaal.

SEO- en contentmodules vereisen controle van de impact op indexatie, canonicals, metadata, schema.org, sitemaps, hreflangs en redirects. Fouten zijn hier mogelijk niet direct zichtbaar, maar kunnen na verloop van tijd gevolgen hebben voor organisch verkeer.

Zo’n indeling helpt prioriteiten te bepalen. Een checkout-module heeft meestal een hogere testprioriteit dan een module die één label op de productkaart toevoegt. Een ERP-integratie vraagt om een andere beoordeling dan een extensie voor een eenvoudige marketingpop-up.

Hoe neemt u de beslissing: behouden, bijwerken, vervangen of verwijderen?

Na de audit kan elke module aan een van vier groepen worden toegewezen.

Behouden

De module wordt gebruikt, is stabiel, compatibel met de Magento-versie en ondersteunt een belangrijk bedrijfsproces. Het is zinvol hem te behouden, maar de rol ervan wel te blijven documenteren.

Voorbeeld: een module voor integratie met een ERP-systeem synchroniseert voorraadniveaus en prijzen, werkt via een wachtrij, heeft een actuele versie en genereert geen fouten in logs. Ook al is hij niet zichtbaar voor de klant, hij is cruciaal voor de verkoop en moet in het systeem blijven.

Bijwerken

De module is nodig, maar draait in een oudere versie. Controleer de changelog, voer de update uit in een testomgeving en test de belangrijkste processen.

Voorbeeld: een betaalmodule heeft een nieuwere versie beschikbaar met compatibiliteitsfixes voor de huidige Magento en PHP. Het heeft geen zin hem te verwijderen, maar het behouden van de oude versie verhoogt het risico op problemen na volgende updates.

Vervangen

De module vervult een belangrijke functie, maar is problematisch: hij vertraagt de webshop, wordt niet ontwikkeld of bemoeilijkt updates. Dan kan migratie naar een andere extensie of implementatie van de functie op een beter controleerbare manier een betere oplossing zijn.

Voorbeeld: een SEO-module genereert noodzakelijke gestructureerde data, maar overschrijft tegelijk veel layoutelementen, conflicteert met het thema en heeft geen updates. De functie is nodig, maar deze specifieke extensie is mogelijk niet de beste manier om haar te onderhouden.

Verwijderen

De module wordt niet gebruikt, dupliceert andere functies of genereert meer risico dan voordeel. Verwijdering moet worden voorafgegaan door controle van afhankelijkheden, configuratie, data in de database en impact op de frontend.

Voorbeeld: een module voor een eenmalige productimport werd tijdens migratie gebruikt, wordt niet meer gestart, heeft geen zakelijke eigenaar en voegt nog steeds items toe in het adminpaneel. Na controle van afhankelijkheden kan verwijdering worden gepland.

Waarom modules niet blind verwijderen?

Alleen een module uitschakelen is mogelijk niet genoeg. Sommige extensies voegen toe:

• tabellen in de database,
• productattributen,
• klantattributen,
• kolommen in bestaande tabellen,
• configuratie-items,
• cron-taken,
• layout XML,
• e-mailtemplates,
• integraties met externe systemen.

Daarom moet het verwijderen van een module eerst in een testomgeving gebeuren. Na de wijziging moeten adminpaneel, frontend, winkelwagen, checkout, betalingen, verzending, indexatie, cache en logs worden gecontroleerd.

Controleer ook of de module geen data heeft achtergelaten die nog door andere processen wordt gebruikt. Voorbeelden zijn productattributen die in feeds worden gebruikt, extra klantvelden die in een B2B-integratie worden gebruikt of historische ordertabellen die nodig zijn voor rapportage. Soms kan een module worden uitgeschakeld, maar mogen de data niet meteen worden verwijderd.

Module-audit en Magento-update

Hoe meer ongeordende modules er zijn, hoe moeilijker een Magento-update wordt. Elke extensie kan eigen afhankelijkheden, preferences, plugins, event observers en template-overrides hebben.

Een goed uitgevoerde audit vóór een update helpt om:

• de tijd voor development te verkorten,
• het aantal conflicten te beperken,
• het risico op fouten na implementatie te verminderen,
• tests te vereenvoudigen,
• de stabiliteit van de webshop te verbeteren,
• het budget beter te plannen.

In veel gevallen komen updateproblemen niet door Magento zelf, maar door extensies die jarenlang zonder breder plan zijn toegevoegd.

Vóór een update is het verstandig een korte risicokaart op te stellen. Modules die ingrijpen in checkout, betalingen, prijzen, winkelwagen, indexatie, API en adminpaneel moeten op de lijst met prioriteitstests komen. Zuiver presentatiegerichte extensies kunnen later worden getest, maar er moet nog steeds worden gecontroleerd of ze compilatie, deployment of het genereren van statische assets niet blokkeren.

Module-audit en Hyva

Als de webshop een Hyva-implementatie plant, is een module-audit bijzonder belangrijk. Niet elke extensie die voor de standaard Magento-frontend is gemaakt, werkt correct met Hyvä zonder extra compatibiliteitslaag.

Controleer bij voorkeur:

• of de module ingrijpt in de frontend,
• of de module eigen .phtml-bestanden heeft,
• of de module RequireJS, Knockout of UI Components gebruikt,
• of de leverancier compatibiliteit met Hyva biedt,
• of een aparte compatibility-module nodig zal zijn,
• of de functie nog nodig is na herbouw van het template.

Dit is een goed moment om de webshop te vereenvoudigen en alleen de extensies te behouden die de verkoop echt ondersteunen.

Bij Hyva zijn vooral modules belangrijk die eerder waren gebaseerd op standaardmechanismen van de Magento-frontend, zoals RequireJS, Knockout of UI Components. Sommige functies kunnen eenvoudiger worden herschreven, andere vereisen een compatibiliteitsmodule en weer andere kunnen na herbouw van het template overbodig blijken. Een audit vóór de implementatie van Hyvä helpt voorkomen dat oude problemen naar de nieuwe frontend worden meegenomen.

Wat moet er na de audit overblijven?

Een module-audit moet eindigen met een werkdocument, niet alleen met een gesprek of een losse lijst opmerkingen. Het beste is als er na de review een tabel met beslissingen en een actieplan overblijft.

Goede documentatie na een audit moet bevatten:

• een volledige lijst met modules,
• de installatiebron van elke module,
• een beschrijving van de zakelijke functie,
• informatie of de module wordt gebruikt,
• impactgebieden: frontend, backend, checkout, cron, integraties, SEO,
• risicobeoordeling,
• aanbeveling: behouden, bijwerken, vervangen of verwijderen,
• actieprioriteit,
• notities voor regressietests,
• de beslissingsverantwoordelijke aan zakelijke of technische kant.

Zo’n document maakt volgende Magento-updates veel eenvoudiger. Het team hoeft niet telkens opnieuw uit te zoeken waarvoor een extensie dient en of deze kan worden aangepast. Het volstaat om terug te gaan naar de eerdere beoordeling en die met nieuwe informatie bij te werken.

Voorbeeld: hoe beoordeelt u drie verschillende modules?

Stel dat er in de webshop drie extensies actief zijn: een SEO-module, een checkout-module en een ERP-integratiemodule. Elk daarvan vraagt om een andere aanpak.

De SEO-module moet worden gecontroleerd op metadata, canonicals, gestructureerde data, sitemap, redirects en impact op indexatie. Een fout op dit gebied stopt de verkoop misschien niet onmiddellijk, maar kan na verloop van tijd de zichtbaarheid van de webshop in Google beperken.

De checkout-module vereist aankooptests. U moet verschillende combinaties doorlopen: ingelogde en niet-ingelogde klant, verschillende betaalmethoden, verzendmethoden, kortingscodes, eenvoudige en configureerbare producten, verschillende bezorglanden, verschillende btw-tarieven. Hier kan zelfs een klein conflict de conversie direct verlagen.

De ERP-integratiemodule moet worden beoordeeld vanuit het perspectief van stabiliteit van gegevensuitwisseling. Cruciaal zijn wachtrijen, logs, foutafhandeling, retries, API-limieten en dataconsistentie. Als de integratie met vertraging werkt of fouten niet afhandelt, kan de webshop producten verkopen met een verouderde voorraadstatus of een verkeerde prijs.

Dit voorbeeld laat goed zien waarom een audit van Magento 2-modules niet alleen een technische lijst met extensies mag zijn. Elke module heeft een andere impact op verkoop, SEO, klantenservice en het dagelijkse werk van het team.

Hoe vaak moet u een module-audit uitvoeren?

In een Magento 2-webshop is het verstandig minstens één keer per jaar een module-audit uit te voeren. Daarnaast zou dit een verplicht onderdeel moeten zijn vóór grotere technische wijzigingen.

Voor webshops die intensief worden doorontwikkeld, is een kortere review per kwartaal een goede oplossing. Dat hoeft geen volledige audit te zijn, maar het is waardevol om regelmatig te controleren of nieuwe modules gedocumenteerd, actueel en daadwerkelijk nodig zijn.

In de praktijk is het ook een goede standaard om elke nieuwe module al op het moment van implementatie aan de documentatie toe te voegen. Dan bestaat de jaarlijkse audit niet uit het vanaf nul ontdekken van de geschiedenis van de webshop, maar uit het bijwerken van bestaande kennis.

Audit van Magento 2-modules met hulp van een specialist

In een eenvoudige webshop kan een deel van de audit zelfstandig worden uitgevoerd: de lijst met modules controleren, configuratie bekijken en vaststellen welke functies worden gebruikt. Bij grotere implementaties is het echter verstandig het zakelijke perspectief te combineren met technische analyse van code, afhankelijkheden, logs, prestaties en compatibiliteit.

Kowal.store werkt met Magento 2-modules, installatie via Composer, compatibiliteit met thema’s en onderhoud van webshops op basis van Magento. Als de webshop extensies moet ordenen vóór een update, hostingmigratie, Hyva-implementatie of grotere herbouw, kan een module-audit een goede eerste stap zijn om risico te beperken.

Zo’n audit helpt niet alleen overbodige extensies te vinden, maar ook de verdere ontwikkeling van de webshop beter te plannen: welke functies u in Magento laat, welke u door andere modules vervangt en welke u naar externe tools verplaatst.

Samenvatting

Magento 2-modules zijn een grote kracht van dit platform, maar alleen wanneer ze bewust worden gekozen en onderhouden. Een te groot aantal willekeurige extensies kan de webshop vertragen, updates bemoeilijken, kosten verhogen en beveiligingsrisico’s creëren.

Een regelmatige audit helpt de controle over de architectuur van de webshop terug te krijgen. Ze helpt bepalen welke modules nodig zijn, welke updates vereisen, welke beter vervangen kunnen worden en welke veilig kunnen worden verwijderd.

Als een Magento-webshop al enkele jaren draait, door verschillende teams is ontwikkeld of een grotere update nadert, is een module-audit een van de beste eerste stappen om het platform op orde te brengen.