Joomla System Information, Maintenance and Troubleshooting: Check-in, Cache, Database Fix, Warnings, Debug and Logs

This content was generated with the assistance of AI and should be verified against the official Joomla documentation before being relied on in production.

This sub-section’s Joomla bibliography lists the reference material consulted while preparing these pages.

This page describes the System menu tools of the Joomla administrator and the standard troubleshooting routine as they were on 2026-10-30, the date on which the facts were checked against the Joomla! User Guide (https://guide.joomla.org/) and the 6.2-dev source tree of the CMS. It was written against Joomla 6.2.x (PHP 8.3 or later); the tools are the same in the 5.4 security-only line unless a version is named. The running example is the Tallpine Hiking Club site, whose editors report that a trail report cannot be saved, whose Friday-afternoon traffic exposes a stale page cache, and whose only Super User once went on holiday with the authenticator app.

The User Guide describes only a few of these screens (its System section covers Backup, Cache and expired-cache purging), so most of the detail below comes from the source of the components that implement them. The legacy wiki at docs.joomla.org still carries older descriptions of these screens; where its text differs from the Guide or the source, prefer the latter.

Site builders and administrators use these screens daily; developers use them to prove that an extension install or update left the database in the expected state. Editors only see the symptom: an article that stays locked or a page that does not refresh.

Where the tools live

In Joomla 4 and later the former Tools and Information menus were regrouped under System. The System dashboard (https://guide.joomla.org/user-guide/dashboards/dashboards-system-dashboard) shows panels named Setup, Install, Templates, Maintenance, Manage, Information, Update and User Permissions. The items on this page are defined in the menu preset of com_menus and open these components:

Menu path Component and view Purpose

System › Maintenance › Clear Cache

com_cache

Delete cache groups, or only the expired entries

System › Maintenance › Database

com_installer, view database

Compare the database schema with the extension SQL update files and repair it

System › Maintenance › Global Check-in

com_checkin

Release locked ("checked out") items across all tables

System › Information › System Information

com_admin, view sysinfo

Read-only report on PHP, the configuration, folders and installed extensions

System › Information › Warnings

com_installer, view warnings

PHP and folder settings that will make extension installation fail

Access to each screen is an ACL permission: the component’s Options › Permissions decide which groups can open it, so a custom Administrator group can be given Clear Cache and Global Check-in without receiving System Information. See users, groups, access levels and ACL.

flowchart TD S[Symptom on the Tallpine site] --> Q{What do you see?} Q -->|HTTP 500 or blank page| E[Turn on Error Reporting and read administrator/logs] Q -->|Edit does not appear| C[Clear Cache and check Page Cache plugin] Q -->|Item stays locked| K[Global Check-in] Q -->|Install or update failed| W[Warnings, then Database Update Structure] Q -->|Template message in a red box| T[Template styles and templates folder] Q -->|Cannot log in as Super User| R[CLI user commands or database repair] E --> D[Debug System and Debug Language] D --> F[Fix cause, then reset Error Reporting and Debug to off]

System Information

System › Information › System Information (index.php?option=com_admin&view=sysinfo) has five tabs: System Information, PHP Settings, Configuration File, Directory Permissions and PHP Information. The model behind it, SysinfoModel, builds each tab on demand and removes private values before showing them.

System Information tab

The first tab shows the Joomla version, the state of the backward-compatibility plugin used for upgrades, the PHP version, the operating system string (php_uname()), the web server software, the PHP server API (for example fpm-fcgi or apache2handler) and the visitor’s user agent. The database block lists the server type and version, the database collation, the connection collation and whether the connection supports encryption. Compare these with the requirements in requirements and hosting before reporting a bug: most support requests that begin with "it worked on my machine" end here.

PHP Settings tab

The PHP Settings tab reads a fixed list of directives and shows each one next to the value Joomla recommends. The list contains memory_limit, upload_max_filesize, post_max_size, display_errors, short_open_tag, file_uploads, output_buffering, open_basedir, session.save_path, session.auto_start, disable_functions and max_input_vars, followed by whether the extensions xml, zlib, zip, mbstring, fileinfo, gd, iconv and intl are loaded.

Pitfalls the Tallpine administrators met:

  • upload_max_filesize and post_max_size limit the GPX files uploaded through the Media Manager and the size of an extension package; post_max_size must be at least as large as upload_max_filesize.

  • max_input_vars (default 1000 in PHP) silently truncates large forms: saving a menu item or a template style with many parameters can lose the last fields without an error. Raise it to 3000 or more on sites with big forms.

  • disable_functions that lists phpinfo makes the PHP Information tab show a "disabled" message instead of output. That is harmless for the site.

  • display_errors should be off in production (see Error Reporting, Debug System and Debug Language).

Configuration File tab

This tab prints the values of configuration.php as an array, so a support person can read the active settings without file access. Credentials and secrets are replaced with xxxxxx: the database host, user and password, FTP and SMTP credentials, Redis and proxy credentials and the secret. The same masking is applied again to the data that the Copy button produces. Even so, treat a screenshot of this tab as semi-sensitive because paths and the database name can be derived from nearby tabs. The file itself is explained in configuration.php and .htaccess.

Directory Permissions tab

The Directory Permissions tab calls is_writable() on a fixed list of paths and shows a Writable or Unwritable flag. The list includes the component, module, template, language and manifest folders of both the site and the administrator, the plugin group folders, libraries, media, the images and files folders and their subfolders, configuration.php, the cache folders (administrator/cache or the configured cache path, and media/cache) and the log and temporary folders.

Key facts for fixing permissions:

  • The result is the permission seen by the PHP user, not by the person who uploaded the files. On a server where the files belong to deploy but PHP runs as www-data, the tab marks almost everything unwritable even though the site works.

  • Only the paths Joomla must write to need to be writable at runtime: the cache folders, the log folder, the temporary folder, the images folder (for the Media Manager) and, while installing or updating extensions through the administrator, the extension folders. Locking the code folders read-only and updating through a deployment pipeline is a legitimate hardening choice (see security hardening, MFA and passkeys); the tab then reports those folders as unwritable on purpose.

  • The usual recommendation is 755 for directories and 644 for files, never 777. configuration.php may be tightened to 444 once the site is configured; the tab then flags it, and Global Configuration cannot save until the permission is relaxed again.

  • The log and temporary folders are shown with the paths configured in Global Configuration (log_path, tmp_path), which default to administrator/logs and tmp. A read-only container file system (see local development with Docker) needs named volumes for exactly these paths and for images.

PHP Information tab

This tab shows a cleaned phpinfo() page. Values such as DOCUMENT_ROOT, PATH, HTTP_HOST, REMOTE_ADDR, SERVER_ADMIN, session.save_path, sendmail_path and open_basedir are replaced with xxxxxx before display. The tab is useful for confirming that OPcache, Redis or Imagick are loaded in the web SAPI rather than only in the CLI, which uses a separate php.ini.

Warnings

System › Information › Warnings (com_installer, view warnings) checks the environment that extension installation and updates depend on. It reports, with an explanatory text for each: file uploads disabled in php.ini; a PHP upload folder that is not set or is not writable; the Joomla temporary folder not set or not writable; a low or medium memory_limit; an upload size larger than the POST size; and a POST or upload size that is too small for typical extension packages. If the screen is empty, the environment is acceptable for installs.

The Warnings view is the first place to look when Extensions › Install fails with "There was an error uploading this file to the server" or when the update page cannot download a package. Fix the setting in php.ini or the pool configuration, restart PHP-FPM, and reload the page. Later sections on extension installation are in installing, updating and update sites.

Global Check-in

Joomla locks an item while somebody edits it: the row gets the editor’s user ID in checked_out and a timestamp in checked_out_time. Leaving the form with Close releases the lock. Closing the browser tab, losing the connection or a PHP crash leaves the row locked and the item shows a padlock in the list, which only the locking user or a user with the Check-in permission can release.

System › Maintenance › Global Check-in (com_checkin) lists every table of the site that has locked rows. How the list is built:

  1. the model lists all database tables and keeps only those whose name starts with the configured dbprefix (a case-insensitive comparison, so other applications sharing the database are ignored)

  2. it keeps only tables that have both the checked_out and the checked_out_time columns, which includes third-party tables such as a component’s own trail table

  3. for each table it counts rows where checked_out is greater than zero and shows the count in the Items to check-in column

Select the tables and press Check-in. Joomla runs an UPDATE that resets checked_out to its default and checked_out_time to NULL (or the null date for older schemas), only on rows that were locked, and fires the onAfterCheckin event per table. The message reads "N items checked in". A quick-icon on the System dashboard shows how many tables have locked items.

Practical advice:

  • Check in a table only when you know the editor is gone. Checking in an article while somebody still edits it lets a second person start editing, and the later save silently wins.

  • The Options of Global Check-in set which groups can use it, as for any component.

  • Developers must call checkIn() after a save or cancel in custom tables that use the checked_out columns, and checkOut() when opening the edit form; otherwise their items either never lock or never unlock.

  • A scheduled task cannot be relied on to release locks, because a lock may be legitimately in progress.

The Tallpine editor who lost her connection while writing the Mount Pilatus trail report fixed the padlock by opening Global Check-in, ticking #__content and pressing Check-in.

Clear Cache

System › Maintenance › Clear Cache (com_cache) shows one row per cache group with the number of files and their size. The Joomla! User Guide (https://guide.joomla.org/user-guide/system/system-cache) explains that, to clear page-cache entries, you tick the group named page and press Delete, and that editing an article does not clear the page cache automatically.

There are two toolbar actions:

  • Delete removes the selected groups entirely

  • Clear Expired Cache (purge task) calls the cache handler’s garbage collection and removes only entries whose lifetime has passed

Rules that explain most "my change does not show" reports:

  • The page cache applies only to guests and only when the System - Page Cache plugin is enabled. Members of the Trail Warden group never see cached pages, so they cannot reproduce what a guest sees.

  • Global Configuration › System › Cache Settings has three values for System Cache: Off, On - Conservative and On - Progressive. Cache time is in minutes globally and in seconds in a module’s own advanced settings.

  • With the Redis, Memcached or APCu handlers, Clear Cache clears the entries through the handler, so it also works for a shared cache (see Redis administration for the server side). The grouping on this screen is a Joomla concept, not a Redis one.

  • Clearing the cache does not clear the OPcache of PHP, the browser cache or a CDN; those are covered in caching and performance.

  • The Web Asset Manager versions assets with a hash of the file; after changing a CSS file, a stale browser copy is normally refreshed by the new ? version parameter, not by this screen.

The CLI equivalent is cache:clean, which accepts the optional argument expired to clear only expired entries:

# Inside the Tallpine container or on the server, from the Joomla root
php cli/joomla.php cache:clean
php cli/joomla.php cache:clean expired

Source: Joomla User Guide: Cache

Database

System › Maintenance › Database (com_installer, view database) is a schema checker. It exists because the database structure is created and modified by SQL files shipped inside each extension, and a failed or partial update can leave the tables out of step with the code.

For every extension that has a row in #__schemas the page runs these checks:

  • schema version: the version recorded in #__schemas is compared with the newest SQL update file in the extension’s sql/updates folder; a mismatch is reported

  • update version: the version stored in the extension’s manifest_cache (in #__extensions) is compared with the installed version, which for the core is the JVERSION constant

  • structure problems: a change set built from the update files is checked against the real tables, so a missing column, a wrong type or a missing index appears as a problem line with the offending query

  • text filters: for the core component, the page also checks the legacy text-filter settings carried from very old versions

The result is a count such as "No Problems" or "N Problems", plus "N database changes were checked" and a count of changes skipped because they do not alter table structure. Select the problem extensions and press Update Structure (the Fix action). It re-applies the missing structural changes, rewrites the schema version row and the manifest version, and, for the core, removes files that should no longer exist and repairs default text filters.

Operational rules:

  • Take a database backup first (see backups and recovery). Update Structure alters tables.

  • Run it after a failed update, after restoring files from one version over a database of another, and after a manual upgrade by overwriting files.

  • It repairs structure, not data. A table that was never created by a vendor SQL file (for example a custom table created from a plugin at run time) is not known to it.

  • On MySQL and MariaDB the page reflects the SQL files shipped for that database; PostgreSQL has its own set. Joomla does not support moving between the two, nor downgrading.

  • The automatic update flow described in updating Joomla runs the same SQL files and ends with the same schema record.

For the Tallpine package, pkg_tallpine ships sql/updates/mysql/1.2.0.sql for com_tallpine; after an interrupted update the Database page shows com_tallpine with one problem, and Update Structure applies the missing column.

Source: Joomla CMS source: DatabaseModel

Error Reporting, Debug System and Debug Language

Global Configuration has three settings that govern diagnostics (see Global Configuration):

Setting Where Effect

Error Reporting

Server tab

default (the server’s PHP setting), none, simple or maximum (all PHP errors including notices)

Debug System

System tab › Debug

Enables the debug plugin’s console and keeps log entries at every level

Debug Language

System tab › Debug

Marks every translated string and shows a list of untranslated or erroring language strings

Log Almost Everything, Log Deprecated API, Path to Log Folder

System tab › Logging

Controls which log files are written and where

These are stored in configuration.php as $error_reporting, $debug, $debug_lang, $log_everything, $log_deprecated and $log_path. When the administrator cannot load, set them there by hand:

<?php
// configuration.php: temporary diagnostics for the Tallpine staging site
public $error_reporting = 'maximum';
public $debug           = true;
public $debug_lang      = false;
public $log_everything  = true;
public $log_path        = '/var/www/html/administrator/logs';

Source: Joomla User Guide: Global Configuration

Production rules:

  • Leave error_reporting at default or none and display_errors off on a public site. Error messages reveal file paths and query text.

  • Turn Debug System on only for the time needed. It adds memory and time overhead, writes more logs and, unless restricted, shows the console to every visitor.

  • Do not leave maximum on in production, because deprecation notices of third-party extensions then flood the logs.

The System - Debug plugin

Debug System alone does nothing visible: the System - Debug plugin (Extensions › Plugins) draws the debug console at the bottom of the page. Its options are in three tabs:

Option group Fields (name, default)

Basic

filter_groups (Allowed Groups, none), refresh_assets (on), memory, request, session, profile and queries (on), query_traces, query_profiles, query_explains and track_request_history (off)

Language

language_errorfiles, language_files, language_strings and strip-first (on), strip-prefix and strip-suffix (empty)

Logging

logs (on), log-deprecated-core (off)

The security-relevant option is Allowed Groups. When it is empty the console is rendered for every visitor; when groups are chosen, only members of them see it. Always select Super Users on a site that is reachable from the internet; the console exposes queries, session data, request data and file paths. Refresh assets makes the Web Asset Manager re-evaluate files so CSS and JavaScript changes appear without clearing the cache.

The query tabs are the tool for finding slow pages: the number of queries and their time, EXPLAIN output for each select when Query Explains is on, and the PHP call stack when Query Traces is on.

Debug Language

With Debug Language on, strings passed through the language layer are visibly marked, so a string that comes from a language file can be told apart from hard-coded text, and untranslated text is shown with its key. The Language section of the console lists the language files loaded, the files that failed to load and the strings requested but not found. Use it for a missing translation on the German version of the Tallpine site and for finding which template override uses a wrong key. The Language Display setting changes how keys are shown. See multilingual sites.

Source: Joomla CMS source: System - Debug plugin manifest

More on the development use of the console, the Joomla 6 exception style and legacy APIs: see debugging and error handling and legacy APIs.

Logs

The folder administrator/logs (or the Path to Log Folder in Global Configuration) receives Joomla’s text files. The application sets up its loggers on every request:

File Content

joomla_core_errors.php

System-category messages. Only error, critical, alert and emergency levels while Debug System is off; every level when it is on

deprecated.php

Deprecated API calls, written when Log Deprecated API is on

everything.php

Almost all categories and levels, written when Log Almost Everything is on. Deprecation and database-query categories are excluded and go to their own logs

Other file names

Created by extensions that register their own logger, and by the Custom logging options (categories and priorities) in Global Configuration

Notes:

  • The files are PHP files whose first line is a comment guard, so a request for them over HTTP produces no output. On Nginx the folder must still not be exposed in a way that skips PHP processing; the sensible rule is that the log folder belongs outside the web root. Set $log_path in configuration.php to a folder next to the public folder (see installation and the public folder).

  • Messages contain request details. Rotate and delete them; the privacy rules in privacy and action logs apply to data they may contain. The System - Log rotation plugin rotates the files.

  • The Action Logs (User Actions Log) is a database table of editor actions and is a different feature from these log files.

  • In containers send logs to stdout by mounting the folder as a volume or use a syslog logger; see Docker logging and monitoring and Kubernetes debugging and troubleshooting.

  • The PHP error log and the web-server error log (error.log of Apache or Nginx, the PHP-FPM log) are outside Joomla and contain the fatal errors Joomla cannot catch, such as memory exhaustion.

Reading a log from the CLI:

# Show the last errors of the Tallpine site
tail -n 50 administrator/logs/joomla_core_errors.php
# Follow everything while reproducing a problem
tail -f administrator/logs/everything.php

Source: Joomla CMS source: CMSApplication logging set-up

Common errors and fixes

HTTP 500 and the blank page

Both mean that PHP failed before it could produce HTML. A blank page (white screen) happens when display_errors is off and the failure is fatal. A 500 happens when the web server turns the fatal error into a status code.

  1. Open the web server and PHP-FPM error logs and administrator/logs/joomla_core_errors.php. Most often it contains a fatal error with a file and line.

  2. If nothing is logged, set $error_reporting = 'maximum'; in configuration.php, reload, and revert afterward.

  3. Typical causes: a PHP version that the installed extension does not support after a host upgrade; a memory limit that is too small (Allowed memory size exhausted); a broken .htaccess (on Apache a 500 on every URL; rename it and retest, see configuration.php and .htaccess); an extension file uploaded halfway; a plugin with a fatal error that breaks every request (rename its folder in plugins/<group>/ or disable it in #__extensions with enabled = 0); a database connection failure reported as "Error displaying the error page".

  4. An error that appears only on the administrator side usually points at an administrator plugin or the administrator template; one that appears only on the site points at the site template, a module or a content plugin.

  5. Joomla 6 removed deprecated classes (JFactory aliases and others) from the default code path; an old extension that fatals on a missing class needs the Behaviour - Backward Compatibility 6 plugin or, better, an update. See upgrading Joomla 5 to 6 and deprecations and preparing for Joomla 7.

"The template for this display is not available"

The message is the language string JERROR_ALERTNOTEMPLATE: "The template for this display is not available. Please contact a website administrator." The site application raises it in getTemplate() when the template chosen for the request, through the active menu item’s template style or the default style, is not valid. In the 6.2 source it then looks for the cassiopeia template as fallback; if even that is missing, an InvalidArgumentException stops the request with a message that it could not find the template.

Common reasons and fixes:

  • The template folder was deleted or renamed, for example cassiopeia_tallpine was removed from templates/ while a template style still pointed at it. Restore the folder from the backup or the package.

  • The folder exists, but index.php is missing or the template’s templateDetails.xml is invalid after a bad upload. Re-upload the template from its package.

  • The menu item is assigned to a template style whose template was uninstalled. In System › Site Template Styles assign an existing default style, or set the Home style as default.

  • A child template whose parent template is not installed. See templates and template styles and Cassiopeia and Cassiopeia Extended.

  • After clearing the database of the #__template_styles rows by hand. Reinstall or re-discover the template.

Because the message is enqueued as an error and the page still renders with the fallback, the admin sees it on the site but the administrator is unaffected. Do not confuse it with Layout %s not found, the message for a missing layout file inside a template or override.

"Layout not found" and "View not found"

Layout <name> not found. (HTTP 500) is thrown when a layout file named by a menu item or a template override does not exist. Remove the stale override in System › Template Overrides, or restore the file. View not found [name, type, prefix] means the component’s view class cannot be located, usually a namespace or folder-case mismatch after a rename on a case-insensitive development machine and deployment to Linux.

Component not found, 404 and 403

"Component not found" (404) points to a disabled or uninstalled component named by a menu item. A 403 "You don’t have permission to access this" is an ACL decision: see the access level of the menu item and the user’s groups. Neither is repaired from the System menu.

"Locked out" after an update or a stuck update

If Joomla Update stops with a half-finished state, run Database › Update Structure and clear the cache. If the administrator shows the maintenance error "Down for maintenance", set $offline = false; in configuration.php, or run the site-up command:

php cli/joomla.php site:up

Source: Joomla CMS source: console commands

Lost Super User access

Three situations are common, and each has a supported fix. Take a database backup first.

1. The password is lost, but the account is intact. Use the Forgot your password? link on the login page if mail works. Otherwise reset it from the CLI:

php cli/joomla.php user:list
php cli/joomla.php user:reset-password --username=tallpine-admin

Source: Joomla source: ListUserCommand.php and ChangeUserPasswordCommand.php

The command prompts for the new password when --password is omitted; do not put a real password on the command line, because it ends up in the shell history.

2. The account was blocked, deleted or demoted. Create a new Super User, or add the existing user to the group:

php cli/joomla.php user:add --username=recovery --name="Recovery admin" \
  --email=recovery@tallpine.example.org --usergroup="Super Users"
php cli/joomla.php user:addtogroup --username=tallpine-admin --group="Super Users"

Source: Joomla User Guide: Using the CLI

The user:add command prompts for any missing option (including the password with hidden input), resolves each group title to its ID in #__usergroups and fails on an unknown group, a duplicate username or a duplicate email. After the recovery, delete the recovery user with user:delete --username=recovery and review the Action Logs to learn who changed the groups.

3. No shell access. With a database tool, find the user in #__users, set block to 0 and requireReset to 0, and make sure #__user_usergroup_map has a row for that user_id and the group ID of Super Users (8 on a standard install, but read it from #__usergroups). To set a password, generate a bcrypt hash and place it in the password column:

php -r 'echo password_hash(getenv("NEW_PASSWORD"), PASSWORD_BCRYPT), PHP_EOL;'

Source: PHP manual: password_hash

Joomla verifies the hash with password_verify(), so a bcrypt hash created this way works. Older MD5 hashes from very old sites are rehashed at the next login. Do not paste the hash into an issue tracker or chat.

4. The Super User is locked out by multi-factor authentication. Use one of the backup codes shown when MFA was set up. Without them an administrator with database access can remove the user’s rows from the #__user_mfa table, which resets the user to "no MFA"; the MFA enforcement of the Multi-factor Authentication plugins then asks the user to enrol again. Plan for this by giving at least two people Super User rights and recording the recovery procedure; see security hardening, MFA and passkeys.

Because the User Guide’s own advice is to rebuild from clean backups after a compromise, treat unexplained loss of access as a possible intrusion: check #__users for accounts you do not know, read the Action Logs and replace the secret in configuration.php if it may have leaked.

Other frequent problems

  • "Session expired" or being logged out repeatedly: wrong cookie_domain/HTTPS settings behind a proxy (see configuration.php and .htaccess), session handler problems or a full tmp folder.

  • Cannot save an article, changes lost: max_input_vars or post_max_size, a locked item, a content plugin that throws, or a page cache hiding the result.

  • Update available but not offered: update channel and stability settings, covered in updating Joomla.

  • Slow site: Debug System’s query list, then caching and performance.

A repeatable routine for the Tallpine site

  1. Reproduce the problem and note the exact URL, user and time.

  2. Check Warnings and System Information for an environment cause.

  3. Read administrator/logs and the server logs around that time.

  4. Turn on Error Reporting maximum and Debug System for Super Users only; reproduce again.

  5. Apply the fix; run Database › Update Structure if an update was involved; Global Check-in if locks remain; Clear Cache last.

  6. Turn Debug System, Debug Language and Error Reporting back off, and delete or archive the debug logs.

  7. Record the cause in the site’s runbook and, for recurring causes, add a monitoring check.

Older books and tutorials

Older tutorials and the Joomla! 3 wiki describe the Tools menu, the Global Check-in location under System › Global Check-in and the Information menu (Database Fix as part of the Extensions Manager). In Joomla 4 and later, the items live under System › Maintenance and System › Information as in the table above, and the Fix button is labelled Update Structure. The 2023 books Developing Extensions for Joomla! 5 and Joomla! 4 Masterclass cover the screens as they existed in 4.x and 5.0; the 5.1 and later changes (TUF-verified core updates, Automated Core Updates, the Backward Compatibility 6 plugin and the 6.0 removals) are missing from them and are the usual source of errors on 5.4/6.x sites. Both books target platform lines that are now end of life or security-only (Joomla 5.x security fixes run until 2027-10-12), so confirm every procedure against the current Guide and the source.

Joomla ships no backup or multisite tool in core; backup plugins such as Akeeba Backup are third-party and are covered as ecosystem in backups and recovery. For the CLI tools used above, see the command-line interface.

References