Comparison and Decision Guide

Joomla core already contains a large part of what a content site needs: articles, categories, tags, custom fields, menus, contacts, banners, news feeds, Smart Search, multilingual associations, redirects, workflows, scheduled tasks, mail templates, multi-factor authentication, privacy tools and action logs, and the Web Services API. What it does not contain is a backup tool, a multisite feature, a shop, a forum or a visual page builder; these come from third-party extensions that are listed in the Joomla Extensions Directory (see Update Servers and the JED).

Before adopting an extension, check its Joomla and PHP compatibility in the changelog (not only on the directory page), the date of its last release, whether it ships an update server (so Joomla can tell you when a security release exists), and who maintains it. The checks are described in Extensions: Installing, Updating and Update Sites. Extensions are installed from the administrator, so every extension is also code that runs with full privileges on the server: install only what the site needs.

Rule of thumb. Use core whenever it covers eighty per cent of the need, and extend it with a small extension of your own when it does not. The club uses core for articles, tags, contacts, banners and Smart Search, and a backup extension because core has none (see Backups and Recovery). Shop extensions for Joomla exist, but selling is a different problem; if a shop is the main product, compare dedicated platforms first in the E-commerce comparison.

The club publishes trail reports with a distance, an elevation gain, a difficulty, a GPX file and a season. Two designs fit.

Rule of thumb. Start with articles and custom fields. Move to a custom component when the data has its own lifecycle, many records, relations or reporting, or when editors do not think of it as content. The club keeps trail reports as articles with fields, because editors, tags, workflow and search all expect articles. It builds com_tallpine only for the trail catalogue, an imported dataset of thousands of segments with closures from a park authority, which does not belong in the editorial article list. The component can still reuse categories and custom fields, so the choice is not all or nothing; see The Database API and Extension Types, Manifests and Packaging.

Cassiopeia is the default site template. To make the club’s site look different there are four routes.

Child templates have existed since Joomla 4.1, and Joomla 6.0 ships cassiopeia_extended as a core child template, so older material that calls them brand new is out of date. A child inherits every file of the parent except the files that share a name with a file in the child. The user guide states that child template files are not affected by Joomla updates. See Child Templates and Cassiopeia and Cassiopeia Extended.

Source: Joomla User Guide: Child Templates

A template that has nothing in common with Cassiopeia, or that is meant as a teaching example, is better written from scratch than copied; see Building a Template from Scratch. Third-party frameworks and builders such as Helix Ultimate, T4, Gantry 5, SP Page Builder and YOOtheme Pro are presented neutrally in Template Frameworks and Page Builders, with an audit procedure; their Joomla 6 compatibility is a statement by each vendor.

Rule of thumb. Create a child template of Cassiopeia. Copy a template only to freeze a design on purpose. Choose a framework only for a concrete feature you need and after checking its Joomla 6 support and its exit path. The club uses cassiopeia_tallpine.

Three mechanisms change the output of an existing page without editing core files. They differ in what they replace and in where the change lives.

An alternative layout is a variation of a view that a menu item or a module can select by name; it is created as an override with a different file name and chosen from the Layout list. See Template Overrides and Alternative Layouts and Layouts and Module Chromes for the search order and the screens. When the work is to change what data appears or to react to something happening, a plugin is the right place; see Plugin Development and Events.

Rule of thumb. If the change is about markup in one template, use an override. If the same fragment appears in many places, override the layout once. If the change is about behaviour or must survive a template switch, write a plugin. Prefer an override created from the Templates manager, so the Updated Files tab warns when the core file it copied has changed. The club overrides the article view and the custom-fields layout in its child template, and keeps the trail conditions notice in the plugin plg_content_tallpine_conditions, because it must also work if the template changes.

Joomla has four extension types for a developer to choose among (templates, languages and packages are the others), and the first three are easy to confuse.

A module uses the Dispatcher and Helper design (see Module Development), a plugin uses a services/provider.php and a class that implements SubscriberInterface with the concrete event classes of Joomla 5 and later, and a component uses the namespaced MVC (see Namespaces, Autoloading and Dependency Injection). A plugin placed in the wrong group is never loaded for its event, and a component is not needed when a module can show the same data. The related scheduled and command-line plugin types are covered in Scheduled Task Plugins and Console Command Plugins.

Rule of thumb. If the feature needs its own page, build a component. If it is a box on many pages, build a module. If it reacts to something, build a plugin. A single feature often needs more than one, which is why the club ships all of them in one package, pkg_tallpine, so they install, update and uninstall together; see Extension Types, Manifests and Packaging.

Both return JSON to another program. Since Joomla 4.0 every site has a Web Services API application at /api/index.php/v1, which returns JSON:API documents, authenticates with an API token in the X-Joomla-Token header, and exposes endpoints for articles, categories, fields, users, menus, modules and more. The Developer Manual page for Web Services documents the article operations and points to a list of core endpoints.

On a fresh 6.2 install the API token plugin is enabled and the Basic Auth API plugin is disabled, so generate a token for a dedicated user and keep it on the server side of the front end. Never put a token in browser code. The following request reads the club’s trail reports.

Source: Joomla Manual: Web Services

See Web Services API, Extending the Web Services API and Headless Joomla.

Rule of thumb. Use the Web Services API for anything that another application consumes, and for headless sites. Use a small custom view or com_ajax call only for a response that the site’s own page needs in the same session. The club’s "trail map" front end reads the API with a server-side token, and the nexthikes module does its small refresh through com_ajax.

Workflows add stages and transitions to articles (and to other components that opt in), so that people can only move an item along the steps their permissions allow. They exist since Joomla 4.0, are off by default, and are switched on in the options of the Articles component. Joomla ships one workflow, the Basic Workflow, and the visual workflow editor arrived in Joomla 6.1. See Workflows for the screens and the plugins.

Rule of thumb. Enable workflows when a second person must approve before an item is public, and not before. The club keeps the News category without workflows and gives the Trails categories a Draft, Review and Published workflow in which only the Trail Wardens group runs the publish transition. Permissions are in Users, Groups, Access Levels and ACL.

Joomla ships a major version every two years, in October of odd years, with four minors, one every six months. The fourth minor (x.4) is a bridge release: it adds no features and is the only starting point for the next major. After x.4.0 there is one year of bugfixes and two years of security fixes. For 5.x the bugfix period ended with 5.4.10 on 2026-10-13, and security fixes continue until 2027-10-12. Joomla 6.x was released on 2025-10-14; the developer roadmap gives regular bugfix support for 6.x until 2028-10-17 and security-only support until 2029-10-16.

An upgrade starts from the latest 5.4.x. Update to it, disable the old backward-compatibility plugin, enable Backward Compatibility 6 (the two cannot both be on), and switch the update channel to Joomla Next. The Joomla 6.0 removals matter for custom code: JPATH_PLATFORM is no longer defined without BC6, AdminModel::getItem() returns stdClass, and the legacy J* aliases such as JFactory and JText are in BC6 only and off by default on new installs. Automated Core Updates, available since 5.4, are on by default for new installs and off for upgraded sites. For the procedure, the removals and the recovery path see Upgrading Joomla 5 to 6, Deprecations and Preparing for Joomla 7 and Versions, Release Cycle and Support. Sites on 4.x or 3.x first reach 5.4: see Upgrading Joomla 4 to 5 and Migrating from Joomla 3.

Rule of thumb. A new site starts on 6.2. An existing 5.4 site should plan the upgrade within its security window rather than wait for its last month, and should not upgrade production before the extension audit and a staging rehearsal. The club’s site runs 6.2 from the start; a partner club site still on 5.4 has until 2027-10-12 and plans for early 2027. Older books such as Developing Extensions for Joomla! 5 (2023) and Joomla! 4 Masterclass (2023) target platforms that are now security-only or end of life, so their code and screens need the corrections listed in Where Older Books and Tutorials Are Outdated.

Joomla pays back its learning curve when a site has structured content, access levels, multiple languages and a long life, and when the team wants a PHP CMS with a built-in administrator and API. It is a poor fit in these cases.