Category: Joomla

To customize Joomla without editing core files, put every change in a layer Joomla will not overwrite: a child template, user.css / user.js, a layout override in html/, a language override, a template style, or a custom plugin. Do not edit files under components/, modules/, plugins/, libraries/, or the parent template. Those paths come back to stock on the next Joomla, PHP, or extension update. This holds on Joomla 4.1+, 5.4, and 6. On Joomla 3 there is no Create Child Template button. You still use html/ overrides and language overrides. You do not patch core there either.

Editing Cassiopeia, com_content, or a plugin “just this once” is how sites get stuck on old Joomla. The safe stack is smaller than it looks. Pick the smallest tool that matches the job, keep the parent stock, and check overrides after every update.

Updates replace core and the parent template. Your child, language overrides, and custom plugins stay.

What you will learn

• What counts as a core file (and what does not)
• Which Joomla tool to use for CSS, HTML, wording, and behaviour
• How to set up a child template so CSS and overrides survive updates
• Where user.css actually lives on Cassiopeia
• How Create Overrides copies layouts into html/
• When a language override or a custom plugin is the real fix
• What to re-check after a Joomla update

The problem core edits create

You change one PHP file. The header looks right. Two weeks later Joomla ships a security release. The updater replaces that file. The header is stock again. Or worse: the update skips the file because it differs from the package, and you sit on an unpatched copy.

That is not a discipline problem. It is how Joomla packages work. Core and most extension files are owned by the installer. Template styles (logo, colour params, menu assignment) live in the database and survive. Files you typed into components/com_content/ do not.

The fix is not “remember to re-apply the hack.” The fix is never putting the hack in a path the installer owns.

Official layout override model: Layout Overrides in Joomla. Child templates: Joomla User Manual, Child Templates. Cassiopeia user.css: Cassiopeia Template Customisation.

What counts as a core file

Treat these as do not edit:

Path	Why
components/com_*	Joomla and extension updates replace views
modules/mod_*	Same for module chrome and tmpl
plugins/*	Event code and plugin tmpl come back on update
libraries/	Framework. A one-line patch here is a future outage
media/vendor/ and compiled template CSS you did not create	Next build or update wipes it
Parent template files (Cassiopeia, Atum, a club parent)	The parent is the package. Your child is the overlay

These are safe homes when you use them as designed:

Place	What it stores
Child template	user.css, user.js, html/ overrides, extra positions, optional index.php
Template style	Params, logo, menu assignment. Not PHP.
Language override	UI strings. Not markup.
Custom fields	Extra data on articles, contacts, users
Custom plugin or module you installed	Behaviour you own. You still update that extension yourself.

A duplicate of the whole Cassiopeia folder renamed “Cassiopeia custom” is not a child. It is a fork. You now maintain hundreds of files you did not write, and Cassiopeia security fixes never reach it.

Pick the smallest safe tool

If CSS can do it, stop. If the string is a language key, do not override PHP to change a label.

You want to…	Use	Do not
Change colour, spacing, hide a block that already has a class	user.css in the active template (child if you have one)	Edit template.min.css or Bootstrap in media/
Add a small script	user.js or a proper Web Asset. Walkthrough: Add custom JavaScript to Joomla	Paste <script> into core index.php
Change article, blog, or module HTML	Layout override in html/	Edit components/ or modules/
Change plugin HTML (Prev/Next, vote, a field type)	Plugin override in html/plg_… when the plugin has tmpl. Guide: Joomla plugin override	Edit plugins/content/…
Change a label, button, or email subject	Language override	Search-and-replace in PHP
Extra data (price, spec, event date)	Joomla custom fields	Hack the article table
Different logo or brand colour per section	Template style (and a child if files must differ)	Duplicate the whole template
Different markup on one category only	Alternative layout (filename without a leading underscore)	if ($catid == 12) inside a core view
Change how Joomla behaves (redirect, ACL, a new event)	Custom plugin, or an extension you can update	Patch libraries/
Survive parent template updates	Child template	Edit Cassiopeia in place

The rest of this article is the order of operations. The child-template post is the click-by-click for Create Child Template. Use that when you reach Step 2. Do not skip it and drop user.css into the parent “for now.”

Step 1: Name the change before you open a file

Write one sentence: “I need the article byline stacked, not inline,” or “I need the header background #0b3d5c,” or “I need Read more to say Continue.”

Then classify it:

1. Look only (colour, type, hide): CSS.
2. Markup (extra wrapper, different heading level, remove a div): layout override.
3. Wording: language override. Confirm with Debug Language if you are unsure which key it is.
4. Data: custom field, not a new column in #__content by hand.
5. Logic: plugin. If you cannot name the event (onContentPrepare, onAfterRoute), you are not ready to write PHP.

If you cannot classify it, you are about to edit the wrong file.

Step 2: Create a child template (Joomla 4.1 and later)

On Joomla 4.1, 5, and 6, open System → Templates → Site Templates, open an inheritable parent (Cassiopeia is the one that ships ready), and click Create Child Template. Assign the child’s style as default or per menu item.

Full clicks, media/ vs templates/, Atum, and making a custom parent inheritable: How to set up a Joomla child template.

Until that style is assigned, the public site still uses the parent. Creating the child does not change the frontend by itself.

Joomla 3: there is no native child. Keep overrides in your template html/ folder. Prefer a template you control, not a club template you will overwrite on the next vendor zip. Plan the Joomla 3 to 6 upgrade so you can use children.

Joomla 6: Cassiopeia Extended is already a child of Cassiopeia. Do not hack Extended as if it were a parent. Copy the child (6.1) or create your own child of Cassiopeia.

Do these in order. CSS first. PHP last.

Step 3: Put CSS in user.css (not in the compiled sheet)

Cassiopeia loads user.css if the file exists. On Joomla 4.1 and later the path is:

media/templates/site/{template}/css/user.css

For a child named cassiopeia_brand, that is media/templates/site/cassiopeia_brand/css/user.css, not the parent’s file. A child does not load the parent’s user.css. If you already wrote rules in Cassiopeia and then created a child, copy them into the child’s file or the site will look stock.

In Template Manager: open the template, select the css folder, New File, name user (no suffix), type .css.

The Joomla 4.0-only path templates/cassiopeia/css/user.css was moved into media/ when child templates landed. If your CSS “does nothing,” you are almost always in the old folder, or you assigned a child while the file still sits on the parent. The next article in this series is the CSS-not-showing checklist. Until then, use the child-template user.css section.

Keep !important rare. Cassiopeia registers user.css with a high asset weight so it loads after the template sheet.

Step 4: Override HTML with Create Overrides

For component and module layouts:

1. System → Templates → Site Templates → {your child} → Create Overrides
2. Pick the component view or module.
3. Joomla copies the file into templates/{child}/html/…
4. Edit that copy only.

Filename rules matter. A copy named _default.php or a typo in the folder (com_content/article vs com_content/articles) means Joomla never loads it. Create Overrides is there so the path is correct.

Plugin layouts usually do not appear in that list. You copy tmpl by hand into html/plg_{group}_{element}/. Details: plugin overrides in the html folder.

After a Joomla update, open the template’s Overrides (or Updated Files) list. If core changed a layout you overrode, diff your copy. Joomla documents this as override management. It does not watch user.css or user.js. You review those yourself.

🔗 Layout Overrides in Joomla
Folder map for components, modules, plugins, and JLayouts.

Step 5: Change wording with a language override

If the public string exists in a .ini language file, System → Language Overrides. Site vs Administrator is a different list. Debug Language shows the constant on the page.

Do not override default.php to change “Read more.” That is a core-edit habit with extra steps.

Setup: Joomla language overrides.

Step 6: Add data with custom fields, not a core hack

Price, subtitle, event date, and spec tables belong in Content → Fields. Automatic display or a field layout in the child. If you still run K2 extra fields, migrate on Joomla 3 first: K2 to com_content.

Fields how-to: Joomla custom fields.

Step 7: Change behaviour with an extension you own

Redirect rules, extra authentication, “hide this module when…” that CSS cannot express: write or install a plugin. Leave plugins/system/sef and libraries/src alone.

If an installed extension is broken, do not patch its PHP on the server. Duplicate the plugin with a new element name, or wait for the vendor, or replace it. A patched third-party file is the same class of problem as a patched core file.

Need a plugin built to spec? Joomla plugin development.

After every Joomla or template update

1. Clear Joomla cache and your browser cache.
2. Open the child template Overrides list. Diff any layout Joomla marked as updated.
3. Skim user.css for selectors that no longer exist (Cassiopeia class names do change between major versions).
4. Confirm the child style is still default or still assigned to the right menus.
5. If you use a club parent, read the vendor notes before you copy their new index.php over your child copy.

This five-minute pass is cheaper than discovering a blank header on Monday.

What this does not replace

A child template is not a page builder, a CDN, or a backup. It does not fix PHP 8 fatals from an old extension. It does not make a commercial template inheritable until the vendor sets <inheritable>1</inheritable> and moves CSS under media/.

Safely customize Joomla without editing core files means you still test on staging. Overrides can be wrong. CSS can hide the cart button. The rule is only: when it is wrong, the stock parent is still there to compare against.

Key takeaways

1. Never edit components/, modules/, plugins/, libraries/, or the parent template to “make it look right.”
2. Classify the job: CSS, HTML, string, data, or behaviour. Use one tool.
3. On Joomla 4.1+, create a child, assign its style, then add files.
4. Cassiopeia custom CSS belongs in media/templates/site/{template}/css/user.css on the active template.
5. Layout overrides live in the child’s html/ folder. Create Overrides for components and modules. Plugin tmpl is usually manual.
6. Labels go through language overrides. Extra article data goes through custom fields.
7. After updates, diff overridden PHP. Review user.css yourself. Joomla will not do that for you.

If the next problem is “I did all this and the CSS still does not load,” that is the 4 September post in this series. If the override PHP does not run, that is the 11 September post.

Need a template customized without forking core on a client site? Joomla design services.

Related Joomla troubleshooting

• Joomla CSS changes not showing
• Joomla JavaScript not working
• Template override not working
• Template override disappeared after an update
• Joomla module not showing
• Custom fields not showing

Frequently asked questions

Can I customize Joomla without editing core files?

Yes. Use a child template, user.css, layout overrides in html/, language overrides, custom fields, and custom plugins. Leave core and parent template files stock.

Is editing Cassiopeia the same as a child template?

No. Cassiopeia is the parent package. Updates replace it. A child stores only your files. Setup: Joomla child template.

Where do I put custom CSS in Joomla 5?

For Cassiopeia, media/templates/site/cassiopeia/css/user.css, or the same path under your child name. Create the file if it is missing. The old templates/cassiopeia/css/ location is the Joomla 4.0-era path.

Do template overrides survive a Joomla update?

Overrides in a child (or in a template Joomla does not overwrite) stay on disk. The source layout in components/ may change. Diff your copy after the update. CSS is not in that checker.

Can I edit a plugin file if I back it up?

You can. The next extension update still overwrites it, or the updater skips it and you stay unpatched. Use an html/plg_… override when there is a tmpl, or a plugin you own when you need logic.

What about Joomla 3?

No native child template. Use html/ overrides and language overrides on a template you control. Do not patch components/. Move to 4.1+ when you can so children exist.

Is a template style enough?

For logo, colour parameters, and menu assignment, yes. For PHP, CSS files, and overrides, you need a child (or a template you fully own). A style still points at the same files.

---

SEO Metadata

Field	Value
Meta Title	Safely Customize Joomla Without Editing Core Files
Meta Description	Change Joomla CSS, HTML, and strings without hacking core. Use a child template, user.css, layout overrides, and language overrides so updates keep your work.
URL Slug	joomla-customize-without-editing-core
Focus Keyword	customize Joomla without editing core

Character counts:

• Meta Title: 50 chars
• Meta Description: 158 chars

HTML Meta Tags

<title>Safely Customize Joomla Without Editing Core Files</title>
<meta name="description" content="Change Joomla CSS, HTML, and strings without hacking core. Use a child template, user.css, layout overrides, and language overrides so updates keep your work." />
<link rel="canonical" href="https://www.infyways.com/joomla-customize-without-editing-core/" />
<meta property="og:title" content="Safely Customize Joomla Without Editing Core Files" />
<meta property="og:description" content="Change Joomla CSS, HTML, and strings without hacking core. Use a child template, user.css, layout overrides, and language overrides so updates keep your work." />
<meta property="og:url" content="https://www.infyways.com/joomla-customize-without-editing-core/" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Safely Customize Joomla Without Editing Core Files" />
<meta name="twitter:description" content="Change Joomla CSS, HTML, and strings without hacking core. Use a child template, user.css, layout overrides, and language overrides so updates keep your work." />

A Joomla plugin override is a copy of a plugin layout file in your template html folder. The path is templates/{template}/html/plg_{group}_{element}/{layout}.php. It works on Joomla 4, 5.4, and 6 for any plugin group (system, content, fields, user, authentication, editors-xtd) if that plugin loads a layout through PluginHelper::getLayoutPath(). That almost always means a tmpl folder. No tmpl means there is nothing for html/ to replace. Most system plugins have no layout. A few that print HTML do.

This is the 2026 operator guide. It is not limited to page navigation. You will test for a layout, name the folder, put the file in a child template, and know when CSS or a language override is the real fix.

The plugin keeps the logic. Your template keeps the HTML. Updates replace the plugin. Your copy stays if it lives in a child.

What you will learn

• How plugin overrides differ from component and module overrides
• The tmpl test that decides yes or no, including system plugins
• The exact html/plg_{group}_{element}/ folder name
• Why Create Overrides in the template manager usually hides plugins
• How to override content page navigation, content vote, and field types
• What a plugin override can change, and what it cannot
• When to use html/layouts/ instead of html/plg_…
• How to debug an override that “does nothing”

The problem plugin overrides solve

You want Prev/Next as buttons. You want the vote stars in a different order. You want a field type to print a badge instead of a definition list.

The HTML lives inside the plugin, not in com_content’s article layout. Editing plugins/content/pagenavigation/tmpl/default.php works until the next Joomla or extension update puts the stock file back.

A component override of the article view does not catch output the plugin injects later. A module override does not catch it either. You need a plugin override, or you are hacking core.

Official path and the tmpl rule: Layout Overrides in Joomla. The J4 layout page shows the same idea for vote: Template Layouts.

Three kinds of output, three folders

What prints HTML	Source folder	Override folder
Component view	components/com_*/tmpl/…	html/com_*/{view}/
Module	modules/mod_*/tmpl/	html/mod_*/
Plugin with tmpl	plugins/{group}/{element}/tmpl/	html/plg_{group}_{element}/
Shared JLayout	layouts/… or extension layouts/	html/layouts/…

Create Overrides under System → Site Templates → {template} → Create Overrides lists components, modules, and many JLayouts. It usually does not list plugins. You create html/plg_… by hand. That is why people think plugin overrides do not exist.

The tmpl test (including system plugins)

System is not a special exception. The test is the same for every group.

1. Open plugins/{group}/{element}/.
2. If you see tmpl/ with .php files, a template override is possible if the PHP calls PluginHelper::getLayoutPath('{group}', '{element}', '{layout}') (or the CMS plugin helper equivalent).
3. If there is no tmpl and no JLayout render, stop. html/plg_system_cache/ will never run. Cache, SEF, Redirect, Language Filter, Remember Me, and most authentication plugins have no frontend layout.
4. Optional confirmation: search the plugin PHP for getLayoutPath. If HTML is concatenated in the event method (return '<div>…'), the author did not make it overridable. Fork the plugin or ask the vendor. Do not patch core.

Developer note: the helper is JoomlaCMSPluginPluginHelper::getLayoutPath($type, $name, $layout = 'default'). The third argument is the file name without .php.

What you can do, and what you cannot

An override only replaces markup the plugin already prints through a layout. It does not become a second plugin. If the job is behaviour, routing, or a string, use a different Joomla tool.

What you can do

You can…	How
Restyle Prev/Next, vote, a field type	Copy tmpl into html/plg_{group}_{element}/
Change wrappers, classes, HTML5	Edit that PHP layout. Keep the variables the plugin passed in
Override a system plugin that prints UI	Same path: html/plg_system_{element}/ when tmpl exists
Override a fields plugin type	html/plg_fields_{type}/ (all fields of that type)
Override backend plugin HTML	Administrator child of Atum, same plg_ folder
Override a JLayout the plugin calls	html/layouts/…, not html/plg_…
Keep the change through Joomla updates	Put the file in a child template
Hide or reorder bits that are already in the layout	Comment out or move the HTML in your copy

What you cannot do

Joomla does not scan html/plg_* for every plugin. It only looks there when the plugin calls getLayoutPath() (or a JLayout helper) to include a file. If that call never happens, your copy is never loaded. That is the whole “why” for most of the rows below.

You cannot…	Why	Do this instead
Override a plugin with no tmpl	There is no layout file to swap. SEF, cache, and Redirect never include PHP from html/. A folder named plg_system_sef is ignored.	Parameters, CSS, or a custom plugin on the same event
Override HTML built as a string in PHP	return '<div>…' never asks getLayoutPath. The template search never runs.	Ask the vendor for a tmpl, or fork the plugin
Turn the plugin on or off	Enable, access, and ordering live in #__extensions / the Plugins screen. Layouts do not run that code.	System → Plugins
Change SEF, 301s, cache, language filter	Those plugins rewrite URLs or headers. They do not print a view.	Plugin options, .htaccess, com_redirect
Prev/Next on one article only	One layout file serves every article that plugin runs on. Joomla has no “this menu item uses that plugin tmpl” dropdown.	CSS for that page, a module, or an article override
One custom field, not the type	plg_fields_text is the type plugin. Every text field shares that tmpl. Field id is data, not a layout name.	Custom fields display, or {field ID}
Change “Read more” or button labels	Those strings go through Text::_() and language files. The layout only prints whatever translation returns.	Language override
Change the article body	com_content renders the article. The plugin injects extra HTML later. Different search path: html/com_content/, not html/plg_.	Article (or category) layout override
Change a module chrome	Modules use html/mod_*. Plugin helper never looks there.	Module override
Pick an alternative layout like a module	Modules register extra files in a form field. Most plugins hardcode 'default' (or 'vote') in PHP. Extra files in tmpl/ are unused unless that string changes.	Override the layout the PHP already names
Auto-merge after a plugin update	Joomla copies nothing into your html/ file. Your copy wins forever, including stale variables.	Diff against the new tmpl after each update
Keep PHP on a template style	A style is a row of parameters and menu assignment. It has no html/ directory.	Files in the template (child) folder
Make Create Overrides list the plugin	That screen is built from component views, modules, and known layout folders. Plugin tmpl is often omitted on purpose.	Create html/plg_{group}_{element}/ yourself
Use the site template for admin plugin HTML	Site and administrator are different CMS applications, different template roots.	Atum child: administrator/templates/{child}/html/plg_…

The pattern is the same every time: no layout lookup, no override. Group system is not a lock and not a key. Only the PHP that includes a file is.

How to name the html folder

templates/{template}/html/plg_{group}_{element}/{layout}.php

{group} is the first directory under plugins/ (system, content, fields, user, …). {element} is the plugin folder name (the element in the XML). Underscores in the plugin name stay. Prefix is always plg_.

Group	Typical override	Notes
content	html/plg_content_pagenavigation/default.php	Prev/Next on articles
content	html/plg_content_vote/vote.php	Also rating.php in the same folder
fields	html/plg_fields_text/text.php	Per field type, not per field id
system	html/plg_system_{element}/default.php	Only if that system plugin has tmpl
user	html/plg_user_{element}/…	Profile extras that ship layouts
editors-xtd	Rare tmpl	Buttons are often JS, not PHP layouts
privacy / MFA	Check tmpl	Captive or consent screens when they exist

Same formula. Different group name. The Create Overrides tab still may not show them.

Wrong folder names that fail silently:

• html/pagenavigation/ (missing plg_content_)
• html/plugins/system/example/ (that is not how Joomla looks up plugin layouts)
• html/plg_system_example/tmpl/default.php (no extra tmpl under html)

Site overrides go in the site template. Administrator plugin UI (if any) goes in an administrator template such as a child of Atum: administrator/templates/{atum_child}/html/plg_….

Put the file in a child template

Copying into Cassiopeia’s html/ works until Cassiopeia updates. Create a child first, assign its style, then add html/plg_… there. Setup: How to set up a Joomla child template.

A template style does not store PHP. Only the template folder does.

Step 1: Confirm the plugin is overridable

1. System → Plugins. Note Type (group) and Element (folder name).
2. On disk: plugins/{type}/{element}/tmpl/.
3. Open the main plugin class. Confirm getLayoutPath.
4. Note every layout file (default.php, vote.php, rating.php). You override only the files you copy. Missing files still load from the plugin.

Backup the site. An override with a PHP error blanks the page that loads that plugin.

Step 2: Create the html folder

On the active template (the child):

templates/{your_child}/html/plg_{type}_{element}/

Example for page navigation:

templates/cassiopeia_site/html/plg_content_pagenavigation/

FTP, hosting file manager, or System → Site Templates → {child} → html (create folder if the UI allows). The template manager will not invent plg_content_pagenavigation for you.

Manual folder. Then copy. Then cache. The public page does not change until the active template is the one that contains the file.

Step 3: Copy the layout and edit HTML only

Copy plugins/{type}/{element}/tmpl/{layout}.php into that folder. Same file name.

Change markup, CSS classes, wrapping. Keep the PHP that reads $displayData or the variables the plugin set up. If you drop a required variable, the layout fatals.

Do not copy the plugin class, XML, or language files into html/. Those are not overrides.

Step 4: Clear cache and prove the file is used

1. Assign the child template style to the menu item (or as default).
2. System → Clear Cache (and any page-cache plugin).
3. Add a harmless HTML comment or class in the override. View source. If it is missing, Joomla is not loading that file.

Then style for real.

Worked example: page navigation

Core plugin Content – Page Navigation. Group content, element pagenavigation.

	Path
Original	plugins/content/pagenavigation/tmpl/default.php
Override	templates/{child}/html/plg_content_pagenavigation/default.php

Enable the plugin. In the article Options (or menu item), show page navigation. Edit the override to wrap links in your button classes. This is the example every old tutorial uses. It still works on Joomla 5 and 6.

Worked example: article vote

Core plugin Content – Vote. Layouts include vote.php and rating.php.

templates/{child}/html/plg_content_vote/vote.php
templates/{child}/html/plg_content_vote/rating.php

Copy both if you change both. Copy one if you only restyle the form or only the stars.

Worked example: a custom field type

Field plugins live in plugins/fields/{type}/tmpl/. Override:

templates/{child}/html/plg_fields_{type}/{layout}.php

That restyles every field of that type. It does not restyle one field id. For one field, Automatic Display, {field ID}, or an article override is the custom fields path. For “Read more” text, use a language override, not a plugin layout.

System plugins: when html/ works

A system plugin that only listens (onAfterRender, onAfterRoute, headers, redirects) has no layout. Creating html/plg_system_redirect/ does nothing. Redirect rules stay in com_redirect.

A system plugin that prints a box, bar, or consent UI and ships tmpl/ uses the same formula:

plugins/system/{element}/tmpl/default.php
→ templates/{child}/html/plg_system_{element}/default.php

Third-party docs that show html/plg_system_mcnsystem/ are using this rule. Your vendor’s element name replaces theirs.

Debug, privacy consent, guided tours, and similar core tools may use tmpl or JLayout. Check the disk. Do not assume every system plugin in Joomla 6 gained a layout. Most still have none.

JLayout is a different folder

If the plugin (or core) calls LayoutHelper::render('joomla.content.…') or a namespaced layout, the override is:

templates/{child}/html/layouts/joomla/…

or the same tree the layout name implies under html/layouts/.

Do not put a JLayout file in html/plg_content_vote/ unless that is actually how getLayoutPath resolves it. Mixing the two folders is the usual “I copied it and nothing changed” bug after tmpl exists.

The Create Overrides tab does list many layouts/joomla files. Use it for those. Use a manual plg_ folder for plugin tmpl files.

Alternative layouts

Modules and articles can have extra files without underscores, chosen in a dropdown. Plugins almost never expose that dropdown. A second file in tmpl/ is used only if PHP asks for that layout name. For plugins, you normally override default (or vote / rating) in place. You do not get a “use my layout on this menu item” switch unless the plugin author coded one.

What a plugin override is not

Use the tables above. Short version: markup in a layout, yes. Events, routing, one-off pages, and language strings, no.

Troubleshooting

Symptom	Likely cause
Nothing changes	Wrong plg_{group}_{element} name, or no getLayoutPath
Nothing changes	Active style is still the parent, not the child that has html/
Nothing changes	Cache, CDN, or you edited a layout the plugin never loads
White screen	PHP error in the copied file
Breaks after update	Plugin tmpl added variables. Diff your copy against the new original
Works in HTML, not in admin	Site vs administrator template

After every extension update, diff override vs new tmpl. Plugin overrides are not merged automatically.

Key takeaways

1. Plugin overrides are real on Joomla 4, 5, and 6. They are usually manual.
2. Folder: html/plg_{group}_{element}/{layout}.php.
3. tmpl plus getLayoutPath means yes. No layout means no, including most system plugins.
4. You can change markup, classes, and field-type HTML. You cannot change plugin events, SEF, cache, or one article only.
5. System plugins that print HTML and ship tmpl use html/plg_system_{element}/.
6. Content vote, page navigation, and field types are the core examples you will actually use.
7. JLayouts use html/layouts/, not html/plg_….
8. Store the file in a child template. Re-diff after updates.

Frequently asked questions

Can I override a system plugin in the html folder?

Yes, if that system plugin has a tmpl file loaded with getLayoutPath. No, if it only hooks events and never includes a layout. The group name system does not block overrides and does not magically enable them.

Why is my plugin missing from Create Overrides?

Joomla’s override UI is built around component views, modules, and many layouts. Plugin tmpl files are often omitted. Create html/plg_{group}_{element}/ yourself.

Does this work the same on Joomla 5 and Joomla 6?

Yes. The helper and folder formula did not change. More core plugins may ship tmpl than in Joomla 3. Always check the folder on disk. Do not trust a wiki sentence that says only page navigation is overridable.

Can I override only one article’s page navigation?

Not with a plugin override. The override applies everywhere that plugin layout runs. For one page, CSS, a module, or a different article layout is the usual workaround.

Should I edit the plugin PHP instead?

No. Updates wipe it. If there is no layout, write a small custom plugin or use parameters. If there is a layout, copy it into the child html/ folder.

Where do administrator plugin screens get overridden?

In the administrator template, typically a child of Atum: administrator/templates/{child}/html/plg_{group}_{element}/. Site html/ does not apply to the backend.

Conclusion

Plugin HTML is overridable. The Create Overrides tab just does not advertise it. Test for tmpl, name plg_{group}_{element}, put the file in a child, and leave system plugins without layouts alone.

If you are still editing Cassiopeia html/ directly, create the child first. If the text is a language string, override the string. If the extra data is a field, custom fields plus a field-type plugin override cover display.

Need this done on a client template? Joomla design services.

Joomla custom fields are core extra data on articles, contacts, and users. They live at Content → Fields (and Field Groups) on Joomla 4, 5.4, and 6. They replace K2 extra fields: typed inputs, groups as editor tabs, values stored per item, optional automatic display on the public page. You do not need K2, a CCK, or a page builder for price, author bio, event date, or a specification table. If you still run K2, copy extra fields into this system on Joomla 3 first. That pipeline is the companion guide: Migrate K2 to Joomla articles before you upgrade.

This article is the feature how-to. The K2 article is the migration sequence. Read both if you are leaving K2. Read only this one if you already use com_content and need structured data on articles.

K2 stored extra data on items. Joomla stores the same idea on native articles, with groups, category assignment, and display you control.

What you will learn

• How custom fields differ from K2 extra fields (and from article body HTML)
• Field vs field group vs category assignment
• How to create a group, a field, and a value on an article
• Automatic display vs {field} in the body vs a layout override
• What a K2 migration copies, and what you still set by hand
• When a child template is the right place to print fields

How this guide and the K2 guide split the work

You need to…	Open
Move K2 items, categories, tags, images, and 301s, then upgrade 3 → 4 → 5 → 6	Migrate K2 to Joomla articles
Understand, create, assign, and display custom fields (including after that copy)	This article
Recover a site that already jumped to Joomla 5 with K2 still installed	K2 not working in Joomla 5 or 6

Migrate K2 Pro (phase 2) creates field groups, fields, and values from published K2 extra fields. It does not choose Automatic Display, rebuild your K2 item layout, or invent {field} shortcodes in the article body. Those jobs stay here.

Why custom fields exist (and why they beat extra fields)

K2 extra fields existed because Joomla 1.5 and 2.5 articles were title, images, and HTML. Magazines needed “Source,” “Duration,” “Price,” “GPS.” K2 bolted that onto com_k2.

Joomla 3.7 added custom fields to core. Joomla 4, 5, and 6 kept and extended them. Tags, nested categories, and workflows also moved into core. K2 did not follow Joomla 4. Extra fields therefore have no future as a platform. Custom fields do.

Custom fields are not a second article. They are named, typed, filterable values attached to an item. The editor shows them on a Fields tab, or on a tab named after the field group. The public site can print them automatically, or you print them in an override.

Use a field when the value is structured (a number, a list, a date, a media file, a yes/no). Keep narrative in intro/full text. Do not paste a spec sheet into TinyMCE if you will sort, filter, or style it later.

🔗 Joomla Docs: Adding custom fields (J5)
Official entry points: Content → Fields, Field Groups, and the context dropdown (Article vs Category).

K2 extra fields vs Joomla custom fields

Idea	K2	Joomla 4 / 5 / 6
Where you click	K2 extra field groups inside K2	Content → Fields and Content → Field Groups
Attached to	K2 items (and K2 categories in K2’s model)	Articles, article categories, contacts, users (separate contexts)
Grouping in the editor	Extra field groups	Field groups become tabs
Which items show the field	Tied to K2 extra field group assignment	Assigned categories (default All does not include Uncategorised)
Public output	K2 item template / extra fields block	Automatic Display, {field ID} in the body, or com_fields layouts
Survives Joomla 5 and 6	No	Yes
After Migrate K2 Pro	n/a	Groups, fields, and values exist. Display and category assignment still need a pass

Types are close, not identical. Confirm list options and media paths after a migration. Do not change a field type after it already holds data.

Approximate type mapping (what operators actually meet):

K2 extra field style	Joomla field type to expect
Text / header-style text	Text
Textarea	Textarea
Select / multiple select	List
Radio	Radio
Checkbox	Checkboxes or List (depends how K2 stored it)
Link	URL or Text
Date	Calendar
Image / media	Media
CSV / lists of pairs	Often List or Repeatable/Subform on a rebuild. Check values after migrate

If a migrated field looks wrong, do not flip Type on a live field with thousands of values. Create a new field, copy values if needed, and retire the old one.

Step 1: Create a field group

Groups are editor UX. They do not change the database value. They become tabs on the article form.

1. Content → Field Groups.
2. Set the context to Article (not Category, unless you are adding data to the category itself).
3. New. Title something editors will recognise: Specs, Source, Event.
4. Save.

No group means every field piles onto a single Fields tab. That is fine for two fields. It is miserable for twenty.

After a K2 migration, groups usually already exist. Rename titles for editors. Do not delete a group until you confirm no field still points at it.

Step 2: Create the field and assign categories

1. Content → Fields, context Article, New.
2. Title: what editors see.
3. Name: lowercase, no spaces. Used in overrides and {field} lookups. Set it once.
4. Type: pick before you save production data.
5. Field Group: the tab from Step 1.
6. Assigned Categories: All, or the categories that should show this field. Remember: All skips Uncategorised. If migrated K2 items landed in Uncategorised, assign that category explicitly or move the articles.
7. Required, default, filter: set now. Filter decides sanitisation (Text, Integer, HTML, Raw).
8. Save.

New articles show the field only after a category is chosen. That is normal. Joomla waits for the category so it can apply assignment.

Order: group (tab), field (type and name), category (where it appears), display (what visitors see).

Step 3: Choose how the public page prints the field

Automatic Display (on the field):

Setting	Where it injects
After Title	Between the title and the intro
Before Display Content	Above the article body
After Display Content	Below the article body
Do not automatically display	Nothing until you print it

A whole field group renders as one block, in field order, in that position.

Use automatic display for simple “label: value” lines (source, duration, licence).

Use Do not automatically display plus:

• {field 12} (field ID) in the article body when placement must differ per article, or
• a layout override when every article in a category needs a spec table, cards, or schema markup.

Overrides belong in a child template, typically under html/layouts/com_fields/ or in the article default.php if you print $this->item field arrays yourself. Editing Cassiopeia core files will be wiped on update.

Automatic display is the fast path. Overrides are the design path. Shortcodes are the one-off path.

K2 item templates that loop extra fields do not run after you uninstall K2. If the magazine layout was a two-column spec grid, plan the override before you delete html/com_k2. The values will be in custom fields. The HTML will not.

Step 4: After a K2 migration, walk the fields once

If you used Migrate K2 Pro:

1. Content → Fields and Field Groups. Counts should match published K2 extra fields and groups.
2. Open five articles. Fields tab (or the group tab) must show values, not empty inputs.
3. Set Automatic Display on the fields you want visitors to see without an override. Migration does not guess your old K2 item chrome.
4. Fix category assignment. If a field vanished from the editor, the article category is not in the assigned list (Uncategorised is the usual trap).
5. Spot-check media fields. Paths should point at images/k2-migrated (or your configured base), not media/k2/.
6. Rebuild the public layout: automatic display, then override if the design is more than a label list.

Permissions: if an editor cannot see a field, check the field’s Access and Display When Read-Only. That is not a migration bug.

What custom fields are not

You need to…	Use
Change “Read more” or module chrome	Language override
Change HTML structure of the article	Layout override in a child template
Move K2 items and URLs onto core	K2 to com_content migration
Store a novel in the article	Intro and full text, not a textarea field
Comments or file attachments from K2	Export from the migrator. Core fields can hold a file you attach later. They do not import K2 comment threads

Key takeaways

1. Custom fields are core. They are the replacement for K2 extra fields on Joomla 4, 5, and 6.
2. Group = editor tab. Field = type, name, value. Category assignment = which articles show the input.
3. Default All categories does not include Uncategorised.
4. Automatic Display prints a block. {field ID} places one value in the body. Overrides print a designed layout.
5. Migrate K2 Pro copies groups, fields, and values. You still set display and rebuild K2 item chrome.
6. Do not change Type on a field that already has production values.
7. Put field layout PHP in a child template, not in the parent.

Frequently asked questions

Are Joomla custom fields the same as K2 extra fields?

Same job, different system. Both attach typed data to content. Custom fields are core, work on Joomla 5 and 6, and use category assignment plus Automatic Display. Extra fields die with K2.

Do I create fields before or after I migrate K2?

Let the migrator create them from published extra fields, then adjust display and assignment. Creating a parallel set by hand first causes duplicate names and empty values. Manual field setup is for sites that never used K2.

Why is the Fields tab missing on a new article?

No category is selected yet, or the field is not assigned to that category. Choose the category. Check assignment. Remember Uncategorised is outside All.

Can I show a field only in an override, not above the article?

Yes. Set Automatic Display to Do not automatically display, then print the field in a child-template layout.

Will custom fields survive a Joomla 5 or 6 upgrade?

Yes. They are com_fields. K2 extra fields will not, because K2 will not. That is why the K2 migration runs on Joomla 3.10 first.

Can I use custom fields on contacts or users too?

Yes. Those are different contexts (Contacts → Fields, Users → Fields). Article fields do not automatically appear on contact forms. Create fields in the context you need.

Conclusion

K2 extra fields were a product. Joomla custom fields are the CMS. Create groups, assign categories, then decide display. If the data still lives in K2, migrate to articles first, then come back to this page and finish Automatic Display and the article layout.

Need both the copy and the field UI done on a large magazine? Joomla K2 migration services.

A Joomla language override is a per-language replacement for any string that the CMS prints through a language constant. In Joomla 4, 5.4, and 6.1 it lives at System → Manage → Language Overrides. It can change modules, components, plugins, templates, and core text. You do not need a translation field on each extension. If the PHP calls Text::_(), one override per language is enough.

This is still the right tool in 2026. The path is the same on Joomla 5.4 and Joomla 6. Login, Articles, plugins, Cassiopeia, Atum, and third-party extensions that follow Joomla practice all use it.

One screen. Five layers: modules, components, plugins, templates, and core strings.

What you will learn

• That overrides are not limited to modules
• Why UI text is a language constant, not an XML parameter
• How to create an override for Site vs Administrator
• How to find a constant when you only know the English words
• How to keep placeholders (%s, {name}) intact
• How overrides differ from multilingual associations and from editing language files

The problem Language Overrides solve

You publish a multilingual site. Italian visitors still see English on Forgot your password?, Read more, plugin messages, template tooltips, and administrator buttons.

You open the module, the article options, or the plugin. You look for “Italian label” on every string. It is not there. You duplicate modules per language, or you edit .ini files over FTP. The next update wipes the files. The extra module copies still show English on anything that comes from Text::_().

That is not a broken extension. Joomla does not store that chrome in each form. The code holds a constant. A language file supplies the words. If Italian has no override and no packaged it-IT string, Joomla falls back to English.

Language Overrides exist so you change any of those strings without touching the extension, and without cloning items just to change a word.

What you can override

One tool covers the whole CMS, as long as the text is a language constant.

Prefix	What it usually is	Examples
MOD_	Modules	Login, Menu, Breadcrumbs, any site or admin module
COM_	Components	Articles (COM_CONTENT_…), Contacts, Tags, Smart Search
PLG_	Plugins	System, content, user, search plugins
TPL_	Templates	Cassiopeia, Atum, commercial templates
JLIB_, JGLOBAL_, JERROR_	Core / libraries	Shared buttons, errors, pagination

If Debug Language shows a constant, you can override it. If the text is hardcoded in PHP, JavaScript, or an article body, this tool cannot see it. Article content still uses associations. Layout HTML still uses a template or module override.

A setting such as “filter by current language” decides which items show. It does not translate the word “Search.” Content language and UI language are different jobs.

How Joomla prints that text

Well-written Joomla code does not hardcode visitor-facing sentences. It holds a language constant. A .ini file maps that constant to text.

MOD_LOGIN_FORGOT_YOUR_PASSWORD="Forgot your password?"
COM_CONTENT_READMORE="Read more"

On an Italian page, Joomla loads it-IT files, then loads language/overrides/it-IT.override.ini last. Whatever is in the override file wins. The same last-file-wins rule applies in administrator/language/overrides/ for backend strings.

File	Role
mod_*.ini, com_*.ini, plg_*.ini, tpl_*.ini, joomla.ini	Packaged translations
*.sys.ini	Installer and Extensions list
xx-XX.override.ini	Your replacements. Loaded last. Survives updates

Site strings live under language/. Administrator strings live under administrator/language/. Mixing those two clients is the number one reason an override “does nothing.”

You do not invent keys. You reuse the key the PHP already calls.

🔗 Joomla User Manual: Language Overrides
Official rule: never edit core or third-party language files. Use the Language Override component.

What Language Overrides are not

You need to…	Use
Change any Text::_() string on the public site	Language Override, client Site
Change administrator wording	Language Override, client Administrator
Change English tone on a single-language site	Language Override for en-GB
Show different articles per language	Multilingual associations and the Language Filter plugin
Change HTML markup	Template, module, or component layout override
Protect template PHP and CSS from updates	Joomla child template
Translate article bodies	Associations or a translation workflow

Many tutorials use “override” to mean a layout copy inside a template. Language Overrides are a different tool. Same word, different folder.

Frontend wording uses client Site. Backend wording uses client Administrator. Mixing them is why an override often appears to do nothing.

Step 1: Open Language Overrides for the right language and client

1. Go to System → Manage → Language Overrides. (Joomla 3 used Extensions → Languages → Overrides. Ignore those screenshots.)
2. Choose the language you are translating into, for example Italiano (it-IT).
3. Choose Site if the text appears on the public page. Choose Administrator if it appears only in the backend.
4. Confirm the language pack is installed under System → Manage → Languages. You cannot override fr-FR if French is not installed.

Create one override row per constant per language. Italian, French, and German are three passes, not one field on the extension.

Find the constant, save the override, repeat per language, then verify on the translated URL.

Step 2: Find the language constant

If you already know the key from an .ini file or docs, skip to Step 3 and paste it into Language Constant.

If you only know the English words on screen:

1. Click New.
2. Set Search to Value.
3. Type the visible text, for example Forgot your password? or Read more.
4. Click Search. Pick the result whose constant matches the extension (MOD_…, COM_…, PLG_…, TPL_…, JGLOBAL_…).
5. Joomla fills Language Constant. You only edit Text.

If search returns too many hits or none: enable Debug Language in Global Configuration (next section), copy the constant from the page, then turn it off.

Do not guess a key. A truncated name saves and the page never changes.

Enable Debug Language in Global Configuration

Use this when Value search is messy or you cannot tell which constant belongs to which extension.

Turn Debug Language on in Global Configuration → System only while you copy keys. Turn it off before you leave.

1. Go to System → Global Configuration.
2. Open the System tab (not the Site tab).
3. Set Debug Language to Yes.
4. Optional: set Debug Language Constants to Constant if you want the raw key on the page, or Value if you want the translated text with debug markers.
5. Save & Close.
6. Open the frontend or administrator page that shows the English (or untranslated) string.
7. Copy the constant. Missing strings often look like ??CONSTANT??. Translated strings get marker characters around the words.
8. Return to Global Configuration → System and set Debug Language back to No. Save.

Leave it off in production. Debug Language changes the layout, exposes keys to visitors, and is easy to forget.

Do not confuse this with Debug System. That switch turns on the debug console. You only need Debug Language to hunt constants.

🔗 Joomla: Debugging a Translation
Official debug markers for missing vs translated strings.

Step 3: Create the override

1. Language Constant: paste the key in uppercase, exactly. No spaces.
2. Text: type the translation. Keep any placeholders (see Step 5).
3. Save. Repeat for the next key.
4. Match the client to where the text appears. Frontend strings are Site. Backend strings are Administrator.

On disk Joomla appends a line to:

language/overrides/it-IT.override.ini

or, for backend strings:

administrator/language/overrides/it-IT.override.ini

There is no overrides table in the database. Back up those files with the rest of the site. A database-only restore will not bring wording back.

Joomla loads core strings, then the extension .ini, then xx-XX.override.ini last. That is why your override wins.

Step 4: Repeat for every published language

If the site ships English, Italian, French, and German, you need four override sets for each constant you care about. English overrides are useful too: they let you change tone (“Read more” to “Continue”) without editing core files.

Switch the language filter on the Overrides list between en-GB, it-IT, fr-FR, and de-DE. Create the same keys in each. The constant stays identical. Only Text changes.

Install the language pack first. Creating de-DE overrides without German installed does not add German to the site.

Step 5: Keep placeholders exactly

Some strings are templates. Joomla injects a name, a number, or a date at runtime.

Core often uses Text::sprintf tokens:

COM_EXAMPLE_GREETING="Hello %s"

Italian can be Ciao %s. Keep %s (or %d, %1$s, %2$s) spelled exactly. Do not reorder bare %s placeholders unless you switch to numbered form (%1$s, %2$s).

Some extensions use named tokens in braces, for example {total} or {name}. Copy those from the original English string. If you translate the token itself ({totale}), the replacement never runs and visitors see the braces.

INI quoting: wrap the value in double quotes if you edit .override.ini by hand. A broken quote can take down every string after that line.

Step 6: Clear cache and verify on the translated URL

1. System → Maintenance → Clear Cache.
2. Hard-refresh. Use a private window if a CDN or browser cache is sticky.
3. Open the Italian (or French, German) page. Overrides follow the active language, not the language of your administrator session.
4. If nothing changed: wrong client (Site vs Administrator), wrong language tag, typo in the constant, Debug still on, or cached HTML.

Worked examples across Joomla

Same screen. Different prefixes.

Module (Login), client Site

Search Value for Forgot your password?. Constant: MOD_LOGIN_FORGOT_YOUR_PASSWORD. Italian Text: Hai dimenticato la password?.

Component (Articles), client Site

Search Value for Read more. Constant under COM_CONTENT_…. Override per language. It changes wherever that constant is used.

Plugin, client Site or Administrator

Search the plugin message you see. Constants start with PLG_. Site plugins that print on the frontend need client Site. Plugin option labels in the backend need client Administrator.

Template, client Site or Administrator

Cassiopeia and Atum strings start with TPL_CASSIOPEIA_ or TPL_ATUM_. Same override form. Do not edit the template .ini inside the template package.

Core / shared strings

Pagination, Save, Cancel, and many errors live in JGLOBAL_…, JLIB_…, or joomla.ini. One override can change a word in several extensions at once. Search Value, then check the constant prefix before you save, so you do not retitle something you did not mean to.

You never need a vendor-specific “language” tab for this. If the code uses Text::_(), Language Overrides already work.

How any standard extension supports this

An extension supports Language Overrides when it:

1. Calls Text::_('SOME_KEY') or Text::sprintf
2. Ships matching .ini files (mod_, com_, plg_, tpl_, or core joomla.ini)
3. Lets Joomla load those files

You do not enable a special “allow overrides” switch. Overrides always load last.

If the extension hardcodes <button>Submit</button> in PHP or JavaScript, Language Overrides cannot see it. Ask the developer to move the string into Text::_(). Until then, a layout override is the only hook, and updates can wipe it.

🔗 Joomla Programmers Documentation: Multilingual
How extensions ship .ini files and how Text::_() resolves constants.

Overrides versus editing language files versus content translation

Approach	Survives updates	Right for
Language Overrides	Yes	Any Text::_() string: modules, components, plugins, templates, core
Edit packaged .ini files	No	Never, except when you are the author shipping a language pack
Language pack from System → Manage → Languages	Yes, until you need custom wording	Baseline Italian, French, German for core
Falang or similar	Separate product	Article and some content fields, not a substitute for Text::_() chrome
Duplicate modules or menu items per language	Painful	Only when settings or layout must differ, not for translating a label

If the author already ships it-IT files, install that pack. Then override only the strings you want to change from their translation.

What not to do

• Do not assume only modules can be translated this way. Components, plugins, templates, and core use the same screen.
• Do not look for a language tab on every label. Standard Joomla chrome does not live there.
• Do not edit packaged .ini files in language/, administrator/language/, or inside the extension folder.
• Do not create the override under Administrator when the text is on the public site (or the reverse).
• Do not leave Debug Language on in production.
• Do not drop %s or {name} tokens from template strings.
• Do not confuse “show items in the current language” with translating UI words.
• Do not mix this up with child templates. Those protect PHP and CSS. These protect wording.

Key takeaways

1. Language Overrides can change any Joomla Text::_() string: MOD_, COM_, PLG_, TPL_, and core keys.
2. Path in 2026: System → Manage → Language Overrides. Client Site or Administrator. One language at a time.
3. Find keys with Value search or Debug Language. Paste the constant exactly.
4. Repeat for every published language. Clear cache. Check the translated URL.
5. You do not duplicate an extension just to change a label.
6. Overrides write language/overrides/xx-XX.override.ini (or the administrator copy). They load last. They survive updates.

Frequently asked questions

Can Language Overrides change more than modules?

Yes. Modules, components, plugins, templates, and core library strings all use the same tool. The constant prefix tells you which layer you are changing.

How do I translate Joomla UI into Italian or French?

Open System → Manage → Language Overrides, select that language and the right client (Site or Administrator), create an override for each constant, save, then clear cache.

Do all Joomla extensions support Language Overrides?

All that print text with Text::_() do. Core does. Third-party extensions that follow the same pattern do. Hardcoded English in PHP or JavaScript does not until the developer fixes it.

Why is there no language setting on each label?

Because Joomla already has a language system. Putting every string in every XML form would ignore the visitor’s active language and would not survive as a single place to edit.

Where are Language Overrides in Joomla 4, 5, and 6?

System → Manage → Language Overrides. Older tutorials still say Extensions → Languages → Overrides. That was Joomla 3.

Why did my override not change the page?

Wrong client (Site vs Administrator), wrong language (en-GB while you are viewing it-IT), typo in the constant, cache, or Debug Language still enabled.

What is Debug Language?

It is a Global Configuration switch. Go to System → Global Configuration → System, set Debug Language to Yes, save, copy the constants from the page, then set it back to No. Optional: Debug Language Constants chooses whether you see the key or the value.

Will a Joomla or extension update delete my translations?

Not if they live in Language Overrides. Updates overwrite packaged .ini files. They do not replace language/overrides/.

Can I change English wording without a second language?

Yes. Create overrides for en-GB. Same tool. Useful for tone (“Read more” to “Continue”) on a single-language site.

Conclusion

The missing Italian label is not a missing parameter on the module, component, or plugin. It is an untranslated language constant.

Create Language Overrides for every language you publish. Use the real keys, whether they start with MOD_, COM_, PLG_, TPL_, or JGLOBAL_. Keep placeholders. Clear the cache. Leave packaged .ini files alone.

One screen covers the whole site. Same files, same habit.

Related: How to Set Up a Joomla Child Template when the change is markup, not words. For core search, Basic Search to Smart Search in Joomla 5.

Migrate K2 to native Joomla articles on Joomla 3.10 first. Then uninstall K2. Then upgrade 3.10 to 4.4 to 5.4, and to Joomla 6 if your extensions allow it. K2 has no supported Joomla 4, 5, or 6 release. If you upgrade first, the component does not load and the items stay trapped in #__k2_* tables. Uninstalling K2 before a copy into com_content is how magazines lose URLs, extra fields, and images.

This is the 2026 operator path. It matches what we ship in Migrate K2 Pro and what the Joomla Community Magazine case study concluded for a 20,000 item news site: finish the content move on Joomla 3, then climb the core versions.

Use this article for the copy and upgrade. Use Joomla custom fields for extra fields after they land in core (groups, category assignment, Automatic Display, overrides). The migrator copies values. It does not rebuild your K2 item chrome.

Do the K2 work while the site still runs Joomla 3. Native articles travel with you on every later upgrade.

What you will learn

• Why K2 blocks Joomla 4, 5, and 6
• Why “uninstall K2 and hope” destroys SEO
• How K2 entities map onto com_content, custom fields, tags, and redirects
• How extra fields become custom fields, and where the custom fields guide takes over
• How to run Migrate K2 Pro on Joomla 3.10
• What to verify before you remove K2
• The upgrade ladder after native articles exist
• What the component does not copy (comments, attachments, author pages)

If K2 already exploded after a rushed Joomla 5 attempt, start with the recovery notes in K2 not working in Joomla 5 or 6, then come back here and do the move on a Joomla 3 staging copy.

Why you migrate on Joomla 3, not after the upgrade

K2 was a full content stack: items, nested categories, extra fields, tags, galleries, attachments, and its own image store under media/k2/. Joomla core later grew custom fields, tags, and nested categories. The K2 project did not follow Joomla 4.

So in 2026 the rule is mechanical, not philosophical.

1. K2 PHP only runs on Joomla 3.
2. Native articles, fields, and tags run on Joomla 4, 5, and 6.
3. Therefore the conversion has to happen while K2 still executes.

The JCM write-up put it in one sentence: migrate on the Joomla 3 site, then upgrade. That was true for a CLI script on 20,000 items. It is still true for a component that does the same mapping in the administrator.

Approach	What actually happens	Use it?
Upgrade first, keep K2	K2 fatal errors. Admin and site views that depend on K2 go blank. Data is still in K2 tables, but you cannot manage it.	No
Uninstall K2, then upgrade	Tables may drop or linger unused. Front-end URLs 404. Extra fields and media/k2 images have no articles attached.	No
Copy to articles on Joomla 3.10, then upgrade	Articles, fields, tags, images, and 301s exist in core. Later Joomla updates do not need K2.	Yes

Migrate K2 Pro is built for that third row. It is a Joomla 3.10 component. It reads K2. It writes Joomla articles. It does not rewrite K2 rows.

🔗 Migrate K2 Pro documentation
Installation, phases, field map, rollback, and the System Redirect plugin checklist.

What maps, and what does not

Treat this table as the contract. If a row is “migrated,” you should see it in core after a successful run. If a row is “export only,” plan a comment extension or a file pass before you delete K2.

K2	Joomla core	How Migrate K2 Pro handles it
Item	Article (com_content)	Title, alias, intro, full text, state, featured, dates, author, meta, hits, access, language
Category tree	com_content categories	Parent/child kept. Matching alias plus parent is reused, not duplicated
Extra field group	Custom field group (scoped to com_content)	Published groups only
Extra field + values	Custom fields + per-article values	Types mapped. media/k2 URLs inside values rewritten
Tag	com_tags	Published tags and article associations
Item image, caption, credits	Intro/full article image JSON	Files copied to the image base path (default images/k2-migrated)
Item URL	com_redirect 301	/component/k2/item/{id} and /component/k2/item/{alias}
Comments	No core article comments on Joomla 3	CSV, JSON, or SQL export only
Attachments	No core attachment field	Export with paths; attach later if you need files
K2 user / author page	No native equivalent	Authors on articles map to Joomla users. Profile pages need a new menu or a third-party directory

Copy entities into core. Do not leave SEO on K2 routers you are about to uninstall.

Readmore handling: if K2 fulltext is empty, the component splits introtext at <hr id="system-readmore" /> the way Joomla articles already expect.

Image credits go into Joomla’s image alt fields. Captions go into the intro/full caption fields. That is SEO-relevant. Check a sample of articles after the run.

How Joomla custom fields replace K2 extra fields

K2 extra fields were typed data on items: source, price, duration, a spec list. Joomla core now does that job with custom fields. Same idea. Different tables, different admin, a future on Joomla 5 and 6.

K2 extra fields	After a successful migration
Extra field groups	Content → Field Groups (editor tabs)
Extra fields + values	Content → Fields, values on the article Fields tab
K2 item template loop	Automatic Display, {field ID} in the body, or a com_fields override

Migrate K2 Pro phase 2 creates the groups, fields, and values from published extra fields. Media URLs inside values are rewritten. Unpublished extra fields are skipped.

It does not set Automatic Display to match your old K2 item layout. It does not put {field} shortcodes in the article HTML. It does not fix category assignment if articles landed in Uncategorised (Joomla’s “All” assignment skips that category). Those steps are the rest of the job.

Read Joomla custom fields: the K2 extra fields replacement next, or keep it open while you verify Step 5. Order of work:

1. This guide: backup, migrate, 301s, menus, uninstall K2, upgrade.
2. Custom fields guide: confirm groups, assign categories, choose display, rebuild the spec layout in a child template if the magazine was more than label:value lines.

If you never used extra fields, skip the second article until you need structured data on native articles.

Step 1: Stay on Joomla 3.10 and take a real backup

Work on a staging clone, not production, for the first pass.

1. Confirm System → System Information shows Joomla 3.10.x. If you are on an older 3.x, update Joomla 3 to 3.10 first. Do not jump to 4 yet.
2. Confirm PHP still satisfies both Joomla 3.10 and K2 (Migrate K2 Pro needs PHP 7.2 or higher).
3. Take a full Akeeba (or host) backup: files plus database.
4. Count K2 items, categories, tags, extra fields, comments, and attachments. You will match these numbers after the copy.

If production is already on Joomla 4+ with a dead K2, restore a Joomla 3 backup to staging and migrate there. Then plan a content merge. Guessing SQL on a Joomla 5 database is how you duplicate aliases and break menus.

Step 2: Audit aliases, authors, and menus

Do this before you click Start Migration.

• Alias clashes. If a Joomla article or category already uses the same alias as a K2 item or category, decide which one keeps the slug. Migrate K2 Pro reuses categories when alias and parent match. Articles are tracked in a mapping table so a resume does not duplicate. A leftover “News” category from core and a K2 “News” category still need a human look.
• Deleted authors. Set Fallback User in component options to a real Super User ID if K2 created_by points at deleted accounts.
• Trashed K2. Leave Skip Trashed on unless you truly need junk restored.
• K2 menu items. List every K2 item, category, tag, and user menu. After migration you replace them with Article, Category Blog/List, and Tagged Items types. The JCM table is the right map: K2 “Latest Items” becomes a category blog. K2 user pages have no core twin.
• Custom K2 SEF. If a third-party router used /blog/alias instead of /component/k2/item/alias, budget extra redirect rows. The component writes the two com_k2 patterns above. It cannot invent every historical SEF plugin path.

Export a K2 dump from the dashboard (CSV, JSON, or SQL) even if you plan to migrate. That archive is your proof if someone uninstalls K2 too early.

Step 3: Install Migrate K2 Pro and pass pre-flight

Download the current ZIP (v1.2.1 as of this writing) from JoomlaX or the Joomla Extensions Directory listing.

1. Extensions → Manage → Install, upload com_migratek2pro_vX.x.zip.
2. Open Components → MigrateK2 Pro.
3. Confirm the dashboard sees K2, item counts, media/k2/items, and media/k2/items/src.
4. Options: Image Base Path (default images/k2-migrated, must be writable), Skip Trashed, Fallback User.

Red banner “K2 not detected” means K2 is not in #__extensions or #__k2_items is missing. A partial uninstall is the usual cause. Restore K2 (or at least its tables) before you continue.

Order matters. Redirects and menu rebuilds happen after the copy, before you delete K2.

Step 4: Run the four migration phases

Create the backup warning acknowledgement, then start.

Phases always run in this order:

1. Categories. Nested tree. Existing alias+parent reused.
2. Custom fields. Groups and fields from published K2 extra fields.
3. Tags. Published tags only.
4. Items. Batched AJAX. Each item becomes an article, gets images, tags, field values, and two 301 rows.

Do not close the tab if you can help it. If you do, the dashboard shows “in progress.” Continue Migration resumes from the last successful batch. The mapping table is why you should not get a second copy of the same K2 id.

Timeouts: raise max_execution_time (60 seconds or more) and memory_limit (128M or more) if a batch dies. Use the log (WARNING / ERROR) instead of guessing.

Need to scrap a bad run? Reset & Remove Migrated Data deletes only what this component created: those articles, categories, tags, fields, field groups, and tagged redirects. K2 tables stay. Copied image files on disk stay (delete images/k2-migrated yourself if you want a clean folder). Then run again.

Step 5: Verify before you touch K2

Do not uninstall anything until this list is boring.

1. Content → Articles. Counts match K2 items (minus trash if skipped). Open ten random items: intro, full text, images, featured flag, publish dates.
2. Content → Categories. Tree matches K2. Descriptions and access levels.
3. Content → Fields and Field Groups. Extra field values on the article Fields tab. Then follow custom fields after migration for Automatic Display and Uncategorised assignment.
4. Components → Tags. Associations on articles.
5. Components → Redirects. Comment contains MigrateK2 Pro. Sample an ID URL and an alias URL.
6. Migration Log. No unresolved ERROR rows. Image-not-found warnings mean those files were already missing in media/k2.

301s only work if System Redirect is enabled. Creating the rows is not enough.

Step 6: Turn on redirects and rebuild menus

1. Extensions → Plugins → System – Redirect: enable it.
2. In Global Configuration, confirm URL rewriting and your .htaccess still match how the site ran under K2.
3. Recreate menus:

Old K2 menu type	New Joomla menu type
Item	Articles → Single Article
Categories	Articles → Category List
Latest Items	Articles → Category Blog
Tag	Tags → Tagged Items
Item form	Articles → Create Article
User / author page	No core type. Plan a Contacts or custom page

4. Point category blogs at the migrated categories, not leftover empty core categories.
5. Hit a handful of indexed K2 URLs in an incognito window. You want 301 then 200 on the article, not 404.

SEF plugins that rewrote K2 beyond com_k2 still need manual redirect rows. Add them now, while you can still open a K2 item and copy the public URL.

Step 7: Uninstall K2 only after the site no longer needs it

When articles render, menus work, and 301s fire:

1. Keep the CSV/JSON/SQL export off-site.
2. Uninstall K2 and K2-only modules, plugins, and templates that call K2 helpers.
3. Search the template for com_k2 overrides under templates/{name}/html/com_k2. Those files do nothing for com_content. Extra field loops in those files must become custom field display or a com_fields override. Use a Joomla child template so the next core update does not eat the layout. The custom fields guide covers Automatic Display vs override.
4. Uninstall Migrate K2 Pro when you are done. Uninstalling the migrator does not delete the articles. Run Reset first only if you intended to throw the copy away.

Step 8: Upgrade Joomla 3.10 to 4.4 to 5.4 (then 6)

Native articles ride the core updater. K2 does not. The ladder in 2026 is still:

Joomla 3.10 → 4.4.x → 5.4.x → 6.x (6 only if every remaining extension is compatible).

There is no supported jump from 3 to 5 or 3 to 6. Use the Pre-Update Check at each hop. PHP must move with the target (Joomla 5 and 6 want current PHP 8.x). Details: Joomla 3 to Joomla 4 upgrade and Joomla 5 upgrade.

Do this on staging first. After 4.4, confirm custom fields, tags, redirects, and article images. Then 5.4. Then 6 if the Pre-Update Check is clean.

Joomla 5.4 is the long-support line if a shop extension is not ready for 6. Joomla 6 is the current major if everything on the Pre-Update list agrees.

When a component is not enough

Migrate K2 Pro is the admin path for sites that can sit in the browser while AJAX batches run. The JCM project used a CLI script for 20,000 items plus a custom K2 plugin. That is the right call when:

• You have tens of thousands of items and a low max_execution_time you cannot raise
• A custom K2 plugin stored extra rows that are not extra fields
• You need a one-off field map ($cfMapping) that is not in the component

We still start those projects with the same entity table and the same “Joomla 3 first” rule. If you want that done as a service, use Joomla K2 migration services.

Key takeaways

1. K2 does not run on Joomla 4, 5, or 6. Native com_content does.
2. Convert on Joomla 3.10 while K2 still loads. Then uninstall K2. Then upgrade.
3. Uninstalling K2 without a copy is how you lose extra fields, media/k2 images, and rankings.
4. Migrate K2 Pro maps items, categories, extra fields, tags, images, and two 301 patterns per item. It never writes back into K2 tables.
5. Extra fields become custom fields. Display and layout are a second pass: Joomla custom fields.
6. Enable System – Redirect or the 301 rows do nothing.
7. Comments and attachments are export-only. Author pages have no core menu type.
8. After the copy, rebuild menus onto article and category types, then climb 3.10 → 4.4 → 5.4 → 6.

Frequently asked questions

Can I migrate K2 after I am already on Joomla 5?

Not with K2 running. K2 has no Joomla 5 release. Restore or clone a Joomla 3.10 copy that still has K2, migrate there, then bring native articles forward. If you only have a Joomla 5 database with leftover #__k2_* tables, you need a specialist extract, not the administrator component.

Does Migrate K2 Pro delete my K2 data?

No. It only reads K2 tables. Reset removes the Joomla articles, categories, tags, fields, and redirects it created. K2 stays until you uninstall it yourself.

Will my old K2 URLs keep ranking?

They can, if 301s exist and System Redirect is on. The component writes /component/k2/item/{id} and /component/k2/item/{alias}. Custom SEF layouts need extra rows. Rebuild equivalent article and category menu items so canonical URLs are clean going forward.

Are extra fields included?

Yes, for published K2 extra fields and their values. They become Joomla custom fields on com_content. Unpublished extra fields are skipped. Media paths inside values are rewritten to the new image folder. For groups, category assignment, Automatic Display, and overrides, use the custom fields replacement guide.

Do comments and attachments become Joomla comments and article files?

No. Export them. Joomla 3 has no core article comments. Attachments are files plus metadata. Import into a comment extension or a file field after you know the new article IDs.

How long does a migration take?

Small sites (hundreds of items) often finish in under a minute. Tens of thousands of items take minutes in the component, or hours in CLI on a large news archive. Batch size and server PHP limits dominate, not the mapping itself.

Should I go to Joomla 5.4 or Joomla 6 after K2 is gone?

Go to 4.4 first, always. Then 5.4. Choose 6 only when the Pre-Update Check and every remaining extension are ready. 5.4 is the safer landing if a cart or CCK is lagging.

Conclusion

K2 is not “almost Joomla 5.” It is a Joomla 3 content engine. The durable fix is native articles, created before you climb versions.

Install Migrate K2 Pro on Joomla 3.10, run the four phases, prove redirects, replace K2 menus, uninstall K2, then upgrade. Read the full documentation for logs, reset, and export formats. Then open Joomla custom fields and finish how extra field data actually shows.

If the site is large, customized, or already half-upgraded, ask Infyways to run the migration. The sequence does not change. The staging and field map just get done for you.

To set up a Joomla child template, open System → Site Templates, open an inheritable parent such as Cassiopeia, click Create Child Template, add only the files you will change, then assign the new style. You need Joomla 4.1 or later (5 and 6 included). Joomla 3 and 4.0 have no Create Child Template button.

Do this before you edit Cassiopeia. A child keeps your CSS, layout overrides, and extra positions when the parent updates. A template style duplicate does not.

This is a setup guide. You will create the child, put user.css in the right folder, add an override, assign it to a menu item, and know when to copy index.php.

The parent stays stock. Each child keeps only the files you change.

What you will set up

• A child of Cassiopeia (or another inheritable template)
• user.css that actually loads
• Optional HTML overrides and extra module positions
• A template style assigned as default or per menu item
• The Joomla 6 path if you already have Cassiopeia Extended
• How to make your own (or a fork you control) support children

The problem a child template solves

Most Joomla sites get slow to update for a boring reason: someone edited the parent template.

You change index.php or drop a user.css inside Cassiopeia. It looks fine. Then Joomla (or the club) ships a template update. Core files go back to stock. Your header colour, extra module position, and article override are gone. Restore from backup, or skip the update and sit on an unpatched template.

The usual workaround is worse. Duplicate the whole template, rename it “Cassiopeia custom,” and never touch the original again. You now maintain hundreds of files you did not write. The next Cassiopeia security fix never reaches that copy.

A template style does not fix this. Styles store parameters and menu assignment. They still point at the same parent files. Duplicate the style, change the logo, and you are fine. Edit PHP or CSS in the parent, and the next update still wipes it.

That is the problem. Custom look, stock parent, files that survive updates. Child templates are the core feature built for that, from Joomla 4.1 onward.

Why you set up a child instead of editing the parent

A template style only stores parameters and menu assignment. It still uses the parent’s files. Edit templates/cassiopeia/index.php and the next Joomla update puts the stock file back.

A child template is a second template. Same-named files in the child win. Everything else loads from the parent. Updates replace the parent. Your child folder stays.

Set up a child as soon as you need custom CSS, a layout override, extra positions, or a second look (home vs knowledge base vs portal). If you only need a different logo colour and no PHP, a style on the same template can be enough. The moment you touch a file Joomla will overwrite, create the child first.

Assigning styles to pages is covered here: How to Change Template in Joomla 4.

A style stores params. A child stores files. You usually need both: create the child, then assign its style.

Benefits of a Joomla child template

Here is why this is worth the extra click.

• Updates stop wiping your work. Joomla can patch Cassiopeia (or your club parent). Your user.css, overrides, and extra positions stay in the child folder.
• You keep a stock parent. Security and accessibility fixes in the core template actually get installed. You are not sitting on a frozen fork named “Cassiopeia copy 3.”
• The child stays small. You duplicate one file, not the whole template. Less to maintain, easier to see what you changed.
• Several looks, one parent. Homepage, knowledge base, and logged-in portal can each have a child. Same Cassiopeia under them, different CSS or index.php.
• Overrides stop fighting the vendor. If the parent already ships html/com_content/article/default.php, you override it in the child. A parent update refreshes their copy. Yours stays.
• The administrator can match the brand. Atum is inheritable. A child of Atum can add a client logo or hide clutter without forking the backend template.
• You can still use styles. Logo, colour params, and menu assignment stay on the style. The child protects files. Together they cover look and safety.

A child is not a speed plugin and not a page builder. It does not replace PHP 8, a CDN, or image work. It replaces the habit of editing files Joomla will overwrite.

Before you click Create Child Template

1. Version. System → System Information. You need 4.1.0 or newer. Joomla 5.4 and 6.1 both work.
2. Backup. A child is safe. Deleting the parent later is not.
3. Parent must be inheritable. Open the parent’s templateDetails.xml and confirm <inheritable>1</inheritable>. Cassiopeia (site) and Atum (admin) have it. Many older commercial templates do not. If the button is missing, this is why.
4. Work from Templates, not Template Styles. Styles assign. Templates create children.

On Joomla 3, stop here. There is no native child. Migrate first: Joomla 3 to Joomla 6 Upgrade.

🔗 Joomla User Manual: Child Templates
Official clicks: create the child, add user.css, assign a menu item.

Do these in order: create, CSS, override (if needed), assign. Creating the child does not change the public site until you assign the style.

Step 1: Create the child from the parent

1. Go to System → Templates → Site Templates.
2. Open Cassiopeia Details and Files (or your inheritable parent).
3. Click Create Child Template.
4. Type a short name, for example brand or portal. Joomla prefixes the parent. You get cassiopeia_brand.
5. Create, then Close the parent.
6. Open cassiopeia_brand Details and Files.

You should see a folder tree and almost only templateDetails.xml. That emptiness is correct. Do not copy the whole parent in.

Joomla 6.1 extra: if you already use Cassiopeia Extended and want a second variant, open that child and use Copy Child Template instead of creating from Cassiopeia again. Then check that /templates/your_child and /media/templates/site/your_child use the same element name. If the editor says the directory is not writable, the media folder name is usually wrong. Rename it to match, or recreate the child on the current 6.1 patch.

Administrator child: same flow under System → Administrator Templates, parent Atum. Assign that style afterward if you want a branded backend.

Step 2: Know where your files must live

Put files in the child, not in Cassiopeia.

PHP, XML, and html/ overrides live under templates/your_child/. CSS, JS, and images live under media/templates/site/your_child/. The Template Editor css folder is the media folder.

What you are changing	Put it here (example child cassiopeia_brand)
Manifest, extra positions	templates/cassiopeia_brand/templateDetails.xml
index.php, error.php	templates/cassiopeia_brand/ only if you copy them
Component and module overrides	templates/cassiopeia_brand/html/…
CSS, JS, images, scss	media/templates/site/cassiopeia_brand/

The Template Editor’s css folder is the media CSS folder. It is not templates/cassiopeia/css/ on Joomla 4.1, 5, or 6. If user.css sits in the old 4.0 path, the site ignores it.

Leave the parent XML as inheritable. The child XML should look like this (simplified):

<inheritable>0</inheritable>
<parent>cassiopeia</parent>

If you zip the child for another site, change the template name and the media destination together.

Step 3: Add user.css (do this on almost every site)

Cassiopeia loads user.css last when the file exists in the child.

1. In the child, click New File.
2. Select the css folder.
3. Filename: user with no .css in the name field. File type: .css.
4. Create, then paste your rules. Save.

Starter example:

.container-header {
  background-color: darkgreen;
  background-image: none;
}

h1, h2, h3 {
  color: darkgreen;
}

Clear Joomla cache and the browser cache, then view a page that uses this child’s style. If nothing changes, you assigned the wrong style, or the CSS file is not in the child’s media folder.

On Joomla 6 with Cassiopeia Extended assigned: use Colour Settings and Font Settings on the style first. Those write CSS variables such as --headerbg and --link-color. Add user.css only for rules the params cannot do. You can still use those variables inside user.css.

🔗 Cassiopeia Extended colour and font options
How the core Joomla 6 child adds params without you forking Cassiopeia.

Step 4: Add a layout override in the child

Do not edit overrides inside Cassiopeia. Create them in the child.

1. Open the child Details and Files.
2. Open the Create Overrides tab.
3. Pick the component or module, for example com_content → article.
4. Joomla copies the layout into the child’s html/ folder.
5. Edit that file. Save.

Typical path: templates/cassiopeia_brand/html/com_content/article/default.php.

If the parent already ships an override, still create yours in the child. A parent update can replace the parent’s html/ files. It will not replace the child’s.

Step 5: Copy index.php only when chrome must change

Skip this step if CSS and overrides are enough.

Copy index.php into the child when you need extra module positions, a different grid, or extra Web Assets. Prefer requiring the parent instead of pasting a full fork.

Cassiopeia Extended does this: it loads Cassiopeia’s index.php, then registers extra CSS. The idea in the child is:

defined('_JEXEC') or die;

require JPATH_THEMES . '/cassiopeia/index.php';

$wa = $this->getWebAssetManager();
// register extra styles or scripts here

Need custom JavaScript? Put a JS file in the child’s media js folder and register it, or follow How to Add Custom JavaScript to Joomla. Do not drop a raw <script> into a copied index.php unless you have no other hook.

Step 6: Add a module position (only if the layout needs it)

1. Edit the child’s templateDetails.xml.
2. Add a <position>brand-hero</position> (use your name).
3. If index.php is not in the child yet, copy it, then add:

<jdoc:include type="modules" name="brand-hero" style="html5" />

4. Save both files.
5. In Content → Site Modules, the new position should appear.

XML without the jdoc:include lists the position in the manager and never prints it on the page. Do not remove parent positions that modules still use. You will get an empty region and no error.

Step 7: Assign the child on the front end

Creating the child does not change the public site.

1. Go to System → Templates → Site Template Styles.
2. Open the style for the child (often cassiopeia_brand - Default).
3. Rename it to a human label, for example Cassiopeia Brand.
4. Either set it as default, or open Menu Assignment and tick the items that should use it.
5. Save. Open those URLs logged out.

Home can stay on Cassiopeia. A landing page can use the child. Same assignment model as any other template.

Step 8: Check the result and cache

1. View source or the Network panel and confirm user.css loads from /media/templates/site/cassiopeia_brand/css/ (your child name).
2. Confirm the override markup on an article if you added one.
3. System → Maintenance → Clear Cache, then a hard refresh.
4. Update Joomla on staging and confirm the child files are still yours.

If CSS never loads, the file is in the parent, the style is wrong, or a CDN is serving an old sheet. Child templates do not replace hosting and image work. For that stack use How to Speed Up a Joomla Website in 2026.

Which setup to use

You need to…	Set up
Colour, font, spacing	Child user.css, or Joomla 6 colour/font params
Different article or module HTML	Child html/ override (Create Overrides)
Extra positions or extra assets	Child index.php that requires the parent when possible
Logo or brand colour per menu item, no PHP	Template style on the same template
Second full look that survives updates	Second child, then assign styles
Branded administrator	Child of Atum, then assign the admin style

What not to do while setting up

• Do not edit Cassiopeia or Atum “just this once.” Create the child first.
• Do not copy every parent file into the child. That is a fork. You will skip updates.
• Do not uninstall the parent while children exist.
• Do not assume a commercial template is inheritable. Check <inheritable>1</inheritable>.
• Do not put user.css under templates/cassiopeia/css/ on 4.1+.
• Do not treat Cassiopeia Extended as a parent to hack. It is already a child. Copy it on 6.1, or create a new child of Cassiopeia.

Building a new inheritable parent is a different job. The Joomla template generator scaffolds that XML flag. It does not convert an old Helix or Protostar fork by itself, and it does not replace Create Child Template.

Make any template support child templates

Any Joomla 4.1+ template can support child templates if the parent opts in. Cassiopeia and Atum already do. A club template does not, until its templateDetails.xml says so and its CSS, JS, and images live under media/.

This is a parent-template change. You need the source (your template, or a fork you are allowed to change). You cannot turn Helix into an inheritable parent by creating a child of Cassiopeia.

Work on a copy. Package it as a template update. Test on staging.

🔗 Child templates are opt-in (dGrammatiko)
The feature author: inheritable XML, media folder, and the PHP path mistakes that break children.

1. Confirm the button is really missing

Open System → Site Templates, then the parent Details and Files. If Create Child Template is there, stop. The parent already supports children. Go to Step 1 of this article.

If the button is missing, open templateDetails.xml. No <inheritable>1</inheritable> means this parent cannot have children yet.

2. Mark the parent as inheritable

In the parent’s templateDetails.xml add (or set):

<inheritable>1</inheritable>

Leave it off the child. Children use:

<inheritable>0</inheritable>
<parent>yourtemplate</parent>

yourtemplate must match the parent’s folder name, for example cassiopeia or acme.

3. Move CSS, JS, and images into media

Child templates expect static assets in Joomla’s media tree, not only inside templates/yourtemplate/css/.

In the install package, put css, js, images, and scss under a media/ folder, then declare:

<media destination="templates/site/yourtemplate" folder="media">
  <folder>css</folder>
  <folder>js</folder>
  <folder>images</folder>
  <folder>scss</folder>
</media>

After install, files land at media/templates/site/yourtemplate/. For an administrator template, use templates/administrator/yourtemplate as the destination.

Keep PHP chrome (index.php, error.php, html/) in templates/yourtemplate/. That split is the same as Cassiopeia.

4. Stop building URLs with $this->template

A child has a different folder name. If the parent does this, the child’s CSS and logos miss:

$path = $this->baseurl . '/templates/' . $this->template . '/images/logo.svg';

Point at the parent media path, or register files in joomla.asset.json / the Web Asset Manager:

$path = 'media/templates/site/yourtemplate/images/logo.svg';

PHP includes have the same trap. Include the parent file, not a path that uses $this->template:

include JPATH_THEMES . '/yourtemplate/base.php';

If you skip this step, Create Child Template may appear and the site still looks unstyled.

5. Reinstall or update so the database matches

Saving XML in the Template Editor is not always enough. Joomla also stores inheritability on the template style row.

Install the updated package (or copy files, then reinstall with method="upgrade"). After that, Create Child Template should show on the parent.

If the XML looks right and the button is still missing, the #__template_styles row for that template may still have inheritable set to 0. Fix it on staging, then reload the Template Manager. Do not guess at production SQL.

6. Create the child the normal way

Use Step 1 in this article on the new parent. Custom CSS goes in the child’s media css folder. Cassiopeia auto-loads user.css. Your template might not. If it does not, register that file in the parent (or in a thin child index.php that requires the parent) so the child sheet actually prints.

Club templates you cannot fork: ask the vendor for a 4.1+ inheritable build, or keep their documented custom-CSS field. Do not paste <inheritable>1</inheritable> onto a live Helix package that still stores CSS under templates/.

🔗 templateDetails.xml (Joomla Programmers Documentation)
Official inheritable and media elements for a parent template.

🔗 JCM deep dive on child files and positions
Media destinations, extra positions, and child vs override.

Key takeaways

• Create the child from Site Templates, add only what you change, assign it under Template Styles.
• Benefits: updates do not wipe custom CSS and overrides, the parent stays stock, you can run several looks, and Atum can have a child too.
• You need Joomla 4.1+. Cassiopeia and Atum are inheritable. Joomla 6 ships Cassiopeia Extended as a ready child.
• user.css belongs in the child’s media CSS folder.
• Overrides belong in the child’s html/ folder, created from Create Overrides.
• Copy index.php only for chrome and positions. Prefer requiring the parent.
• Styles assign. Children protect files. You usually set up both.
• Any template can be a parent if it ships <inheritable>1</inheritable>, assets under media/templates/…, and paths that do not depend on $this->template.

Frequently asked questions

How do I create a Joomla child template?

Open System → Site Templates, open Cassiopeia (or another inheritable parent), click Create Child Template, name it, then close. Open the new template, add files, then assign its style under Site Template Styles.

What problem do Joomla child templates solve?

Edits inside Cassiopeia (or any parent) disappear when that template updates. Duplicating the whole template avoids the wipe but blocks future parent fixes. A child keeps only your files, so the parent can still update.

Why use a Joomla child template?

So Joomla can update the parent while your CSS, layout overrides, and extra positions stay in a separate folder. You also get more than one look from the same parent, and you can brand Atum the same way.

Which Joomla version do I need?

Joomla 4.1.0 or later, including Joomla 5 and 6. Joomla 3 and Joomla 4.0 have no Create Child Template button in core.

Why is the Create Child Template button missing?

You are below 4.1, or the template is not inheritable. Open templateDetails.xml and look for <inheritable>1</inheritable>.

Where do I put user.css?

In the child, New File → css folder → filename user → type .css. On disk: media/templates/site/your_child/css/user.css.

Is a child template the same as a template style?

No. Create the child under Templates. Assign it under Template Styles (default or Menu Assignment). You need both for the public site to change.

Do I have to copy index.php?

No. Most setups only need user.css and maybe one override. Copy index.php when you add positions or change page chrome. On Joomla 6, try Cassiopeia Extended’s colour and font tabs first.

Can I set up a child of the administrator template?

Yes. System → Administrator Templates → Atum → Create Child Template, then assign the admin style.

What if my commercial template has no child button?

It is probably not inheritable. Use the vendor’s custom CSS feature, ask them for a 4.1+ inheritable build, or switch to an inheritable parent. Do not only add <inheritable>1</inheritable> if CSS still lives under templates/.

How do I make my own template support child templates?

On the parent: set <inheritable>1</inheritable>, move CSS, JS, and images into media/ with a <media destination="templates/site/yourtemplate"> block, stop building URLs with $this->template, then reinstall so the style row updates. After the Create Child Template button appears, create the child as usual.

Conclusion

Setup is the whole point. Create the child, put user.css in the media CSS folder, add overrides in the child’s html/ folder, assign the style, leave the parent stock.

Do it on staging today. One menu item is enough to prove it. Then stop editing Cassiopeia.

If the parent is a custom Joomla 3 fork with no inheritable flag, Infyways Joomla design and Joomla upgrade set this up as a cutover: stock parent, thin child, files you can still explain in six months.

To speed up a Joomla website in 2026, fix Time To First Byte and images first, then JavaScript. Google ranks field Core Web Vitals (LCP, INP, CLS), not your one-off Lighthouse screenshot. Joomla 5 and 6 already have cache, Gzip, and the Web Asset Manager. Most slow sites are still on PHP 7, uncompressed images, Progressive cache on a logged-in shop, or five minify plugins fighting each other.

The 2023 version of this URL was a long “10 ways” list. That list still works. The destination changed. FID is gone. INP is the interactivity metric. Cassiopeia and modern templates load almost no jQuery unless an old extension drags it in. If you only enable Conservative Caching and call it done, you will not win a PageSpeed argument.

This is the order we use at Infyways on Joomla 4, 5, and 6 (current 6.1.3 / 5.4.8). For a full optimization project, see Joomla website optimization.

What you will learn

• Why lab scores lie and Search Console field data does not
• Conservative vs Progressive vs System Page Cache, without breaking logins
• What actually moved in Joomla 5 and 6: Web Asset Manager, PHP 8.3, less default JS
• The image and INP work most “speed up Joomla” posts still skip

What “fast” means in 2026

Metric	What Google wants (good)	Usual Joomla cause when it fails
LCP	Largest content paints quickly	Hero JPEG, no dimensions, slow TTFB
INP	Clicks respond in about 200 ms or less	Heavy JS, jQuery stacks, chat widgets
CLS	Layout stays still	Images without width/height, late fonts, ads
TTFB	Server answers fast	PHP 7, no cache, distant origin, huge SQL

Use PageSpeed Insights and Search Console together. The top of PSI is field data when Google has enough traffic. Lighthouse below that is a lab story on a simulated phone. A green lab and a red field report means your real visitors are slower than the test. Trust the field numbers for ranking.

Test tools still worth a pass: PageSpeed Insights, GTmetrix, WebPageTest, and your host’s TTFB. They do not replace Search Console.

Step 1: Measure one URL, logged out, on mobile

Pick the homepage and one heavy inner URL (product, article with modules). Test logged out. Logged-in administrator pages will always look worse. Note LCP element (usually the hero image), unused JavaScript, and TTFB. Do not change ten settings at once. You will not know what helped.

Step 2: Put PHP and the host on Joomla 6 footing

Joomla 6 expects modern PHP (8.3 on the official 5 to 6 path). Shared hosting on PHP 7.4 will lose to a cheap VPS on 8.3 with OPcache. HTTP/2 or HTTP/3, SSD, and a region near your users beat another caching plugin.

If you are still on Joomla 3, speed work is a delay tactic. Upgrade path is in Joomla 3 to Joomla 6.

Step 3: Turn on Joomla cache the way the site actually works

Global Configuration, System tab, Cache Settings:

• Conservative Caching: safe default. Modules can still vary. Use this on shops, membership, and anything with a cart or login.
• Progressive Caching: more aggressive. Fine for a brochure site that is identical for every guest. It will show the wrong module to the wrong user if you sell or personalize.
• Cache Handler: File is fine on small sites. Redis or Memcached if the host actually runs them. Do not pick Redis because a blog said so.
• Cache Time: start around 15 minutes. Raise it if content barely changes.

Separately, the System, Page Cache plugin caches full HTML for guests. That is often the biggest Joomla-native win. Exclude cart, checkout, and account pages. Purge cache after template or extension updates.

Module-level cache helps repeating chrome (menus, footers). Do not cache a module that shows the logged-in name.

Step 4: Compress on the server, then confirm in Joomla

Gzip in Global Configuration, Server tab, still matters if the host is not already sending Brotli or Gzip. Many Nginx stacks already compress. Enabling Gzip twice does nothing useful. Confirm in the response headers (content-encoding: gzip or br). Walk through the admin toggle in test and enable Gzip in Joomla. If the host offers Brotli, prefer it at the server and leave Joomla Gzip off to avoid double work.

Also send long cache-control for /media, /templates, and images. Joomla’s Web Asset Manager appends a version query when assets change, so long browser cache is safe if you actually use WAM. See the Web Asset Manager docs.

Step 5: Fix LCP, which is usually an image

Resize the hero to the largest size you display. Serve WebP or AVIF with a fallback. Set width and height so CLS does not jump. Lazy-load below the fold only. Never lazy-load the LCP image.

A 4000px PNG in a 720px column will beat any cache plugin. If you want that conversion inside Joomla, our JoomlaX WebP/AVIF tools exist for that job. CDN the /images tree after the files are small.

Step 6: Cut JavaScript until INP recovers

Joomla 4+ templates should not ship jQuery for decoration. If the page still loads jQuery, an extension asked for it. Unpublish sliders, live chat, and “add to any” buttons you do not use. One chat widget can wreck INP on mobile.

Do not install three CSS/JS minify extensions. They race, break Web Asset Manager order, and duplicate HTTP requests. Pick one approach: a capable template, or one well-supported optimizer, or Cloudflare’s rocket features, not all three.

Defer non-critical JS. Keep first click handlers light. INP is about the worst interaction on the page, not the first paint only.

Step 7: Use a CDN for bytes, not as a substitute for PHP

Cloudflare, Bunny, or Fastly help static files and TTFB for distant users. Purge after deploys. Page rules that cache HTML for logged-in cookies will leak carts. Cache /media and images aggressively. Be careful with HTML at the edge on Joomla sites that set cookies on first view.

Step 8: Clean the CMS so the cache has less to store

• Uninstall unused extensions. Disabled plugins still load in some stacks. Uninstall.
• Keep Joomla on 6.1.3 or 5.4.8. Old 3.x PHP loops are slow and unsafe.
• Limit modules in the header. Every module is queries and HTML.
• Turn off debug and uncompressed scripts on production.
• Database: delete expired sessions, old banner tracks, and leftover #__session bloat if the host shows huge session tables.

What not to do

Habit	Result
Progressive cache on a shop	Wrong prices or a logged-in module on a guest page
Five “speed” plugins	Broken CSS, duplicate jQuery, worse INP
Lazy-loading the logo and hero	Worse LCP
Chasing 100 on Lighthouse desktop	You ignore mobile field data
Gzip plus Brotli plus a minify CDN plus JCH	Unreadable CSS and no way to debug

Key takeaways

1. Speed up Joomla for LCP, INP, and TTFB, not a vanity lab score.
2. Conservative cache plus Page Cache for guests beats Progressive cache on personalized sites.
3. Images and PHP version usually beat another minify extension.
4. Use the Web Asset Manager. Stop injecting raw script tags in the template.
5. One optimizer stack. Then re-measure the same URLs.

Frequently asked questions

How do I speed up a Joomla website in 2026?

Measure field Core Web Vitals, raise PHP, enable Conservative Caching and guest Page Cache if the site allows it, compress responses, shrink the LCP image, and remove extra JavaScript. Then retest the same URLs.

What is the difference between Conservative and Progressive Caching?

Conservative caching is the safe default and respects module variation. Progressive caching stores more aggressively and is for sites that look the same to every guest. Do not use Progressive on carts, membership, or personalized modules.

Does Gzip speed up Joomla?

It reduces HTML, CSS, and JS bytes if the server was sending them raw. If Nginx already sends Brotli or Gzip, turning it on in Joomla will not magically double the gain. Check response headers.

Will a caching plugin replace a slow template?

No. Cache serves the same heavy HTML faster the second time. It does not fix a 2 MB hero or 400 KB of jQuery plugins on first view.

Is Joomla 6 faster than Joomla 3?

A current 6.x site on PHP 8.3 with Web Asset Manager is in a different league than Joomla 3 on PHP 7. The CMS version alone is not a PageSpeed plugin. You still have to size images and modules.

Conclusion

Speed work on Joomla is a sequence: measure, host, cache, compress, images, JavaScript. Skip the sequence and you get a graveyard of speed extensions. If you want that sequence run as a project, use Joomla website optimization and keep the site patched under support.

To repair a hacked Joomla website you must do two jobs, in order: remove the attacker’s persistence (files, database rows, rogue users, extra JCE profiles, .htaccess redirects), then close the hole they used (outdated core or a vulnerable extension). Patching alone leaves webshells. Cleaning alone gets you reinfected overnight.

Most guides still tell you to “scan with Sucuri, delete junk PHP, update Joomla 4.” That was incomplete in 2023. In August 2026 it is dangerous. Joomla 5.4.8 and 6.1.3 shipped on 18 August 2026 with core security fixes. JCE’s CVE-2026-48907 is on CISA’s Known Exploited Vulnerabilities list. Unpublishing a component does not remove its PHP. Overwriting a Joomla 3 tree with a Joomla 6 zip will not “clean” the site. It will break it.

This is the cleanup sequence we use at Infyways when a live Joomla shop, membership site, or brochure site is already serving malware. It is written for Joomla 4, 5, and 6. It is not a how-to-hack article. If you need hands-on help, use Joomla support and maintenance after you have a forensic copy of the infected files.

What you will learn

• How to tell a real compromise from a slow host or a plugin conflict
• The 2026 entry points other articles skip (JCE profiles, VEL, core CVEs fixed 18 August 2026)
• A step-by-step repair that does not destroy logs or restore an infected backup
• How Google Safe Browsing, Search Console, and “request a review” actually differ

What most Joomla malware guides get wrong

Advice you keep seeing	What actually happens
Run an online scanner, then go live	External scanners miss PHP webshells that never render to Googlebot
Update Joomla and you are done	The backdoor is still in /images, a template override, or a rogue Super User
Unpublish the vulnerable extension	The files still execute if the attacker hits the old URL. Official Joomla docs say uninstall, do not merely unpublish
Restore last night’s Akeeba backup	If the backup ran after the hack, you restore the malware
Upload the newest Joomla zip over the site	Wrong major version bricks the CMS. Match the installed major, then upgrade on a clean tree
Only scan PHP for eval and base64	Spam and redirects often live in JavaScript, .htaccess, modules, and article HTML

Joomla’s own checklist is still the baseline: treat the incident as a full compromise, check the Vulnerable Extensions List, and do not confuse a core refresh with a same-series repair. See You have been hacked or defaced and why unpublishing is not enough.

How to know a Joomla site is actually hacked

You do not need a dramatic defacement. In 2026 the quiet infections are the ones that kill SEO: hidden spam, Japanese or pharma links in modules, redirects for Googlebot only, or a new Super User that never logs in from your country.

• Google Search Console Security issues, or a Safe Browsing interstitial
• Host ticket: “malware detected, site suspended”
• Users you did not create, especially Super Users with a fresh registerDate
• Pages or .htaccess rules you did not write
• PHP files under /images, /media, /tmp, or a template folder that should only hold CSS and index.php
• JCE Editor profiles you never created (relevant if JCE is installed)
• Scheduled tasks or cron jobs you did not add
• Outbound spam from the site’s mailer

What scanners miss: VirusTotal and Sucuri SiteCheck are useful for “is Google already angry?” They are not a file integrity check. We still open JavaScript by hand. Automated tools love base64 and skip a one-line redirect in a minified JS file the template loads on every page.

Confirm Google’s view with the Safe Browsing site status tool and Search Console. Those are different queues from Bing or Norton Safe Web. Clearing one does not clear the others.

August 2026: what is actually being used against Joomla

Do not hunt for a mythical “Joomla is insecure” story. Hunt the hole that matches your stack.

Joomla core. On 18 August 2026 the project published security releases covering Joomla 5.4.7 / 6.1.2 and earlier in those lines, including CVE-2026-73337 (authentication bypass, moderate) and related access-control and upload issues. Current patched lines at the time of writing: 5.4.8 and 6.1.3. If you cleaned a site last week and left it on 6.1.2, you are not finished.

JCE (Joomla Content Editor). CVE-2026-48907 is actively exploited and listed by CISA. A vulnerable JCE is not “an overdue update.” Treat it as possible compromise: unexpected editor profiles, unexpected PHP in upload paths, then update to a patched JCE release (vendor guidance starts at 2.9.99.5, with 2.9.99.6 described as further hardening). Do not paste exploit URLs into production to “test.”

Everything else. Check VEL for every installed component, including page builders. For the broader 2026 picture, read our Joomla security 2026 guide.

Step 1: Freeze evidence before you delete anything

Take a full copy of files and the database as they are. Label it infected. Do not restore it later as “the clean site.” You need it to diff, to recover a unique article, and if you ever have to explain the incident.

Also copy web server access and error logs for the last 14 to 30 days. Once you start deleting PHP, you lose the URL that proved the entry point.

Step 2: Take the public site down without wiping the server

Use Joomla’s offline mode if the administrator still works. If it does not, a host-level placeholder is fine. Do not reformat the VPS yet. Do not disable logging. You are stopping visitors from hitting malware, not destroying the crime scene.

If you are on shared hosting, ask the host whether other accounts on the same user were writable. A cleaned Joomla next to an infected WordPress install will not stay clean.

Step 3: Name the infection type

Cleanup is different for each. Mixing them is why sites “get hacked again” in 48 hours.

• Webshell / backdoor: PHP in the wrong folder, extra Super User, odd JCE profile
• SEO spam: hidden links in modules, articles, or template overrides, often still ranking in Google
• Redirect: .htaccess, index.php in the template, or JS that only fires for certain user agents
• Mailer abuse: spam sent as the site, often a rogue user plus a form or cron

You can have all four at once. Fix persistence first, then content spam, then Google.

Step 4: Find the door they used

List every extension and template. Check VEL. Note Joomla version versus 5.4.8 / 6.1.3. If JCE is present, inspect editor profiles for anything you did not create. Search logs for administrator logins from unknown IPs and for component query strings you do not recognize.

Common 2026 doors: outdated JCE, outdated page builders, leftover Joomla 3 extensions on a “mostly upgraded” site, reused Super User passwords, and world-writable /images.

Step 5: Replace core and extensions from clean packages

Download the official full package for the same major version you are running. Diff or overwrite core folders (/administrator, /libraries, /includes, core /components) from that zip. Do not use this step to jump from Joomla 3 to Joomla 6. That is a migration, not a malware repair.

Reinstall templates and extensions from the vendor zip, not from the infected disk. Uninstall unused extensions. Delete their folders. Unpublish is not uninstall.

On the server, hunt recently changed files (SSH find by mtime is enough conceptually). Treat surprise PHP under media paths as guilty until proven otherwise. Reset permissions: folders 755, files 644, configuration.php 444. Never 777.

Step 6: Clean the database, not only the disk

File cleanup that leaves spam in #__modules, #__content, or #__extensions will republish the infection on the next page load.

• Dump the database, then search for spam domains, hidden iframes, and script tags you did not add
• Remove Super Users and extra admin accounts you cannot explain
• Check session and action logs if you keep them
• Review Joomla Scheduled Tasks for fetch-URL or PHP jobs you did not schedule

Do not run random “drop user” SQL you found on a 2014 blog. The old copy of this article even had invalid SQL. Use the User Manager, or a query you understand, on a backup copy first.

Step 7: Patch current, then rotate every secret

Update core to 6.1.3 or 5.4.8 (or newer if the project has moved on when you read this). Update every remaining extension, including JCE if you keep it. Then rotate:

• Every Super User and administrator password, plus 2FA
• Database password in the host panel and in configuration.php
• FTP, SFTP, hosting panel, Akeeba, payment, and SMTP secrets
• Joomla secret in configuration.php if you know how to regenerate it safely

If the attacker had Super User, assume they also had the database. A new password on the same leaked SMTP account is not a rotation.

Step 8: Prove it is gone, then talk to Google

Crawl the site as Googlebot and as a phone. Check .htaccess, ads.txt, and homepage HTML. Search your domain for spam queries. Take a new backup only after that.

Google is not one button:

• Safe Browsing warnings: wait for recrawl after the site is clean, then use Search Console security / malware reporting as Google documents it today
• Hacked content / spam in search: a different Search Console issue type. Cleaning files does not instantly drop spam URLs from the index. Use URL removal only for URLs that should not exist, not as a substitute for cleanup
• Request indexing is not a malware review. It will not lift a Safe Browsing flag

Expect days, not minutes, after a clean bill of health. Rankings recover after the warning and the spam URLs are gone, not after you “submit the sitemap again.”

Aftercare that actually prevents round two

• Stay on a supported line. 5.x regular bugfix ends 13 October 2026. Do not start a rebuild on 5.4 if you can start on 6.x. See the Joomla roadmap.
• 2FA on every administrator. Least privilege. No shared Super User.
• No nulled templates. That is still how a large share of “we were hacked for no reason” cases start.
• HTTPS is table stakes. It does not stop a vulnerable component.
• Off-server backups, tested restores, and a note of the last known-clean date.
• Admin Tools, RSFirewall, or equivalent help. They are not a substitute for updates.

If you are rebuilding after Joomla 3, that is an upgrade project, not a find-and-replace on a malware tree.

Key takeaways

1. Cleanup without a patch, or a patch without cleanup, fails.
2. Unpublish is not uninstall. Infected backups are not restores.
3. In August 2026, verify Joomla 5.4.8 or 6.1.3 and check JCE / VEL, not only “Joomla 4.3.”
4. Scan JavaScript, .htaccess, the database, and users, not only PHP signatures.
5. Google Safe Browsing review is separate from “request indexing.”

Frequently asked questions

How do I repair a hacked Joomla website?

Preserve an infected copy, take the site offline, identify the hole, replace core and extensions from official packages of the same major version, clean the database and rogue users, patch to current 5.4.8 or 6.1.3, rotate every secret, then request Google’s security review only after the site is actually clean.

Can I just update Joomla to remove malware?

No. Updates close the door. They do not delete PHP the attacker already wrote, extra Super Users, or spam in modules.

Is unpublishing a vulnerable Joomla extension enough?

No. Joomla’s documentation is explicit: uninstall it. Unpublish leaves files that can still run.

Should I restore my latest Akeeba backup?

Only if you are sure that backup is from before the compromise. A backup taken after the hack is a malware installer.

What Joomla version should I be on after a 2026 cleanup?

The current patched releases at this writing are Joomla 6.1.3 or 5.4.8. Check the security centre before you go live. Do not leave 6.1.2 or 5.4.7 as “good enough.”

Will Google rankings come back immediately?

No. Warnings and spam URLs clear on Google’s schedule after a successful review and recrawl. Indexing requests do not replace a malware review.

Conclusion

A hacked Joomla site is a persistence problem plus a patch problem. Treat it like both. If you want this done as a project rather than a weekend, we still clean and harden Joomla sites as part of support and maintenance. Bring the infected copy. Do not bring a guess.

You cannot jump from Joomla 3 to Joomla 6. In 2026 the supported destination is Joomla 6.1.x (current: 6.1.3). The official path is still staged: Joomla 3.10 to 4.4, then 4.4 to 5.4, then 5.4 to 6. Each hop needs its own backup, Pre-Update Check, and extension pass. Stopping at Joomla 4 is no longer the finish line.

This URL still ranks for Joomla 3 to Joomla 4 because that hop is mandatory. The article is updated for people who think a Joomla 6 zip on a Joomla 3 tree is an upgrade. It is not. It is a broken site.

We have run this path on client sites at Infyways for years. The 2023 “ten tips for Joomla 4” list still matters. The target, PHP, and Backward Compatibility plugin rules have changed. Follow the current Joomla 3 to 4, 4 to 5, and 5 to 6 manuals for the button-by-button UI. Use this page for the decisions those manuals assume you already made.

What you will learn

• Why Joomla 3 to Joomla 6 is a chain, not a single update
• What still applies from the old Joomla 3 to 4 checklist
• PHP, MySQL, and Backward Compatibility plugin rules that stop a 5.4 to 6 upgrade
• Whether to land on 5.4.8 or go all the way to 6.1.3

The only upgrade path that works

Stage	You must be on	You move to
1	Latest Joomla 3.10.x	Joomla 4.4.x
2	Joomla 4.4.x	Joomla 5.4.x
3	Joomla 5.4.x	Joomla 6.x (6.1.3 as of 18 August 2026)

If the Update component does not offer the next major, your PHP/MySQL or extensions failed the Pre-Update Check. Forcing a package overwrite across majors is how sites go offline.

Joomla 5.x regular bugfix support ends 13 October 2026 (security-only until 12 October 2027). Joomla 6.x is supported into 2028 and 2029 on the project roadmap. A new project should not “finish” on 4.x. A Joomla 3 site in 2026 should budget for 6.x, with 5.4 as a holding pattern only if an extension is not ready.

Step 1: Put Joomla 6 on the requirements sheet first

Do not size the server for Joomla 4 and hope. Joomla 6’s documented floor includes PHP 8.3, MySQL 8.0.13 or MariaDB 10.6.x (PostgreSQL 14 if you use it). Joomla 4 to 5 already wants PHP 8.1 and MySQL 8.0.13. Joomla 3 often still sits on PHP 7.x. That is three hosting conversations, not one.

If the host cannot do PHP 8.3, you will stop on 5.4 and still have a clock. Change host or plan before you burn a weekend on 3 to 4.

Step 2: Backup with Akeeba, then prove the restore

Take a full Akeeba (or equivalent) backup before every hop, not once at the start. Restore that backup on staging at least once. An untested backup is not a rollback plan. Keep the Joomla 3 backup after you reach 4. You will want it if an extension vendor has no Joomla 6 build and you need original data.

Step 3: Inventory extensions for 4, 5, and 6, not only 4

The 2023 advice was: check Joomla 4 versions on the JED. In 2026, a Joomla 4-only extension is a trap. You will pay for that migration twice.

• Keep it if the vendor has a Joomla 5.4 and Joomla 6 package, or a clear 5.4 bridge
• Replace it before 3 to 4 if the vendor is dead. Dead on Joomla 4 is dead on Joomla 6
• Ask the developer in writing for the 6.x date. “Coming soon” is not a path

VirtueMart, K2, old page builders, and custom components are where this project actually lives. Core is the easy part. If you need the work done as a project, that is Joomla upgrade and extension development, not a checkbox.

Step 4: Treat the template as a rewrite, not a setting

A Joomla 3 template will not “mostly work” on 6. Bootstrap, Chrome, and module positions change at 4 and again later. Budget a Joomla 5/6 template or a rebuild. Cassiopeia is a landing pad, not a brand.

Step 5: Run the Pre-Update Check on 3.10 before you touch 4

On Joomla 3.10, point Joomla Update at the Joomla 4 channel and read the Pre-Update Check. Update what you are keeping. Uninstall what will not survive. Disable incompatible system plugins so they do not fatal the first administrator hit after 4. Then migrate 3 to 4 on staging using the official 3 to 4 guide. Live is last.

Step 6: Do not live on 4.4

Joomla 4.4 is a station. After the site is stable, update extensions for 5, uninstall leftover com_search if the 4 to 5 manual still requires it, fix reCAPTCHA as that guide says, then 4.4 to 5.4. Current 5.x at this writing is 5.4.8.

The Backward Compatibility plugin is enabled on the 4 to 5 hop so old extensions can breathe. That is not permission to skip testing.

Step 7: Disable the old Backward Compatibility plugin before Joomla 6

This is the step 2023 Joomla 4 articles never mention, and it is why 5.4 to 6 fails in silence.

The official 5 to 6 guide: you must be on Joomla 5.4.x. The Behaviour, Backward Compatibility plugin without a number in the name must be disabled before you go to 6. Extensions have to run on 5.4 without that plugin. Joomla 5.4 also ships Backward Compatibility 6 to ease 6.x. Do not mix those two plugins up.

Then set the update channel to Joomla Next, pass Required Settings, and go to 6.x. Current 6.x: 6.1.3.

Step 8: Test each hop like it is production

Checkout, login, multilingual, ACL, custom fields, cron, and the two templates you actually use. Then the next hop. One giant “we will test at the end” is how you discover a Joomla 3 module still running on 6 with a white screen.

Stop on 5.4 or go all the way to 6

Land on 5.4.8 when	Go to 6.1.3 when
A paid extension has 5.x only	Vendors already ship Joomla 6
You need weeks to rebuild a template	PHP 8.3 is live and staging is green
You need a freeze before a campaign	You want the line supported through 2028 and 2029

Do not stop on 5.4 forever. Regular 5.x support ends 13 October 2026. For why 6.x is the live major line, see the future of Joomla in 2026.

Key takeaways

1. Joomla 3 to Joomla 6 is 3.10 to 4.4 to 5.4 to 6. No skip.
2. Joomla 3 to 4 is still required. It is not the 2026 destination.
3. Inventory extensions for Joomla 6 on day one, not after you reach 4.
4. PHP 8.3 and the unnumbered Backward Compatibility plugin are the usual 5.4 to 6 blockers.
5. Test and backup at every hop. Then go live.

Frequently asked questions

Can I upgrade Joomla 3 directly to Joomla 6?

No. There is no supported jump. Go 3.10 to 4.4, then 4.4 to 5.4, then 5.4 to 6.

Is a Joomla 3 to Joomla 4 upgrade enough in 2026?

No. Joomla 4 is a required station. Plan for 5.4 and 6.x unless you like another migration in a few months.

What is the current Joomla 6 version?

Joomla 6.1.3 as of 18 August 2026, with 5.4.8 still on the 5.x line. Check the roadmap before you freeze a package list.

Why does Joomla 6 not show in the Update component?

You are not on 5.4.x, PHP is below 8.3, or an extension/plugin (including the old Backward Compatibility plugin) failed the Pre-Update Check.

Do I still need Akeeba and a staging site?

Yes. More hops means more rollback points. Restore a backup on staging before every major jump.

Conclusion

Keep the Joomla 3 to 4 discipline: backup, extensions, template, Pre-Update Check, staging. Change the destination to Joomla 6. If that chain is more than you want to own, we still run it as an upgrade project and keep the site on support afterward.