Für wen das ist
Shop-Betreiber und kleine Teams, deren Magento-2-Shop live ist und Umsatz macht und die Engineering brauchen statt einer weiteren Extension: ein Request-Pfad, der langsam geworden ist, ein Import, der den Katalog beschädigt, ein Checkout, der bei manchen Kunden fehlschlägt, ein Upgrade, das niemand anzustoßen wagt.
Ich arbeite seit Version 1 mit Magento und von 2021 bis 2026 täglich mit Magento 2 und Hyvä bei Sanexo B.V. Außerdem baue und betreibe ich Velgrina, einen Magento-2-Shop mit React-Native-App. Die Server unter diesen Shops betreibe ich selbst.
Typische Situationen
- Kategorie- und Produktseiten laden sekundenlang, und jeder Extension-Anbieter sagt, es liege nicht an seiner Extension.
- Der nächtliche Produktimport lässt still Attribute fallen, dupliziert SKUs oder legt die Website lahm.
- Bestellungen kommen mit Zahlung, aber ohne Bestätigung an, oder mit Bestätigung, aber ohne Zahlung.
- Das Luma-Frontend ist langsam und schwer, und der Wechsel zu Hyvä wurde zweimal verschoben wegen der Extensions, die dabei brechen würden.
- Ein Magento- oder PHP-Upgrade ist überfällig, und das letzte hat den Checkout einen Tag lang lahmgelegt.
- Eine frühere Agentur hat eigene Module ohne Dokumentation, Tests oder Staging-Umgebung hinterlassen.
Was ich liefere
- Performance-Arbeit entlang des gesamten Request-Pfads: Full-Page-Cache und Varnish, PHP-FPM, Datenbank und Indexer, Aufrufe an Dritte, vorher und nachher gemessen.
- Hyvä-Theme-Arbeit: einen Luma-Shop migrieren, Extensions ohne Hyvä-Kompatibilität ersetzen, die Templates schlank halten.
- Produkt- und Katalogimporte, die vor dem Schreiben validieren, fehlerhafte Zeilen isolieren, die Produktidentität stabil halten und ein Log hinterlassen, das jeden Lauf erklärt.
- Checkout-, Zahlungs-, Versand- und ERP-Integrationen, mit Webhook-Empfängern, die mit Duplikaten und verspäteten Events zurechtkommen.
- Upgrades und Migrationen: Magento-Versions- und PHP-Upgrades auf einer Staging-Kopie mit echten Daten, und Umzüge zwischen Hostern.
- Eigene Module, wenn der Marketplace nichts Passendes hat, geschrieben, um das nächste Upgrade zu überstehen, mit der mobilen App oder dem Headless-Frontend im Blick.
Wie es abläuft
Den Shop so betrachten, wie ein Request ihn sieht. Logs, Cache-Trefferquoten, langsame Queries, Indexer-Status, Queue-Tiefe, die Observer, die auf jeder Seite feuern. Das Ergebnis ist eine Liste von Ursachen mit Belegen, nach Wirkung geordnet.
Zuerst die größte Ursache beseitigen. Ich baue die Änderung auf einer Staging-Kopie des Shops mit echten Katalogdaten und einem Rückweg und teste sie, bevor sie in die Nähe von Kunden kommt.
In einem ruhigen Zeitfenster ausrollen, dann aufschreiben. Monitoring läuft während des Releases; danach eine kurze Notiz dazu, was sich geändert hat, worauf zu achten ist und was ich als Nächstes tun würde.