Magento CLI Hidden Gems: Power-User-Befehle

1. Warum Standard-CLI-Wissen bei komplexen Projekten nicht reicht

Jeder Magento-Entwickler kennt bin/magento setup:upgrade, cache:flush und indexer:reindex. Diese Grundbefehle reichen für ein neu aufgesetztes Projekt, aber sie versagen genau dann, wenn es wirklich interessant wird: bei einem Plugin-Konflikt zwischen drei Drittanbieter-Modulen, bei einem gesperrten Admin-Account während eines Kundentermins, oder bei einem Cron-Job, der in der Produktion nicht mehr zuverlässig läuft. An dieser Stelle trennt sich die Magento-CLI-Grunderfahrung von echtem Power-User-Wissen. Die Magento CLI Hidden Gems in diesem Artikel sind Befehle, die in den meisten Einsteiger-Tutorials fehlen, aber in jedem Agenturalltag mehrfach pro Woche gebraucht werden.

Der gemeinsame Nenner dieser Power-User-Befehle ist, dass sie Diagnosezeit drastisch reduzieren. Statt Code zu durchsuchen, um herauszufinden, welche Plugins eine Methode patchen, liefert ein einziger Befehl die vollständige Antwort. Statt eine SQL-Abfrage gegen die admin_user-Tabelle abzusetzen, entsperrt ein CLI-Befehl den Account in einer Zeile. Diese CLI Hidden Gems sind kein Ersatz für Grundlagenwissen, sondern eine Erweiterung, die aus reaktivem Debugging proaktive Diagnose macht. In den folgenden Abschnitten gehen wir neun solcher Befehle im Detail durch, mit realen Anwendungsfällen aus dem Mark-Shust-Docker-Setup, das mironsoft.de für Magento-2.4.8-Projekte einsetzt.

Ein wichtiger Hinweis vorab: Im Projekt wird niemals direkt php bin/magento aufgerufen, sondern immer der Wrapper bin/magento aus dem bin/-Verzeichnis. Das stellt sicher, dass der Befehl im richtigen Container-Kontext ausgeführt wird, unabhängig davon, ob PHP lokal überhaupt installiert ist. Alle folgenden Beispiele nutzen konsequent diese Wrapper-Konvention.

2. dev:di:info: Plugins und Preferences einer Klasse sofort sehen

Der wohl nützlichste unter den CLI Hidden Gems ist bin/magento dev:di:info. Der Befehl nimmt einen vollqualifizierten Klassennamen entgegen und listet auf: welche Preference diese Klasse ersetzt, welche Plugins in welcher Reihenfolge auf sie registriert sind, und ob es sich um einen virtuellen Typ handelt. Ohne diesen Befehl bleibt nur die manuelle Suche durch alle di.xml-Dateien im vendor- und app/code-Verzeichnis, was bei einem Projekt mit fünfzig oder mehr installierten Modulen schnell zehn bis fünfzehn Minuten kostet. Mit dev:di:info liegt die Antwort in unter einer Sekunde vor.

Besonders wertvoll ist dieser Befehl, wenn ein Kunde meldet, dass sich ein Preis oder eine Berechnung "irgendwie falsch" verhält, ohne dass der Entwickler weiß, welche Module überhaupt an dieser Stelle eingreifen. Statt zu raten, führt man dev:di:info auf die betroffene Klasse aus und sieht sofort die vollständige Interceptor-Kette samt sortOrder. Das ist auch der erste Schritt bei jeder Analyse von Plugin-Sortierreihenfolge-Konflikten zwischen mehreren Modulen.

# Show every preference, plugin and virtual type registered for a class
bin/magento dev:di:info "Magento\Catalog\Model\Product"

# Typical output structure:
# Preference for Magento\Catalog\Model\Product: none
#
# Plugins for Magento\Catalog\Model\Product:
#   plugin_name              sortOrder   instance
#   -----------------------  ----------  ------------------------------------
#   vendor_pricing_plugin    10          Vendor\Pricing\Plugin\ProductPlugin
#   vendor_inventory_plugin  20          Vendor\Inventory\Plugin\ProductPlugin
#
# Virtual types found: none

# Same for a service contract interface, useful before overriding a repository
bin/magento dev:di:info "Magento\Catalog\Api\ProductRepositoryInterface"

Ein weiterer Anwendungsfall: Vor dem Anlegen eines eigenen Plugins lohnt sich immer ein Blick mit dev:di:info auf die Zielklasse, um zu prüfen, ob bereits andere Module dort eingreifen. So lassen sich sortOrder-Kollisionen von vornherein vermeiden, statt sie erst nach dem Deployment im Fehlerfall zu entdecken. Dieser Befehl gehört zu den Power-User-Befehlen, die jeder erfahrene Magento-Entwickler reflexartig vor jeder größeren Änderung an einer Kernklasse einsetzt.

3. module:config:status und module:status vor jedem setup:upgrade

Die meisten Entwickler kennen bin/magento module:status nur, um zu sehen, welche Module aktiv oder deaktiviert sind. Als Hidden Gem lohnt sich der Befehl aber auch als Diagnose-Werkzeug direkt VOR einem setup:upgrade, insbesondere nach einem Composer-Update mit vielen neuen oder aktualisierten Paketen. Der Befehl zeigt die tatsächliche Modul-Reihenfolge, wie sie aus den sequence-Deklarationen aller module.xml-Dateien berechnet wurde, und macht sichtbar, ob ein neu installiertes Modul an einer unerwarteten Stelle in der Ladereihenfolge landet.

bin/magento module:config:status ergänzt das um einen Abgleich zwischen der in app/etc/config.php gespeicherten Modulliste und dem tatsächlichen Zustand im Dateisystem. Weicht beides voneinander ab, etwa weil ein Modul per Composer entfernt, aber nicht sauber deaktiviert wurde, meldet der Befehl das explizit, statt dass der nächste setup:upgrade mit einer kryptischen Fehlermeldung abbricht. Gerade bei Multi-Entwickler-Teams, in denen mehrere Personen parallel Module hinzufügen oder entfernen, verhindert dieser Check-Schritt viele der klassischen "bei mir funktioniert es aber"-Situationen.

# List every module and its enabled/disabled state
bin/magento module:status

# Compare declared module config against the actual filesystem state
bin/magento module:config:status

# Typical warning before it becomes a setup:upgrade failure:
# Command is not executed because of the following error:
# Value of module Vendor_OldModule differs from the value saved
# in app/etc/config.php by 1

# Run this diagnostic reflexively after every composer update
bin/composer update vendor/some-package
bin/magento module:config:status
bin/magento setup:upgrade

4. indexer:set-mode und gezieltes Reindex einzelner Indexer

Die meisten Tutorials erklären bin/magento indexer:reindex, das pauschal alle Indexer neu aufbaut. In einem Produktkatalog mit mehreren hunderttausend SKUs ist das jedoch selten die richtige Wahl, weil es unnötig lange dauert und temporär die Systemlast erhöht. Der Power-User-Befehl in dieser Kategorie ist bin/magento indexer:reindex <indexer_id>, mit dem sich genau ein einzelner Indexer gezielt neu berechnen lässt, etwa nur der Preisindex nach einer Preisregel-Änderung, ohne den kompletten Kategorie- oder Suchindex mit anzustoßen.

Ebenso wichtig ist bin/magento indexer:show-mode, das für jeden Indexer anzeigt, ob er im Modus "Update on Save" oder "Update on Schedule" läuft. In der Produktion sollte praktisch immer der Schedule-Modus aktiv sein, damit Indexierung über Cron-Jobs im Hintergrund läuft, statt jede einzelne Speicheraktion im Admin-Panel zu blockieren. Der Befehl bin/magento indexer:set-mode schedule <indexer_id> setzt diesen Modus gezielt für einzelne Indexer, was hilfreich ist, wenn ein bestimmter Indexer aus Debugging-Gründen temporär synchron laufen soll, während alle anderen im Schedule-Modus bleiben.

# Show current mode (update on save / update on schedule) per indexer
bin/magento indexer:show-mode

# Reindex a single indexer instead of all of them
bin/magento indexer:reindex catalog_product_price

# Set a specific indexer to scheduled mode without touching the others
bin/magento indexer:set-mode schedule catalogsearch_fulltext

# Temporarily force synchronous mode for one indexer while debugging
bin/magento indexer:set-mode realtime catalog_product_price

In der Praxis kombiniert man diese beiden Befehle: indexer:show-mode als Diagnose, gefolgt von einem gezielten indexer:reindex <id>, statt reflexartig alle Indexer neu zu berechnen. Diese präzise Steuerung ist einer der Punkte, die einen erfahrenen Magento-Entwickler im Produktionsbetrieb von einem Anfänger unterscheiden.

5. maintenance:allow-ips für kontrollierte Deployments

Der Wartungsmodus bin/magento maintenance:enable ist bekannt, aber sein wichtigster Begleitbefehl wird oft übersehen: bin/magento maintenance:allow-ips <IP-Adressen>. Damit lässt sich der Wartungsmodus aktivieren, während bestimmte IP-Adressen, etwa das Büronetzwerk der Agentur oder die IP eines Kunden, weiterhin normalen Zugriff auf den Shop haben. Das ist der Unterschied zwischen einem kompletten Blackout für alle Besucher und einem kontrollierten Testfenster während eines laufenden Deployments.

bin/magento maintenance:status ergänzt das, indem es sowohl den aktuellen Wartungsstatus als auch die Liste der freigegebenen IP-Adressen anzeigt, was besonders hilfreich ist, wenn mehrere Entwickler an einem Deployment beteiligt sind und niemand mehr genau weiß, wer welche IP wann freigeschaltet hat. Diese Hidden Gems rund um den Wartungsmodus verwandeln ein grobes Ein/Aus-Werkzeug in ein präzises Instrument für kontrollierte Rollouts, gerade bei größeren Migrationen oder Layout-Umbauten.

# Enable maintenance mode but allow specific IPs through
bin/magento maintenance:enable --ip-address=203.0.113.42,198.51.100.7

# Show current status and the list of currently allowed IPs
bin/magento maintenance:status

# Add another IP to the allow-list without restarting maintenance mode
bin/magento maintenance:allow-ips 203.0.113.42,198.51.100.7,192.0.2.15

# Disable maintenance mode once the deployment is verified
bin/magento maintenance:disable

6. admin:user:unlock und admin:user:create für Notfälle

Ein gesperrter Admin-Account mitten in einem Kundentermin ist ein klassischer Stresstest für jeden Magento-Entwickler. Statt eine SQL-Abfrage gegen die admin_user-Tabelle abzusetzen und das Feld lock_expires manuell zurückzusetzen, löst bin/magento admin:user:unlock <username> das Problem in einer Zeile, ohne dass man überhaupt eine Datenbankverbindung öffnen muss. Das ist einer der Power-User-Befehle, der selten in Tutorials auftaucht, weil er nur in Notfällen gebraucht wird, dann aber Minuten statt Sekunden Bearbeitungszeit spart.

bin/magento admin:user:create erlaubt es, einen neuen Admin-Benutzer vollständig per CLI anzulegen, inklusive Rolle, Passwort und E-Mail-Adresse, ohne dass ein bestehender Account funktionsfähig sein muss. Das ist besonders bei einer frischen Staging- oder Testumgebung praktisch, wenn noch kein einziger Admin-Zugang existiert, oder wenn der einzige verbliebene Super-Admin-Account versehentlich gelöscht wurde. Beide Befehle zusammen decken die häufigsten Admin-Zugriffsnotfälle ab, ohne dass ein direkter Datenbankzugriff nötig ist.

# Unlock an admin account after too many failed login attempts
bin/magento admin:user:unlock jdoe

# Create a fresh admin user directly via CLI, no working account required
bin/magento admin:user:create \
  --admin-user="emergency_admin" \
  --admin-password="Str0ng!Passw0rd" \
  --admin-email="admin@mironsoft.de" \
  --admin-firstname="Emergency" \
  --admin-lastname="Access"

7. dev:urn-catalog:generate und dev:tests:run

bin/magento dev:urn-catalog:generate .idea/misc.xml ist ein Hidden Gem, den viele Entwickler nie bewusst ausführen, obwohl er jeden Tag im Hintergrund hilft: Der Befehl erzeugt die URN-Zuordnungen für PhpStorm, damit XML-Dateien wie di.xml oder layout.xml korrekte Autovervollständigung und Schema-Validierung im Editor bekommen. Ohne diesen Katalog markiert PhpStorm gültige Magento-XML-Strukturen fälschlich als Fehler, was besonders nach dem Hinzufügen neuer Module oder nach einem Magento-Versionswechsel wieder aktuell werden sollte.

bin/magento dev:tests:run startet Unit- oder Integrationstests direkt über die Magento-CLI, ohne dass PHPUnit separat mit den richtigen Bootstrap-Pfaden konfiguriert werden muss. Für schnelle Regressionschecks während der Entwicklung eines eigenen Moduls ist das der unkomplizierteste Weg, einen einzelnen Testsuite-Typ laufen zu lassen, ohne die komplette CI-Pipeline anzustoßen.

# Regenerate URN mappings for PhpStorm XML autocompletion and validation
bin/magento dev:urn-catalog:generate .idea/misc.xml

# Run just the unit test suite through the Magento CLI wrapper
bin/magento dev:tests:run unit

# Run integration tests for a quick regression check
bin/magento dev:tests:run integration

8. queue:consumers:start und cron:run mit gezielten Gruppen

Message-Queue-Consumer laufen in der Produktion meist als Supervisor-verwaltete Dauerprozesse, aber für Debugging ist ein einzelner, begrenzter Lauf oft die bessere Wahl. bin/magento queue:consumers:start <consumer_name> --max-messages=50 --single-thread verarbeitet genau fünfzig Nachrichten und beendet sich danach selbst, statt endlos zu laufen. Das erlaubt es, einen Consumer gezielt mit einer begrenzten Nachrichtenmenge zu testen, ohne einen Dauerprozess manuell abbrechen zu müssen.

Ähnlich verhält es sich mit Cron-Gruppen: bin/magento cron:run --group=index führt ausschließlich die Cron-Jobs einer bestimmten Gruppe aus, etwa nur die Indexierungs-Jobs, statt aller in crontab.xml definierten Jobs auf einmal. Das ist besonders wertvoll, wenn ein einzelner Job in der Produktion Probleme macht und isoliert getestet werden soll, ohne Nebenwirkungen durch andere, unrelated Cron-Gruppen zu riskieren.

# Process exactly 50 messages from a queue consumer, then exit
bin/magento queue:consumers:start product_action_attribute.update --max-messages=50 --single-thread

# Run only the cron jobs belonging to the "index" group
bin/magento cron:run --group=index

# List all registered consumers before targeting one specifically
bin/magento queue:consumers:list

9. config:show, app:config:dump und config:sensitive:set

bin/magento config:show <path> liest einen einzelnen Konfigurationspfad direkt aus der aktiven Konfiguration aus, inklusive Scope-Überschreibungen, ohne den Admin-Bereich öffnen zu müssen. Das ist bei Deployment-Skripten oder bei der Fehlersuche in CI-Pipelines deutlich schneller als ein Login ins Backend. bin/magento app:config:dump exportiert die komplette Systemkonfiguration in versionierbare XML-Dateien unter app/etc/, ein zentraler Baustein für Deployments nach dem "Konfiguration im Code, Daten in der Datenbank"-Prinzip.

Für sensible Werte wie API-Keys oder Zahlungsanbieter-Zugangsdaten gibt es bin/magento config:sensitive:set <path> <value>, das diese Werte gezielt setzt, ohne sie in die versionierten Dump-Dateien zu schreiben. Diese drei Befehle zusammen bilden einen vollständigen Workflow für nachvollziehbare, aber trotzdem sichere Konfigurationsverwaltung über mehrere Umgebungen hinweg.

# Read a single config value directly, including scope overrides
bin/magento config:show web/secure/base_url

# Export the full system configuration as versionable XML files
bin/magento app:config:dump

# Set a sensitive value (API key, payment credentials) without dumping it to disk
bin/magento config:sensitive:set payment/braintree/private_key "sk_live_xxx"

Die folgende Übersicht fasst die wichtigsten Gegenüberstellungen aus diesem Artikel zusammen: der übliche, breite Weg im Vergleich zum präzisen Hidden-Gem-Befehl.

Diese Gegenüberstellung zeigt das Muster hinter allen Magento CLI Hidden Gems: Sie ersetzen breite, langsame oder riskante Standardaktionen durch präzise, gezielte Befehle. Der Zeitgewinn pro Einzelfall wirkt klein, summiert sich aber über ein Projektjahr zu spürbar reduzierter Diagnose- und Wartungszeit.

10. Zusammenfassung

Die Magento CLI Hidden Gems aus diesem Artikel lösen Probleme, die Standardbefehle gar nicht adressieren: dev:di:info zeigt die vollständige Plugin- und Preference-Kette einer Klasse, module:config:status deckt Inkonsistenzen vor einem setup:upgrade auf, indexer:set-mode und gezieltes indexer:reindex sparen Zeit bei großen Katalogen, maintenance:allow-ips ermöglicht kontrollierte Deployments ohne Komplettausfall, und admin:user:unlock löst Notfälle in Sekunden statt mit riskanten Direktzugriffen auf die Datenbank.

Der eigentliche Wert dieser Power-User-Befehle liegt darin, dass sie in Sekunden liefern, wofür sonst Codesuche, SQL-Abfragen oder ein kompletter Wartungsmodus nötig wären. Wer diese Befehle in den täglichen Workflow integriert, sei es beim Debugging eines Plugin-Konflikts, bei einem dringenden Admin-Zugriffsproblem oder bei einem kontrollierten Produktions-Deployment, gewinnt spürbar an Reaktionsgeschwindigkeit gegenüber Teams, die ausschließlich auf die bekannten Grundbefehle setzen.

11. FAQ: Magento CLI Hidden Gems