Een extensie installeren is snel: zoeken op de Marketplace, licentie kopen, composer require, klaar. Wat je op dat moment niet ziet, is wat er bij die paar klikken meekomt. Een leverancier van wiens releaseschema je jarenlang afhankelijk bent. Onderhoud dat iemand moet blijven doen, ook als die extensie allang “gewoon werkt”. En risico dat niet in de productbeschrijving staat.
Dit is wat je checkt vóór je een extensie koopt, en wat je doet met de extensies die al in je shop staan.
Wat je checkt vóór je een extensie kiest
Onderhoud en releasetempo. Een extensie die het laatste jaar geen update kreeg, is niet per se slecht, maar wel een signaal om naar te vragen. Kijk op de changelog van de leverancier of op Packagist wanneer de laatste release uitkwam, en of nieuwe Magento- en PHP-versies in die releases worden gevolgd.
Compatibiliteit met je Magento- en PHP-versie. Niet alleen vandaag, ook over een jaar. PHP 8.2 krijgt na 31 december 2026 geen beveiligingsupdates meer, en nieuwere Magento-versies laten oudere PHP-versies vallen. Een extensie die niet verder komt dan PHP 8.2, wordt zo je blokkade bij de volgende upgrade. Check het zelf met composer why-not php 8.3: dat commando laat direct zien welke packages een hogere PHP-versie tegenhouden. Welke Magento-versie bij welke PHP-versie hoort, staat in PHP 8.2 end of life.
Hyvä-compatibiliteit. Draai je op Hyvä, dan zijn er voor een extensie drie mogelijkheden: native Hyvä-ondersteuning, een losse compatibility module, of niets. De Hyvä Module Tracker houdt bij wat er al is, en de documentatie over compatibility modules legt uit wat die wel en niet oplossen. Is er geen van beide, dan laat je de compatibiliteit bouwen of kies je een andere extensie. Reken dat mee in de prijs, vóór je koopt.
Codekwaliteit en de leverancier zelf. Adobe controleert elke Marketplace-extensie via het Extension Quality Program: een geautomatiseerde check op codestandaarden, malware en plagiaat, plus een handmatige QA-review. Dat zegt iets, maar niet alles: een bekende naam op de Marketplace zegt niets over wat er in de code gebeurt. Sansec publiceerde begin juli 2026 over tientallen Amasty-extensies met zes kritieke lekken, van een leverancier die al jaren een vaste naam is in Magento-land.
Kijk ook naar de licentievorm. Een jaarlicentie betekent dat je updates krijgt zolang je betaalt. Stop je met betalen, dan blijft de code meestal werken, maar krijg je geen fixes meer, ook niet voor een kritiek lek. Vraag dat vooraf expliciet aan de leverancier, niet achteraf als het misgaat.
Supply chain: ook een betaalde extensie kan de achterdeur zijn
Een extensie van een betaalde leverancier voelt veiliger dan een gratis download. Dat is niet altijd terecht.
In 2022 werd de distributieserver van FishPig gehackt. Klanten die een update ophaalden, kregen malware mee in License.php, die uiteindelijk de Rekoobe-backdoor installeerde. Sansec onderzocht het incident. De extensie zelf was niet het probleem, de distributieweg was het.
In 2025 vond Sansec iets dat nog dieper zat: 21 extensies van Tigren, Meetanshi en Magesolution bevatten een backdoor die tussen 2019 en 2022 was ingebouwd en pas in april 2025 actief werd. Shops draaiden die code jarenlang zonder dat er iets gebeurde, tot op een gegeven moment de schakelaar omging.
Wat beide incidenten gemeen hebben: “draait al jaren zonder problemen” is geen garantie voor morgen. Een update doorzetten omdat het altijd goed ging, is een gok. Laat je developer bij elke update de changelog naast de gewijzigde bestanden leggen, en let op wijzigingen die niets met de aangekondigde fix te maken hebben, zoals een aangepaste licentiecheck. En twijfel je over een extensie die je al langer gebruikt, laat die code dan checken. Dat niets gebeurt, bewijst niet dat er niets in zit.
Waarom minder extensies beter is
Elke extensie die je toevoegt, is een stuk code dat je niet zelf geschreven hebt, waar je afhankelijk van bent voor updates, en dat kan botsen met iets anders in je shop. Upgrades duren langer naarmate er meer extensies mee moeten. Performance lijdt onder code die je niet nodig hebt maar wel laadt. Het aanvalsoppervlak groeit met elke extra module, en conflicten tussen extensies kosten uren om uit te zoeken. Wat dat in geld betekent, lees je in Magento-kosten besparen.
Check daarom eerst of Magento of Hyvä het al kan voordat je een extensie zoekt. Veel functionaliteit die ooit alleen met een extensie kon, zit inmiddels standaard in Magento, en in een Hyvä-thema is een frontend-functie vaak zonder extra module te bouwen.
Is er geen standaardoplossing, dan is een kleine, zelfgebouwde module soms betrouwbaarder dan een zware extensie die honderd features biedt waarvan je er drie gebruikt. Minder code om te onderhouden, minder afhankelijkheid van een externe leverancier, en geen functionaliteit die je nooit aanraakt maar wel meegaat bij elke upgrade. Kijk voor dat alternatief naar een eigen module laten bouwen.
Wat je doet met de extensies die je al hebt
De meeste shops hebben na een paar jaar meer extensies dan iemand nog kan opnoemen. Begin met een inventaris: bin/magento module:status laat zien wat actief is, je composer.json laat zien wat er daadwerkelijk via Composer binnenkomt.
Uitschakelen is niet hetzelfde als verwijderen. Een module met bin/magento module:disable uitzetten laat de code gewoon staan, inclusief eventuele kwetsbaarheden erin. Wil je een extensie echt weg, verwijder die dan via Composer, en pas nadat je op staging hebt getest dat de shop zonder die module blijft werken. Let op: composer remove haalt alleen de code weg. Tabellen en instellingen van de module blijven in de database staan, tenzij je developer de module met bin/magento module:uninstall verwijdert of die resten zelf opruimt.
Het grootste risico is een extensie die als zip-bestand rechtstreeks in app/code is gezet, buiten Composer om. Niemand kan dan nog met zekerheid zeggen welke versie erop staat, of waar een update vandaan zou moeten komen. Breng die situaties als eerste in kaart.
Doe deze inventarisatie niet eenmalig. Bij elke grote upgrade verandert de situatie opnieuw: een extensie die vorig jaar nog meeging, kan dit jaar de blokkade zijn. Daarom hoort extensiebeheer bij structureel Magento onderhoud, en niet bij een losse actie rond een upgrade.
Wil je weten wat er precies in je shop draait en waar het risico zit, dan zet een Magento code review dat zwart op wit, los van wat de leverancier erover zegt. Of neem contact op, dan kijken we mee.
Veelgestelde vragen
Is een Marketplace-extensie altijd veilig?
Nee. Het Extension Quality Program van Adobe geeft een signaal over codekwaliteit, maar geen garantie. Sansec vond in 2026 nog kritieke lekken in extensies van een bekende, gevestigde leverancier. Een plek op de Marketplace vervangt geen eigen check.
Uitschakelen of verwijderen, wat is het verschil?
Uitschakelen zet een module uit maar laat de code op de server staan, inclusief eventuele kwetsbaarheden. Verwijderen via Composer haalt de code daadwerkelijk weg. Wil je een extensie echt kwijt, verwijder hem dan in plaats van hem alleen uit te schakelen.
Extensie kopen of laten bouwen?
Dat hangt af van hoeveel van de functionaliteit je daadwerkelijk gebruikt. Past een extensie met honderd features maar drie die je nodig hebt, dan is een kleine, eigen module vaak minder onderhoud en minder risico dan de volledige extensie.
Hoe weet ik of een extensie met Hyvä werkt?
Check de Hyvä Module Tracker voor native ondersteuning of een compatibility module. Staat een extensie er niet in, vraag dan rechtstreeks aan de leverancier, en reken er niet op dat een Luma-extensie zonder meer op Hyvä werkt.