Joomla's debug console: find the slow query, the missing string and the broken plugin

When a Joomla page is slow, blank or simply wrong, most people start by disabling extensions one at a time. Joomla has a better tool built in: the debug console. It tells you which queries ran, how long each step of the page took, which language strings are missing and what ended up in the log. It costs two settings to switch on and one setting to keep it away from visitors.

Two switches in Global Configuration

Go to System > Global Configuration and open the System tab. Under Debug Settings you find:

• Debug System. Set to Yes, Joomla collects timing, memory and query data for every request and shows a full stack trace on the error page instead of a bare message.
• Debug Language. Set to Yes, every translated string on the page is wrapped in ** and every string without a translation in ??. It is the fastest way to find the untranslated label in a template override.

The third setting sits on the Server tab: Error Reporting. Set it to Maximum while you are debugging, so PHP warnings and deprecation notices actually reach the screen. Put it back to System Default or None when you are done.

The plugin that draws the bar

Debug System only collects. The bar at the bottom of the page comes from the System - Debug plugin, which is enabled on a fresh install. If you switch on debugging and see nothing, check that plugin first under System > Plugins.

Open the plugin and look at Allowed Groups. Leave it empty and every visitor sees your queries, file paths and session data. Select Super Users only, and you can debug on a live site while visitors see a normal page. This is the one setting that makes debugging on production acceptable, and it is also the one most people skip.

What the tabs tell you

Since Joomla 4 the console is built on PHP DebugBar. The tabs worth reading:

• Queries. Every database query, with its duration and the file that fired it. Sort by time to find the slow one. Look for the same query appearing dozens of times: that is a module or plugin running a query inside a loop, and no amount of caching config fixes it properly.
• Profile. Timing markers for each stage of the request: after initialise, after route, after dispatch, after render. If most of the time goes before routing, the problem is a system plugin. If it goes in dispatch, it is the component. If it goes in render, look at modules.
• Request and Session. What Joomla received and what it remembers about the current user. Useful when a form "forgets" values or a login does not stick.
• Language Strings and Language Files. Which INI files were loaded and which keys had no translation. Pair this with Debug Language when building overrides.
• Log. Messages that extensions write to Joomla's logger during this request, including deprecation warnings if you enable them in the plugin.

Deprecation logging before an upgrade

In the System - Debug plugin, the Logging tab has an option to log deprecated API calls. Turn it on for a few days before moving from Joomla 5 to 6. Every time an extension calls a method that will disappear, Joomla writes a line to deprecated.php in the log folder (by default administrator/logs). That file gives you a list of extensions to update or replace before the upgrade breaks them, rather than after.

When the backend is the thing that is broken

A white screen in the administrator means you cannot reach Global Configuration. Open configuration.php in the site root via FTP or your host's file manager and change two lines:

public $debug = true;
public $error_reporting = 'maximum';

Reload the page and the white screen usually turns into an error with a file name and line number. That line almost always points into a plugin or template folder, which tells you what to rename to get back in. Read how to disable a plugin without backend access for that step.

Switch it off again

Debug mode adds work to every request. Even with Allowed Groups set, Joomla still collects the data, so a busy site gets slower. Note in your own changelog when you turned it on, and set Debug System, Debug Language and Error Reporting back once the problem is found. Leaving a stack trace on a public error page also hands an attacker your server paths and extension list for free.