Sieben Klicks braucht ein Händler im Admin Panel von Magento Open Source, um den Cache zu leeren. Über die Kommandozeile genügt ein Befehl: bin/magento cache:flush. Genau dieser Unterschied macht die Magento 2 CLI zum Standardwerkzeug in Agenturen und technischen E-Commerce-Teams – und mit der aktuellen Version 2.4.8, die PHP 8.4 unterstützt, gehört die Beherrschung der Kommandozeile für technische Shop-Teams zur Pflicht. Wer Updates, Reindex-Läufe und Datenimporte noch manuell im Backend erledigt, verliert täglich Arbeitszeit.
Warum setzen Techniker auf die Magento 2 CLI statt aufs Admin Panel?
Die Antwort lässt sich in einem Satz zusammenfassen: Die Kommandozeile arbeitet reproduzierbar, skriptbar und deutlich schneller als jede Backend-Oberfläche. Wer bin/magento im Terminal aufruft, erhält über 150 Kommandos, die nahezu jeden Bereich des Shops abdecken – von der Konfiguration über die Indexverwaltung bis zum Deploy-Modus. Jeder Befehl lässt sich in Shell-Skripte oder CI-Pipelines packen und damit automatisieren.
Ein Beispiel aus dem Agenturalltag: Nach dem Einspielen eines Updates auf Magento Open Source 2.4.8 läuft eine feste Befehlskette. setup:upgrade bringt Datenbank-Schema und Daten-Patches auf den aktuellen Stand, setup:di:compile erzeugt den Dependency-Injection-Code, und setup:static-content:deploy baut die statischen Dateien neu. Im Admin Panel wäre diese Sequenz schlicht nicht möglich.
Das Admin Panel ist für Redaktion und Marketing gedacht. Der technische Betrieb eines Magento-Shops läuft im Terminal.
Für den Produktivbetrieb entscheidend: deploy:mode:set production schaltet den Shop in den performance-optimierten Modus, maintenance:enable sperrt den Shop während Deployments – per maintenance:allow-ips bleibt die eigene IP dabei freigeschaltet. Beides sind Kommandos, die Betreiber bei jedem Release nutzen.
Die Kommandos, die im Shop-Alltag zählen
Abseits von Deployments fallen im laufenden Betrieb vor allem vier Aufgaben an. indexer:reindex baut die Such-, Preis- und Katalogindizes neu auf – bei Katalogen ab 100.000 Artikeln ein Routinevorgang nach jedem Massenimport. cache:clean und cache:flush räumen gezielt den internen Cache beziehungsweise den kompletten Cache-Storage auf. config:set ändert Einstellungen direkt in der Datenbank, ohne dass ein Mitarbeiter ins Backend muss. Und cron:run startet geplante Aufgaben manuell, etwa wenn ein Cronjob hängengeblieben ist.
Weniger bekannt, aber bei Multi-Umgebungen hilfreich: app:config:dump exportiert die Systemkonfiguration in eine Datei, app:config:import spielt sie auf einer anderen Instanz wieder ein. Damit lassen sich Einstellungen zwischen Staging und Live synchronisieren, ohne Klickarbeit im Backend.
Wie funktionieren Import und Export über die Magento 2 CLI?
Hier liegt die größte Fehleinschätzung vor: Magento bringt nativ kein vollwertiges CLI-Kommando für den Produktimport mit. Der klassische Import läuft im Admin Panel über System → Import. Wer große Datenmengen automatisiert einspielen will, nutzt stattdessen die Bulk-REST-API: Die Anfragen landen in einer RabbitMQ-Warteschlange, und der Konsument async.operations.all – gestartet über queue:consumers:start – verarbeitet sie asynchron. So lassen sich CSV-Dateien mit Zehntausenden Produkten importieren, ohne dass ein Browser-Timeout den Vorgang abbricht.
Für Händler ohne eigene Entwicklungskapazität schließt die Extension Improved Import & Export von Firebear diese Lücke. Das Modul erlaubt Import- und Export-Profile für Produkte, Kunden und Bestellungen, die sich per CLI-Befehl oder Cron anstoßen lassen – inklusive Anbindung an Google Sheets und FTP-Quellen. Bei Adobe-Commerce-Projekten mit ERP-Anbindung gehört ein solches Werkzeug zum üblichen Stack.
Shopbetreiber sollten die kommenden Wochen nutzen, um ihre Routineaufgaben zu inventarisieren: Welche Schritte im Backend wiederholen sich wöchentlich? Fast jede davon existiert als bin/magento-Kommando – und wer sie einmal skriptet, muss sie nie wieder klicken.