Beispielauftrag Magento 2: Ein Sicherheitspatch und eine Pflichtangabe im Checkout für einen B2B-Shop

Beispielauftrag in Magento 2: Sicherheitspatch und Pflichtfeld Firma mit Prüfung der Umsatzsteuer-ID im Checkout
Was die Agenten vor der Freigabe prüfen
✓Patch eingespielt, Version und Changelog stimmen
✓Indexer, Cron und Caches laufen sauber
✓Firma im Checkout Pflicht, Fehlermeldung verständlich
✓USt-ID wird geprüft, Kundengruppe wechselt
✓alle Zahlungsarten bis zur Bestellung getestet
✓keine Änderung an Core-Dateien

Dieser Beitrag beschreibt einen erfundenen, aber typischen Auftrag. Die Firma gibt es nicht, der Ablauf entspricht der Arbeitsweise der Eywora AI Crew.

Die Ausgangslage

Ein Großhändler für Elektroinstallationsmaterial verkauft über einen Shop auf Magento Open Source 2.4 ausschließlich an Gewerbekunden. Zwei Dinge stören seit Längerem: Immer wieder bestellen Kunden ohne Firmenangabe, was die Buchhaltung bei der Rechnungsstellung ausbaden muss, und die Umsatzsteuer-ID wird nirgends geprüft. Dazu kommt ein Sicherheitspatch, den Adobe vor zwei Wochen veröffentlicht hat und der noch nicht eingespielt ist. Der Betreiber beschreibt alle drei Punkte in einem Auftrag.

Schritt 1: Priorität und Reihenfolge

Der KI-Teamleiter stellt den Sicherheitspatch an den Anfang. Er betrifft das Live-System unabhängig von den anderen Wünschen und soll deshalb nicht auf die Checkout-Änderungen warten müssen. Vorschlag: Patch als eigene, erste Änderung mit eigener Freigabe, Checkout-Anpassungen als zweite. So kann der Patch am nächsten Releasetag live gehen, auch wenn der Checkout noch in der Feedbackrunde ist. Der Agent für Kostenschätzung nennt für beide Teile eine grobe Spanne.

Schritt 2: Der Patch an der Kopie

Der Shop wird per Composer verwaltet. An der Kopie spielt der Agent für Schnittstellen und Systeme den Patch ein, führt die Setup-Upgrades aus, kompiliert die Abhängigkeiten neu und erzeugt die statischen Dateien. Danach prüft er, was bei Magento nach jedem Update gern hakt: Laufen alle Indexer durch, arbeitet der Cron, sind die Caches sauber. Die automatischen Tests rufen Kategorie-, Produkt- und Warenkorbseiten auf und schließen je eine Bestellung mit jeder aktiven Zahlungsart ab. Der Agent für Sicherheit und Datenschutz bestätigt anhand von Version und Changelog, dass der Patch greift.

Schritt 3: Checkout mit Bordmitteln und einem kleinen Modul

Für die Umsatzsteuer-ID braucht es keinen eigenen Code: Magento bringt die Prüfung über den europäischen Abgleichdienst mit und kann Kunden abhängig vom Ergebnis automatisch einer Kundengruppe zuordnen. Die Agenten konfigurieren das und legen die Gruppen „Gewerbe geprüft“ und „Gewerbe ungeprüft“ an, die der Betreiber später für Preise und Zahlungsarten nutzen kann. Das Pflichtfeld Firma dagegen lässt sich nicht einfach einschalten. Dafür entsteht ein kleines eigenes Modul, das die Adressfelder im Checkout um die Pflichtregel ergänzt und eine verständliche Fehlermeldung liefert. Es ändert keine Core-Dateien und keine Dateien anderer Module, damit spätere Magento-Updates es nicht überschreiben. Ein zweiter Agent prüft den Code, die Designerin die Darstellung im Checkout auf dem Smartphone.

Schritt 4: Vorschau, Freigabe, Livegang

Der Betreiber gibt den Patch nach kurzer Prüfung der Vorschau frei, er geht am Dienstag mit Backup live. Für den Checkout bittet er um eine Änderung: Die Fehlermeldung soll auf die Rechnungsstellung hinweisen, nicht nur „Pflichtfeld“ sagen. Nach der zweiten Vorschau gibt er frei, der Checkout geht am Donnerstag live, wieder mit Backup davor. Beide Änderungen sind getrennt im Versionierungssystem dokumentiert und lassen sich unabhängig voneinander zurücksetzen. Zwei Rücksetzungen pro Monat sind enthalten.

Was dieses Beispiel zeigt

Sicherheitspatches warten in vielen Shops, weil sie an andere Aufgaben gekoppelt oder schlicht vergessen werden. Ein Entwicklungsteam, das sie entkoppelt und mit eigenem Backup und eigener Freigabe einspielt, nimmt dem Betreiber genau diese Sorge ab. Und auch in Magento gilt: erst die Bordmittel, dann so wenig eigener Code wie möglich. Die unterstützten Magento-Versionen nennt die Systemliste; was eine Agentur und ein KI-Entwicklungsteam bei solchen Aufgaben unterscheidet, der Beitrag KI-Entwicklungsteam oder Agentur?.

Quellen

  1. Adobe – Adobe Commerce und Magento Open Source, Lifecycle Policy und Release-Informationen – https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy
  2. Eywora, FAQ zur AI Crew: Kann die AI Crew Updates durchführen, was passiert nach dem Livegang – https://www.eywora.com/faq/ai-crew/

Methodik & Quellen

Die genannten Abläufe, Reaktionszeiten, Releasetage und Vertragsbedingungen entsprechen dem Leistungsumfang der Eywora AI Crew zum Zeitpunkt der Veröffentlichung; verbindlich sind die FAQ und die AGB. Beispielaufträge sind erfundene, typische Szenarien und keine Kundenprojekte.

Veröffentlicht 30. Oktober 2026 · Autor: Eywora Redaktion

Mehr lesen

Schematische Darstellung: ein KI-Agent liest, ändert und testet Code an einer Kopie eines Onlineshops

AI Crew

Was ist ein KI-Agent für Shop-Entwicklung?

ChatGPT schreibt Code, den Sie selbst einbauen müssen. Ein KI-Agent arbeitet direkt an einer Kopie Ihres Shops, testet und dokumentiert. Was ihn ausmacht, warum ein Team aus Agenten besser ist als einer, und wo die Grenzen liegen.

6 Min. Lesezeit

Gegenüberstellung: Ticketstapel einer Agentur neben einer Aufgabenliste mit Vorschau und Freigabe

AI Crew

KI-Entwicklungsteam oder Agentur?

Die laufende Pflege eines Shops passt weder zum Angebot-pro-Aufgabe der Agentur noch zum Kalender eines Freelancers. Ein Vergleich entlang von vier Kriterien, ohne Heilsversprechen: Wofür ein KI-Entwicklungsteam gemacht ist, und wofür nicht.

7 Min. Lesezeit

Alle Beiträge →

Bereit zu sehen, wie das bei Ihnen aussieht?

Demo an Ihrem Shop.

20 Minuten live: Sie beschreiben eine Aufgabe, wir zeigen, wie die AI Crew sie an einer Kopie umsetzt. Unverbindlich und ohne Vorbereitung.