Magento CLI Hidden Gems: Power User Commands

1. Why standard CLI knowledge isn't enough on complex projects

Every Magento developer knows bin/magento setup:upgrade, cache:flush and indexer:reindex. These basic commands are enough for a freshly set up project, but they fail exactly where things get genuinely interesting: a plugin conflict between three third-party modules, a locked admin account during a client call, or a cron job that no longer runs reliably in production. This is where basic Magento CLI experience separates from real power user knowledge. The Magento CLI hidden gems in this article are commands that most beginner tutorials leave out, yet every agency uses several times a week.

What these power user commands have in common is that they drastically reduce diagnosis time. Instead of searching code to find out which plugins patch a method, a single command delivers the complete answer. Instead of running a SQL query against the admin_user table, a CLI command unlocks the account in one line. These CLI hidden gems aren't a replacement for foundational knowledge, but an extension that turns reactive debugging into proactive diagnosis. In the sections below we go through nine such commands in detail, with real use cases from the Mark Shust Docker setup that mironsoft.de uses for Magento 2.4.8 projects.

One important note up front: this project never calls php bin/magento directly, but always uses the bin/magento wrapper from the bin/ directory. That ensures the command runs in the correct container context, regardless of whether PHP is even installed locally. All examples below consistently use this wrapper convention.

2. dev:di:info: seeing a class's plugins and preferences instantly

Arguably the most useful of the CLI hidden gems is bin/magento dev:di:info. The command takes a fully qualified class name and lists which preference replaces that class, which plugins are registered on it and in what order, and whether it is a virtual type. Without this command, the only option is manually searching through every di.xml file in the vendor and app/code directories, which on a project with fifty or more installed modules can easily cost ten to fifteen minutes. With dev:di:info the answer is ready in under a second.

This command is especially valuable when a client reports that a price or a calculation "somehow looks wrong" without the developer knowing which modules are even involved at that point. Instead of guessing, you run dev:di:info against the affected class and immediately see the full interceptor chain including sortOrder. It is also the first step in any analysis of plugin sort order conflicts between multiple modules.

# 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"

Another use case: before creating a plugin of your own, it is always worth checking the target class with dev:di:info to see whether other modules already intervene there. This avoids sortOrder collisions from the outset instead of discovering them only after deployment once something breaks. This command belongs to the power user commands that every experienced Magento developer reflexively runs before any larger change to a core class.

3. module:config:status and module:status before every setup:upgrade

Most developers only know bin/magento module:status as a way to see which modules are active or disabled. As a hidden gem, the command is also worth running as a diagnostic tool directly BEFORE a setup:upgrade, especially after a Composer update with many new or updated packages. The command shows the actual module order, as computed from the sequence declarations of all module.xml files, and reveals whether a newly installed module ends up in an unexpected position in the load order.

bin/magento module:config:status complements this with a comparison between the module list stored in app/etc/config.php and the actual state on the filesystem. If the two diverge, for example because a module was removed via Composer but not cleanly disabled, the command reports that explicitly, instead of the next setup:upgrade failing with a cryptic error. Especially in multi-developer teams where several people add or remove modules in parallel, this check step prevents many of the classic "it works on my machine" situations.

# 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 and targeted reindexing of a single indexer

Most tutorials explain bin/magento indexer:reindex, which rebuilds all indexers indiscriminately. In a product catalog with several hundred thousand SKUs, that is rarely the right choice, since it takes needlessly long and temporarily increases system load. The power user command in this category is bin/magento indexer:reindex <indexer_id>, which recalculates exactly one specific indexer, for instance only the price index after a price rule change, without triggering the full category or search index alongside it.

Equally important is bin/magento indexer:show-mode, which shows for each indexer whether it runs in "update on save" or "update on schedule" mode. In production, schedule mode should practically always be active, so indexing runs in the background via cron jobs instead of blocking every single save action in the admin panel. The command bin/magento indexer:set-mode schedule <indexer_id> sets this mode specifically for individual indexers, which is helpful when a particular indexer should temporarily run synchronously for debugging reasons while all others remain in schedule mode.

# 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 practice these two commands get combined: indexer:show-mode as diagnosis, followed by a targeted indexer:reindex <id>, instead of reflexively recalculating every indexer. This precise control is one of the things that separates an experienced Magento developer from a beginner in production operations.

5. maintenance:allow-ips for controlled deployments

Maintenance mode, bin/magento maintenance:enable, is well known, but its most important companion command is often overlooked: bin/magento maintenance:allow-ips <IP addresses>. It lets you activate maintenance mode while certain IP addresses, for example the agency's office network or a client's IP, still have normal access to the shop. That is the difference between a complete blackout for all visitors and a controlled test window during an ongoing deployment.

bin/magento maintenance:status complements this by showing both the current maintenance state and the list of allowed IP addresses, which is particularly helpful when several developers are involved in a deployment and nobody remembers exactly who allowed which IP when. These hidden gems around maintenance mode turn a crude on/off tool into a precise instrument for controlled rollouts, especially during larger migrations or layout overhauls.

# 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 and admin:user:create for emergencies

A locked admin account in the middle of a client meeting is a classic stress test for every Magento developer. Instead of running a SQL query against the admin_user table and manually resetting the lock_expires field, bin/magento admin:user:unlock <username> solves the problem in a single line, without ever opening a database connection. This is one of the power user commands rarely found in tutorials because it's only needed in emergencies, but then it saves minutes instead of seconds of handling time.

bin/magento admin:user:create lets you create a new admin user entirely via CLI, including role, password and email address, without requiring an existing account to be functional. This is especially practical on a fresh staging or test environment when no admin access exists yet, or when the only remaining super admin account was accidentally deleted. Both commands together cover the most common admin access emergencies without any direct database access.

# 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 and dev:tests:run

bin/magento dev:urn-catalog:generate .idea/misc.xml is a hidden gem many developers never consciously run, even though it helps every single day in the background: the command generates the URN mappings for PhpStorm, giving XML files such as di.xml or layout.xml correct autocompletion and schema validation in the editor. Without this catalog, PhpStorm incorrectly flags valid Magento XML structures as errors, which should be regenerated especially after adding new modules or after a Magento version change.

bin/magento dev:tests:run starts unit or integration tests directly through the Magento CLI, without needing to configure PHPUnit separately with the correct bootstrap paths. For quick regression checks while developing a module of your own, this is the simplest way to run a single test suite type without triggering the entire CI pipeline.

# 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 and cron:run with targeted groups

Message queue consumers usually run in production as supervisor-managed long-running processes, but for debugging a single, bounded run is often the better choice. bin/magento queue:consumers:start <consumer_name> --max-messages=50 --single-thread processes exactly fifty messages and then terminates itself instead of running forever. This lets you test a consumer with a bounded message count without having to manually kill a long-running process.

Cron groups work similarly: bin/magento cron:run --group=index executes only the cron jobs of a specific group, for example just the indexing jobs, instead of all jobs defined in crontab.xml at once. This is particularly valuable when a single job causes problems in production and needs to be tested in isolation, without risking side effects from other, unrelated cron groups.

# 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 and config:sensitive:set

bin/magento config:show <path> reads a single configuration path directly from the active configuration, including scope overrides, without needing to open the admin area. This is noticeably faster than logging into the backend for deployment scripts or when troubleshooting CI pipelines. bin/magento app:config:dump exports the entire system configuration into version-controllable XML files under app/etc/, a central building block for deployments following the "configuration in code, data in the database" principle.

For sensitive values such as API keys or payment provider credentials there is bin/magento config:sensitive:set <path> <value>, which sets these values specifically without writing them into the versioned dump files. Together these three commands form a complete workflow for traceable yet secure configuration management across multiple environments.

# 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"

The overview below summarizes the key comparisons from this article: the usual, broad approach versus the precise hidden gem command.

This comparison shows the pattern behind every Magento CLI hidden gem: they replace broad, slow or risky default actions with precise, targeted commands. The time saved per individual case seems small, but adds up over a project year to noticeably reduced diagnosis and maintenance time.

10. Summary

The Magento CLI hidden gems in this article solve problems that standard commands don't address at all: dev:di:info shows the complete plugin and preference chain of a class, module:config:status exposes inconsistencies before a setup:upgrade, indexer:set-mode and targeted indexer:reindex save time on large catalogs, maintenance:allow-ips enables controlled deployments without a full outage, and admin:user:unlock resolves emergencies in seconds instead of risky direct database access.

The real value of these power user commands lies in delivering in seconds what would otherwise require code searches, SQL queries or a full maintenance mode. Anyone who integrates these commands into their daily workflow, whether debugging a plugin conflict, handling an urgent admin access problem, or running a controlled production deployment, gains noticeably in response speed compared to teams relying solely on the well-known basic commands.

11. FAQ: Magento CLI Hidden Gems