Administrator Tour: Dashboards and Guided Tours
|
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 Joomla administrator interface as it was on 2026-10-30, the date on which its facts were checked against the official documentation. It was written against Joomla 6.2.x (the current release; PHP 8.3 or later), and the screens described here are the same in the 5.4 security-only line. The Guided Tours component has been part of Joomla since 4.3, whose release announcement lists it as a feature that helps new users through administrative tasks. The Joomla! User Guide (https://guide.joomla.org/) is the end-user documentation that replaced most of the legacy wiki, and the Joomla! Developer Manual (https://manual.joomla.org/docs/) is the developer reference. Where the Manual describes a topic only briefly, this page also cites the source tree.
The running example is the Tallpine Hiking Club, a fictitious mountain club whose volunteers write trail reports. The site builder logs in to the administrator once to set the site up; the editors come back every week to publish a report. This page follows both: how the interface is organised, and how to make it teach the editors their own workflow.
Two applications, one installation
A Joomla installation contains two web applications that share the same database, the same extensions and the same user table, but have different entry points, templates and menus:
-
the site (the front end) is what visitors see. It is served from the web root, uses a site template such as Cassiopeia (see Cassiopeia and Cassiopeia Extended) and is driven by menu items;
-
the administrator (the back end) is served from the
/administratorpath. It uses an administrator template, Atum, and is driven by the component menu in the sidebar. Only users whose groups have the Administrator Login permission can enter it.
Every extension is installed once and can have a site half and an administrator half (a component has both, a module
belongs to exactly one client, a plugin has no client at all). That is why the language files, the template styles
and the module lists exist twice, once per client. The architecture is explained in
Introduction and Architecture, and the way logins are secured in
Security Hardening, MFA and Passkeys. Because the
administrator lives at a predictable address, it is the usual target of password-guessing bots; a strong password,
multi-factor authentication and, where the hosting allows it, an additional restriction in front of /administrator
are the baseline. Sites that need a public registration page must still keep the administrator login separate from
it.
A frequent confusion for newcomers is the two language settings and the two template style lists. The Site language, template style and modules are managed under the site client, while the Administrator ones are managed under the administrator client. Changing the administrator language therefore never changes what visitors see, and the other way round. Section The user menu and personal settings shows where each user can pick a personal administrator language and style.
The Atum administrator template
Atum is the administrator template shipped with Joomla since 4.0. It replaced the Isis template of 3.x and is responsive, uses Bootstrap 5 and is built to be accessible. Its layout is made of the same blocks on every screen:
-
the header across the top with a collapsible menu toggle, the brand logo, the page title, and on the right the status icons and the user menu;
-
the sidebar (the administrator menu) on the left, with the menu groups Content, Menus, Components, Users and System, a Help entry, and a link to the front end of the site;
-
the toolbar above the main content on list and edit screens, with the buttons that act on the screen (New, Edit, Save, Options, Help);
-
the main area, which shows either a dashboard, a list or a form.
The sidebar and the header are not hard-coded. They are rendered from administrator modules assigned to template
positions, so a site builder can add, remove or reorder what they show. Atum declares these positions in its
templateDetails.xml: top, bottom, debug, menu, sidebar, status, title, toolbar, cpanel, icon,
login and customtop. The User Guide describes them as follows: menu is the left sidebar, status holds the
right-aligned icons in the banner, toolbar is shown above the content of list and edit screens but not on
dashboards, top sits below the toolbar and above the system messages, bottom is below the component output, debug
is below everything, and customtop sits above the banner and suits site-wide warnings.
Administrator modules are managed under Content → Administrator Modules. Among the module types the User Guide lists are Administrator Menu, Administrator Dashboard Menu, Quick Icons, Logged-in Users, Popular Articles, Articles - Latest, Action Logs - Latest, Joomla! Version Information, Post Installation Messages, Privacy Dashboard, Privacy Status Check, Sample Data, Statistics, Messages, Multilingual Status, Frontend Link, Title, Toolbar, User Menu, Feed Display and Custom. Which of them appear on a dashboard is therefore a configuration choice, not a fixed feature.
Colour handling is a template style setting. Atum’s parameters, defined in its templateDetails.xml, include a hue
and a set of colours for backgrounds, text and links, a monochrome switch, three logos (login, large brand and small
brand, each with an alt text and a checkbox to leave the alt text empty on purpose) and a colorScheme list with the
values Disabled, Follow the operating system (the default, value os), Light and Dark. This is how dark mode
works in the administrator: with the default, the interface follows the colour mode of the visitor’s operating system
or browser, and a site builder can pin it to light or dark. The full template-style workflow, overrides and the
colour-mode details are in The Administrator Template Atum and
Colour Modes, RTL and Accessibility. Changing the
administrator logo from the style is the supported way to brand the back end for a client; editing core files is not,
because the next update overwrites them.
Dashboards
A dashboard is an administrator page made of modules arranged in panels. It gives quick access to a part of the site management or shows information that is awkward to find elsewhere. Most panels duplicate a link from the sidebar, which is deliberate: the dashboards let an occasional user find a task without knowing which menu group holds it. The User Guide describes seven of them.
| Dashboard | What it shows |
|---|---|
Home |
The page shown after login. Its panels are instances of the Quick Icons module, plus information modules such as logged-in users, popular and recently added articles, the Joomla version, notifications about updates, sample data, privacy status and the latest actions. The Welcome tour is offered here. |
Content |
One panel per entry of the Content menu, and extras such as popular and recently added articles. |
Menu |
A panel for Menus and Menu Items, and a panel listing the items of each site menu. |
Components |
A panel of sub-menu links for each installed component, so a new component such as |
Users |
A panel per group of the Users menu, and a view of who is logged in. Privacy, User Actions Log and Messaging have dashboards of their own. |
System |
The administrative tasks, grouped in eight panels: Setup, Install, Templates, Maintenance, Manage, Information, Update and User Permissions. |
Help |
Links to the Joomla help and support resources. Every panel except Joomla Help opens an external Joomla site; the Joomla Help panel opens an internal page that links to the help screens of the toolbar. |
Except for Home, which opens at login, a dashboard is opened with the small dashboard icon beside its main menu item (Content, Menus, Components, Users or System). Help is a separate dashboard: the User Guide notes that its screen is not titled "Dashboard" but has all the features of the others.
How a dashboard is built
The dashboards are served by the com_cpanel component. Its view reads a dashboard request parameter. In the
current source the position is computed from it: with no parameter the home dashboard uses the module position
cpanel, and with a parameter the position becomes cpanel- followed by the URL-safe name, so dashboard=system
loads the modules of position cpanel-system. Quick icons follow the same pattern: icon for Home and icon-
followed by the name for the others. The core dashboards get fixed icons (icon-puzzle-piece for Components,
icon-wrench for System and icon-info-circle for Help); a component can supply its own title and icon through a
dashboard entry in its manifest, and otherwise language keys derived from the component and section name are used,
falling back to the generic title. Every dashboard shows the same help screen, screen.cpanel.
This design has practical consequences for a site builder:
-
A panel is an administrator module. Open Content → Administrator Modules, filter by position, and a panel can be edited, reordered, unpublished or restricted to certain user groups. For a Home panel, use the Edit action in the panel’s top-right corner, change the Access field of the Quick Icons module and save; the panel then disappears for groups without that access level.
-
A new dashboard needs no code. Link to
index.php?option=com_cpanel&view=cpanel&dashboard=tallpine, for example from a custom administrator menu item, and assign modules to the positioncpanel-tallpine. The Menus section of the User Guide documents how to add a custom administrator menu. -
The Sample Data panel and the first-install notices are best unpublished on an established production site.
The Tallpine administrator, for instance, wants the editors to land on something shorter than the full Home
dashboard. A site builder can create a Trail reports dashboard with three modules in position cpanel-tallpine: a
Custom module with a link to the report form, an Articles - Latest module filtered to the Trails category, and a
Quick Icons module whose links open the article list pre-filtered by the Trail Warden’s access level. Because the
panels are modules, the access level of each one decides who sees it, which keeps the Trail Warden group’s
member-only panels away from ordinary editors.
<!-- Custom administrator module, position cpanel-tallpine, access: Editor -->
<p>Publish a new trail report in three steps.</p>
<p>
<button type="button"
class="btn btn-primary button-start-guidedtour"
data-gt-uid="tallpine-editors-publish-trail-report">
Start the "Publish a trail report" tour
</button>
</p>
The button class and the data-gt-uid attribute are what the Guided Tours script looks for; the example module is
the one the Manual itself uses to show how to launch a tour from anywhere. The module is a Custom module, so its content
is filtered by the text filters configured for the author’s group (see the Text Filters section of
Global Configuration). A group with the default filter strips button
elements and attributes the filter does not allow, in which case the markup must be entered by a Super User or the
group’s filter relaxed deliberately.
The modules themselves are covered in Modules and Positions; the only difference for the administrator is that the Site/Administrator client switch in the module manager selects the other list.
The System dashboard
The System dashboard is where an administrator spends most of the maintenance time. Its panels group tasks that other pages of this sub-section cover in depth:
-
Setup leads to Global Configuration (Global Configuration) and the other site-wide settings;
-
Install leads to the extension installer, the extension manager, the update sites and the language installer (Extensions: Installing, Updating and Update Sites);
-
Templates leads to the template styles and overrides for both clients;
-
Maintenance leads to the clear-cache, the global check-in and the database tools (System Information, Maintenance and Troubleshooting);
-
Manage leads to the extension, plugin, scheduled task, guided tour, mail template and redirect lists;
-
Information leads to the System Information screens and the Installation Messages tab described below;
-
Update leads to Joomla Update (Updating Joomla and Automated Core Updates);
-
User Permissions leads to the screens that govern what each group may do (Users, Groups, Access Levels and ACL).
The panel names are those listed in the User Guide; individual links inside a panel vary with the installed extensions and with the permissions of the logged-in user, because a user only sees what their groups may manage. In practice an Editor who opens the System dashboard sees an almost empty page, which is the intended behaviour and not a fault.
The Help dashboard
The Help dashboard collects the places where a site builder can ask for help. Its external panels open in a new tab and point to Joomla sites such as the documentation, the forum, the extensions directory and the security pages. The internal Joomla Help panel lists the toolbar help screens. Each list and edit screen also has a Help button in its toolbar, which opens the help page for that exact screen, so an editor rarely needs the dashboard itself. For the Tallpine editors, pointing the help links at a club handbook is better done with a tour than by editing core language files.
Post-installation messages
Post-installation messages are notices addressed to the site administrator, shown after an installation or an update. They explain new features, ask for decisions (for example about the statistics collection feature that reports anonymous installation data to the project) and point to resources. The User Guide gives two examples: the statistics-collection message and a welcome message that lists helpful resources.
They are reached in two ways: from System → Information, on the Installation Messages tab, or from the button in the title bar of most list screens (it is missing on edit screens, and also if its parent module, Post Installation Messages, is unpublished). Each message is a panel with two actions:
-
Hide this message removes a message permanently. Joomla offers no screen to restore a hidden message; it can only be restored in the database.
-
Archive collapses the panel’s content and replaces the button with a green Read Again button.
Extensions can ship their own messages by adding records to the post-installation messages table from an installer
script (see Installer Scripts and SQL Updates). The Tallpine
package could use one to tell the administrator, after the first install of pkg_tallpine, to set the park-authority
API credentials in the component options. Such a message should be short and actionable; a message that nobody can
dismiss, or that repeats on every update, trains administrators to ignore all of them.
Guided Tours
Guided Tours are step-by-step walkthroughs that highlight elements of an administrator page and tell the user what to do next. They were introduced in Joomla 4.3. The User Guide describes them as a very brief introduction for complete newcomers, and ships these tours: how to create guided tours and add steps to them; "Welcome to Joomla!" on the Home dashboard; and one each for creating articles, categories, menus, tags, banners, contacts, news feeds, smart search filters and users. Several tours were refreshed in later releases, and each major or minor release can add a "What’s New" tour that appears after an update.
Starting a tour
-
The "Welcome to Joomla!" tour starts by itself the very first time a user logs in to the administrator.
-
Any other tour is chosen from the Guided Tours dropdown in the title bar of dashboards and list screens. The dropdown lists first the tours whose component selector matches the current page, and tours set to All last.
-
A tour with Auto Start switched on starts when a user reaches the screen it belongs to. A user can hide a tour permanently, and a cancelled tour waits before it runs again. The wait defaults to one hour and is set in the component’s options (the field is called
delayed_time; a separate switch,allowTourAutoStart, turns auto start on or off for the whole site). -
A button with the class
button-start-guidedtourand adata-gt-uidattribute holding the tour identifier starts that tour from any page, as in the dashboard module above.
Managing tours
Tours are managed under System → Manage → Guided Tours, which is the com_guidedtours component. The list has
the usual Joomla filters (status, access level, language and search), and an Options button opens the component’s
permissions, so that the right to create and edit tours can be given to a group without making it a Super User. A
tour has these properties, taken from the component’s form definition:
| Field | Meaning |
|---|---|
|
Required. Either plain text or a language key; when it is a key, a read-only translation field shows the text for the user’s language. |
|
The tour identifier. It is suggested on Save or Save as Copy. It distinguishes tours of different origin, names
the language files and is what |
|
The text shown at the start of the tour; HTML, or a language key. |
|
Required. The relative path where the tour starts, for example
|
|
Required, multiple. The component selector: the pages that offer the tour first. The Manual advises against leaving it on All, and third-party developers should select their own extensions. |
|
Switch, off by default. |
|
The usual status (published, unpublished, archived, trashed), access level, language (default All) and an internal note of up to 255 characters. |
A tour can be duplicated, exported and imported; the export offers a SQL + INI Export, which produces the SQL statements and the language keys needed to ship the tour with an extension or with core.
Steps
Each tour has an ordered list of steps, edited from the Steps button of the tour. A step has these properties, taken from the step form definition:
| Field | Meaning |
|---|---|
|
The heading, usually a call to action, and the help text. Both can be language keys. |
|
A CSS selector for the element to highlight. Several comma-separated selectors may be given, and the first valid one is used; if none is found the step is shown in the centre of the screen. |
|
Where the step bubble appears relative to the target: bottom, center, left, right or top. The default is center. |
|
Next (0) moves on; Redirect (1) sends the user to another page, given in |
|
For an interactive step: form submit (1), text field (2), button (4), checkbox or radio (5), select list (6) or other (3). Text fields, checkboxes and select lists can be marked required, and a text field or select list can demand a specific required value, so the user cannot continue until the field is filled in correctly. |
Interactive steps are what make a tour more than a slideshow: the user is led to type a title, tick a box or press the
Save button, and the tour moves forward only when that happens. They are also the part most likely to break when the
interface changes, because the selector in target must still match. Prefer stable selectors such as element IDs and
name attributes over positional ones like :nth-child, and re-run every custom tour after a Joomla update.
Joomla’s own tours are re-checked at each release for that reason.
A custom tour for the Tallpine editors
The Tallpine editors need to learn one task: publishing a trail report. The tour below is set up from the Guided Tours screen with these values.
| Setting | Value |
|---|---|
Title |
|
Identifier ( |
|
Relative URL |
|
Component selector |
Articles |
Auto Start |
No (editors start it from the dashboard button) |
Access |
Editor (so authors and the public never see it) |
The steps are:
-
Next, target
.button-new, position bottom: "Press New to start a trail report." -
Redirect, URL
administrator/index.php?option=com_content&task=article.add: opens the article form. -
Interactive, text field, required, target
#jform_title, position bottom: "Give the report a clear name, such as the trail and the date." -
Next, target the category field, position right: "Choose Trails then Alpine or Valley, or News."
-
Interactive, button, target the Save & Close button of the toolbar: "Save the report. A reviewer publishes it."
Target selectors depend on the markup of the form, and the editor field IDs in particular can differ between forms and
releases, so confirm each one with the browser’s developer tools before saving the tour. Titles and descriptions are
written as language keys so that the German edition of the site gets a German tour. The tour uses two language files,
named after the identifier with dashes turned into underscores: one for the tour’s title and description and one for
its steps. Every key in them must contain GUIDEDTOUR.
; administrator/language/en-GB/guidedtours.tallpine_editors_publish_trail_report.ini
COM_GUIDEDTOURS_TOUR_TALLPINE_PUBLISH_TRAIL_REPORT_TITLE="Publish a trail report"
COM_GUIDEDTOURS_TOUR_TALLPINE_PUBLISH_TRAIL_REPORT_DESCRIPTION="<p>Learn how to publish a trail report for the Tallpine Hiking Club in five steps.</p>"
; administrator/language/en-GB/guidedtours.tallpine_editors_publish_trail_report_steps.ini
COM_GUIDEDTOURS_TOUR_TALLPINE_PUBLISH_TRAIL_REPORT_STEP_NEW_TITLE="Create a report"
COM_GUIDEDTOURS_TOUR_TALLPINE_PUBLISH_TRAIL_REPORT_STEP_NEW_DESCRIPTION="<p>Press <strong>New</strong> to start a trail report.</p>"
COM_GUIDEDTOURS_TOUR_TALLPINE_PUBLISH_TRAIL_REPORT_STEP_TITLE_TITLE="Name the report"
COM_GUIDEDTOURS_TOUR_TALLPINE_PUBLISH_TRAIL_REPORT_STEP_TITLE_DESCRIPTION="<p>Use the trail and the date, for example <em>Alpine ridge, 12 July</em>.</p>"
The Manual describes the same two-file convention for the core tour joomla-welcome, whose files are
guidedtours.joomla_welcome.ini and guidedtours.joomla_welcome_steps.ini. The exact key names above are an
organisational choice; the rule is the GUIDEDTOUR substring.
There are two ways to deliver the tour:
-
By hand, for one site. Create it in the interface, choose Export and keep the file in the repository, so that the staging and production sites receive the same tour.
-
With an extension. A tour that belongs to an extension can keep its language files inside the extension, provided its
uidstarts with the extension type and name:com_,mod_,plg_[group]_ortpl_followed by the name, for examplecom_tallpine.publish-trail-report. The extension’s installer script or SQL update file inserts the rows. The core "What’s New" tours are delivered the same way through SQL update files incom_admin, and the Manual shows that a new major version removes earlier "What’s New" tours with explicit statements on the#__guidedtoursand#__guidedtour_stepstables, and disables the autostart of the previous minor’s tour with anUPDATE. It recommends listing the identifiers withIN (...)rather thanLIKE, so that tours created by users are never deleted by accident. Images used in a tour come from the/imagesfolder, or, for an extension, from a path starting withmedia/.
-- Remove the previous release's tour when Tallpine 2.0 ships (MySQL)
DELETE FROM `#__guidedtour_steps`
WHERE `tour_id` IN (SELECT `id` FROM `#__guidedtours`
WHERE `uid` IN ('com_tallpine.whatsnew-1-0'));
DELETE FROM `#__guidedtours` WHERE `uid` IN ('com_tallpine.whatsnew-1-0');
PostgreSQL needs its own file with double-quoted identifiers; the query builder does not make raw install SQL portable between the two databases (see Installer Scripts and SQL Updates).
Permissions and security
Tour descriptions and step texts are HTML that every user who runs the tour will render, so edit rights on
com_guidedtours are a privilege worth limiting: a person who can write a step can put markup in front of a Super
User. Give the Create and Edit actions only to the group that maintains the documentation. Because the tour
extensions filter limits who sees a tour on a given page and the access level limits who can run it, a tour that
mentions a member-only feature, such as the Trail Warden’s condition reports, should carry the Trail Warden access
level. A tour must never include real credentials as example input, and a required value must not be a secret.
Auto start is the setting most often regretted. A tour that restarts after every cancellation annoys experienced users; leave auto start off for everything except onboarding, and use the delay and the user’s hide permanently choice to stay out of the way.
The user menu and personal settings
Every administrator user has a user menu in the header, rendered by the User Menu module (position status). It
gives the signed-in user access to their own account. The account form is the standard user edit screen, which
carries a Basic Settings tab with three personal choices (the fields admin_style, admin_language and editor):
-
the administrator template style, so one user can use a different Atum style than the rest;
-
the administrator language, chosen from the installed administrator languages;
-
the editor, so a Tallpine author who prefers a plain textarea can have it while the rest of the club uses TinyMCE.
Each of them also accepts Use default. Setting a personal administrator language is the recommended way to give a German-speaking board member a German interface without changing the language of the site’s visitors; the language packs themselves are discussed in Language Files and Internationalisation.
Accessibility settings
The same user form has an Accessibility Settings tab. It contains four switches, each off by default, stored with the user and applied by the administrator template:
| Setting | Effect |
|---|---|
Monochrome ( |
Shows the interface without colours. |
High contrast ( |
Increases the contrast of text and controls. |
Highlight ( |
Emphasises links and focus so that they stand out more. |
Font size ( |
Enlarges the text. |
The labels shown in the interface come from the language files, so wording differs between languages. Dark mode is not one of these switches: by default it follows the operating system’s colour preference, as described above, unless the template style pins the scheme. A site builder who serves club members with visual impairments should enable these per user instead of editing the template, since the settings survive template updates. The wider accessibility story (the Accessibility Checker, the front-end template, WCAG) is in Colour Modes, RTL and Accessibility, and a general treatment of web accessibility is on the Accessibility page.
Common problems
-
The dashboard shows no panels. The modules in the
cpanelorcpanel-nameposition are unpublished, or the user’s groups lack the module’s access level. Check Content → Administrator Modules, with the filter set to the position. -
A tour does not start. The tour is unpublished, its access level excludes the user, its relative URL has a typo, or auto start is switched off in the component options. If the highlighted element is missing, the step falls back to the centre of the screen instead of failing, which usually points to an outdated selector.
-
The post-installation button is gone. The Post Installation Messages module is unpublished. Messages that were hidden cannot be shown again from the interface.
-
The Welcome tour is not shown to a new editor. It runs for a user’s first login to the administrator only; start it manually from the Home dashboard dropdown.
-
A Custom module button does nothing. The text filter removed the markup, or the page does not load the Guided Tours script because no tour is available on that screen.
Corrections to older material
Joomla! 4 Masterclass (Marzo, Packt, 2023) is the best book overview of the administrator screens, and its dashboard chapter still maps onto the screens above. Its target is Joomla 4.x, which reached end of life in October 2025, and it does not cover the Joomla 5 and 6 releases; it links to docs.joomla.org and launch.joomla.org pages that have been superseded by the Joomla! User Guide at guide.joomla.org. Material written for Joomla 3 describes the Isis template, the control panel as one screen and the four-colour interface; none of that applies to Atum. For the current documentation locations, and a list of older advice to avoid, see Where Older Books and Tutorials Are Outdated.