Magento-modules op maat, geschreven door iemand die de shop kent

Wanneer een eigen module beter is dan een gekochte

Een module is een los stuk code dat functionaliteit aan Magento toevoegt zonder de kernbestanden van Magento aan te passen. Dat maakt updates veiliger. Toch vraagt niet elk probleem om eigen code.

• Er bestaat geen module die jouw situatie dekt, bijvoorbeeld een eigen orderflow in je magazijn.
• Een gekochte module doet het meeste, maar een klein stuk ontbreekt en je moet bij elke update om dat gat heen werken.
• Een gekochte module laadt scripts en queries die je niet gebruikt en maakt de shop daarmee trager.
• Magento zelf heeft een fout of een leemte, en je wilt een gerichte fix zonder de kern te wijzigen.
• Twee systemen moeten iets uitwisselen wat standaard niet kan.

Bestaat er een goede module die past? Dan raad ik die aan. Eigen code is onderhoud dat je meekoopt, dus ik bouw alleen wat zich terugverdient.

Hoe een module in Magento 2 werkt

Een module meldt zich bij Magento aan met een paar configuratiebestanden. Daarna kan hij op vaste punten ingrijpen: een plugin past het gedrag van een bestaande functie aan, een observer reageert op een gebeurtenis (zoals een geplaatste bestelling), en templates bepalen wat de bezoeker ziet.

Dat klinkt overzichtelijk, maar Magento voert veel modules door elkaar uit. Twee modules die dezelfde functie aanpassen, kunnen elkaars werk teniet doen. Zo'n conflict zie je niet in de code van je eigen module, alleen in het gedrag van de hele shop.

Daarom lees ik eerst hoe de bestaande modules in elkaar zitten voordat ik een regel schrijf. Dat is het verschil tussen een module die op een lege installatie werkt en een module die in jouw shop werkt.

Modules die ik zelf schreef

Dit zijn modules uit de shop waar ik zelf in werk. Ze laten zien welk soort problemen een eigen module oplost.

• Content Security Policy en SRI-hashes: de CSP zijn de regels die bepalen welke scripts je shop mag laden, een SRI-hash is een controlesom waarmee de browser nagaat of een bestand niet is aangepast. Mijn module loste een fout op waarbij de hashes na een deploy niet meer klopten met de uitgeleverde bestanden.
• Canonical-tags op CMS-pagina's: een canonical-tag vertelt Google welke URL de originele is. Op CMS-pagina's zet Magento die zelf niet. Mijn fix doet dat wel.
• Een 'gate' voor scripts van derden: chatwidgets, trackers en andere externe scripts laden pas nadat een bezoeker iets doet. De eerste weergave wacht dan niet meer op code van anderen.
• Een eigen magazijnmodule voor orderpicken, het samenstellen van bestellingen uit het schap. Die is nog in ontwikkeling.

Geen van deze modules is een product dat je kunt kopen. Ze bestaan omdat de shop erom vroeg. Zo werk ik ook voor jou.

Zo werk ik aan jouw module

Een module die in een testshop werkt, kan op productie nog steeds misgaan. Daarom loopt elk traject langs dezelfde stappen.

• Eerst lezen: hoe zit de bestaande code en zitten de bestaande modules in elkaar, en welke raken hetzelfde onderdeel als de nieuwe.
• Wijzigingen eerst op een testomgeving, met een kopie van de situatie op productie.
• Uitrol zonder dat de shop plat gaat. Bezoekers en bestellingen lopen gewoon door.
• Geen volledige cache-flush op productie. Een flush gooit alle opgeslagen pagina's weg, waardoor de shop tijdelijk traag wordt. Ik ververs alleen wat nodig is.

Na de uitrol controleer ik of de module doet wat hij moet doen, op de pagina's waar het om gaat.

Wat ik niet doe

Een module is code die jij straks laat meedraaien. Daarom houd ik me aan een paar grenzen.

• Kernbestanden van Magento aanpassen. Dat maakt elke update een risico.
• Een module bouwen terwijl er al een goede bestaat die past.
• Direct op productie ontwikkelen of testen.
• Een volledige cache-flush op productie draaien.
• Gekochte modules uit je shop halen zonder dat jij daarom vraagt.

Als eigen code niet de beste route is, zeg ik dat.

Verwante pagina's