QuickDevBar: a debug toolbar for Magento 2 that reads the request from the inside

Nine panels, and the question each one is built to answer

QuickDevBar is a developer toolbar for Magento 2, and the way it is put together is stated plainly in the project documentation: the structure is extremely simple, and you just need to add a new block in the layout to get your tab running.

That single sentence tells you what kind of tool this is. The panels are layout blocks, added to a layout XML the way any other Magento block is, which means adding a tab is the same operation as adding any other piece of the page and needs no plugin, no observer and no event wiring.

The panels are where the value sits. Info gives the main information about the controller, the route, the action and the store, with a search on core config data and a dedicated tab output for local and global phpinfo. Design lists the handles that were called and displays the layout structure of nested blocks and containers. Profile shows the current observers, all events dispatched, collections and models loaded, plugins instantiated, preferences, and cache hits. Queries gives statistics about executed queries plus a detailed listing with syntax highlighting for the main SQL keywords. Logs displays the log files and can reset them. Dump catches every dump() call in the code and identifies inline JavaScript that is not compliant with CSP. Actions toggles template hints and inline translation and flushes the cache. Translation shows module, pack, theme and database translations. Help gives the module version and a link to the project.

The Profile panel is the one that separates this from a template-hint toggle. Template hints tell you which template rendered a block. Profile tells you what the request actually did, and for a Magento problem that is usually the question you were about to ask.

A screenshot of a theme chooser is included as well, so the toolbar can switch between a light and a dark presentation.

The overhead is controlled, and the profiler is opt-in

A toolbar that runs on every request has to be careful, and the project documentation is explicit about the two controls that matter.

Functionalities like VarDumper are unforced, and the SQL profiler backtrace is only on demand. That is a sensible split. A variable dumper that fires on every request changes the timing of the page you are trying to measure, and a full backtrace for every executed query is expensive in a way that has to be deliberate.

The module also states that it is compatible with the full page cache and follows the coding standard, and that with the vanilla JavaScript refactoring comes compatibility with Hyvä and Breeze themes. Those two points are about the environment a modern Magento 2 store actually runs in: a store on a JavaScript-rendered front end does not have the server-rendered block structure the older toolbar designs assumed, and a store with full page cache enabled would otherwise show a cached page with none of the debug information on it.

The supported range is Magento 2.4.x up to 2.4.8, with the note that it should work with lower versions, and the project points at composer.json for the other requirements.

The current release is 0.4.0, published on 2026-05-19, which is also the date of the last push to the repository. Before it come 0.3.4 from 2025-07-18 and 0.3.3 from 2025-06-10, so the gap between the two most recent releases is about ten months and the one before that was a month. A changelog lives in the repository at doc/Changelog.md, which is where you would look to see what a given release changed.

Installing it three ways, with Composer as the one that keeps it out of production

There are three installation paths in the documentation, and they differ in more than mechanics.

The manual route is to download the zip of the last version from the release tab, extract the files into the Magento root under app/code/ADM/QuickDevBar, enable the extension and upgrade the setup:

php bin/magento --clear-static-content module:enable ADM_QuickDevBar
php bin/magento setup:upgrade

The Composer route is the one to prefer in a team, because it declares the module as a development dependency and therefore keeps it out of a production install:

composer require vpietri/adm-quickdevbar --dev
php bin/magento module:enable ADM_QuickDevBar
php bin/magento setup:upgrade

The third route is Modman, which clones the repository into your module directory:

modman clone [email protected]:vpietri/magento2-developer-quickdevbar.git
php bin/magento module:enable ADM_QuickDevBar
php bin/magento setup:upgrade

The module identifier ADM_QuickDevBar follows from the namespace, and the file layout in the repository is the standard Magento module shape: Api/, Block/, Console/, Controller/, Helper/, Model/, Observer/, Plugin/, Profiler/, Service/, view/, etc/, a registration.php, a composer.json and a modman file. The presence of both Console/ and Observer/ tells you the module ships a command, which is the next thing worth looking at.

The tree also holds a doc/ directory with the changelog and the panel screenshots, and a .codeclimate.yml configuration with a matching maintainability badge in the documentation, which means code quality is measured for this project as well as for the code it inspects.

Turning it on, and the two configuration fields that decide who sees it

The activation logic is the part of this module with a real security dimension, so it is worth reading exactly.

The toolbar is displayed by default if your web server is on your local development environment. On a shared host, a container, or a remote development box, that condition is not met, and you can force activation from the command line:

php bin/magento dev:quickdevbar:enable

and to activate the full SQL backtrace as well:

php bin/magento dev:quickdevbar:enable --sql-profiler

The alternative is the standard configuration in the Advanced, Developer, Quick dev bar section of the Magento admin configuration.

If the toolbar does not appear, the documentation gives the reason and the fix. You either force activation by filling in your IP in the Allowed IPs field, and fill in a matching pattern of your user agent in the Allowed user-agent pattern field if it is needed.

Those two fields are the whole access control model. There is no role check and no per-user configuration; a client whose IP matches and whose user agent matches the pattern sees the toolbar. That is a coarse filter rather than an authorisation system, and it is the right thing to know before you enable the module on a box that is reachable from a network you do not control, because the toolbar exposes the request, the SQL, the configuration values and the log files of a store. The SQL backtrace in particular is a full stack trace per query, which is useful to you and expensive to compute.

The documentation notes that the URI file to IDE feature, which lets you open a file in PhpStorm through IDE Remote Control, is in beta.

Extending it, and the project compared with what Magento already ships

The extension story has an odd history, and it is documented rather than hidden.

The documentation lists a sample module for adding your own tabs, a separate project called magento2-brandnew_quikdevsample, with the entry struck through and annotated with a note that a refactoring is coming. So the sample module for extending the toolbar is currently marked as being reworked. In practice, the mechanism is the layout block one, so a new tab is a block and a layout update rather than anything the sample module would have taught you.

Set against this, Magento 2 ships its own developer modes. The setup:di:compile and cache commands, the template hints and the developer mode configuration in the admin panel, and the built-in profiler are all standard parts of the platform, and none of them require an extension.

The difference is in kind rather than degree. The built-in tools answer questions about compilation, caching and the current mode. QuickDevBar answers questions about a single request: which layout handles fired, which observers were attached, which events were dispatched, which collections and models were loaded, which plugins were instantiated, which preferences were touched, and which queries ran. None of that is exposed by the platform's own developer mode, and getting it by hand means reading the generated code and the debug log.

There is also a second axis of comparison, which is the commercial profiler extensions for Magento that exist for the same reason. The project documentation does not name them, so the comparison cannot be made from the project side, but the structural point stands: a free community module that covers the request-inspection half and leaves the profiling half to paid tools is a different proposition from either of those.

One credit is given in the documentation, to Jens Törnell, and the sponsor section invites companies to add their logo to the GitHub Sponsors page, with Sansec.io shown as an example.

Where QuickDevBar is the wrong tool

The first limit is the licence, and for a module that sits inside a store's own codebase it is an unusual thing to have to think about. The licence field in the repository metadata says unknown, which means there is no declared licence in the standard position for the tooling to detect, so a team shipping a customised version of the module has no clear grant to rely on. That is worth resolving with the author before you fork it into a client project.

The second is the access model, already described. The Allowed IPs and Allowed user-agent pattern fields are a filter, not permissions, and the module exposes request details, SQL, configuration and logs to anyone who matches them. On a shared or reachable environment, that is a real exposure, and the tool is a development aid rather than something to enable on a live store.

The third is the Magento version range. Support is stated for 2.4.x up to 2.4.8, and the extension is described as compatible with Hyvä and Breeze themes, which are the JavaScript-rendered front ends. A store on a customised or heavily forked theme may find that some panels render oddly, since a theme that changes the layout structure is exactly the case the design-panel output depends on.

The fourth is the extension path, which is currently in the middle of a refactoring. The sample module for custom tabs is marked as reworked, so a team that wanted to add a project-specific tab is building against an interface that is in motion.

And the fifth is the base of comparison. If your problem is that a page is slow rather than that a page is puzzling, a per-request debug toolbar is the wrong instrument, and the module's own profile panel, its SQL statistics and its cache hit counts are a starting point for that investigation rather than an answer to it.

Editorial conclusion

QuickDevBar is worth installing in a Magento 2 development environment because the panels answer the questions that Magento's own setup commands do not, such as which layout handles fired, which observers are attached, which queries ran and which translations exist, and because it installs as a development-only Composer dependency that stays out of production. It is the wrong tool for a store you do not control, and it is the wrong tool if you need the toolbar on a live environment. Before you install it, check three things: that you are on Magento 2.4.x up to 2.4.8, which is the supported range, and that the module code lives under app/code/ADM/QuickDevBar so the module identifier ADM_QuickDevBar resolves; that the toolbar only appears by default when your web server is on your local development environment, and that on a shared or remote server you have to fill in the Allowed IPs field and the Allowed user-agent pattern in the Advanced, Developer, Quick dev bar configuration section; and that the licence is not declared, since the licence field in the repository metadata says unknown, so check the terms in the repository before you redistribute the module.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. vpietri/magento2-developer-quickdevbar on GitHub