Blog

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.

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

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.

Most people who want a Joomla helpdesk install osTicket next to Joomla and call it done. That is the mistake.

A Joomla helpdesk is a support ticket system that runs inside Joomla. Customers open and track tickets on your domain, with your users and ACL. osTicket is good software, and it is still a second PHP app. If you want an osTicket alternative for Joomla, that split is the whole decision.

A native Joomla helpdesk lives in the same site as your customers. osTicket sits beside it as another application.

I built Easy Helpdesk at Infyways after watching buyers log into Joomla, then get sent to another hostname to attach a screenshot. You do not need another case study. You have lived that ticket.

As of August 2026, Easy Helpdesk 1.0.31 is built for Joomla 5 and Joomla 6. It is on the JED and documented on JoomlaX.

What you will learn

• Why “osTicket plus Joomla” is not a Joomla helpdesk
• How a real Joomla support ticket should use your existing logins
• When osTicket is still the smarter call
• How to choose without reading a feature brochure

Why people install osTicket instead of a Joomla helpdesk

They need support tickets. They type Joomla helpdesk or Joomla support ticket into Google.

Then they install the first famous name they know.

osTicket shows up because it is free, old, and everywhere. Custom forms. Filters. SLA plans. A client portal. A knowledge base. All of that is real. Check the osTicket feature list if you want the source.

But wait.

osTicket is a separate PHP app with its own database and its own staff logins. Joomla already has PHP, MySQL, users, ACL, and a template.

So you now patch two stacks, brand two portals, and give the customer two “accounts.” That is the cost. Not the osTicket license. The community edition is free.

If you already run Joomla support and maintenance as a long-term site, a second helpdesk stack is extra work you will still be paying for in two years.

What a Joomla helpdesk actually is

A Joomla helpdesk installs as a Joomla package. Your visitor opens a support ticket in Joomla, tracks it on your domain, and an agent works the queue from a Joomla menu, not from a foreign admin skin on another subdomain.

If the desk does not use Joomla users, Joomla menus, and Joomla updates, it is not a Joomla ticketing system. It is a neighbour.

One stack means one login story. Two stacks means you patch Joomla and osTicket as separate products.

Easy Helpdesk is the native example I ship: portal, staff console, mail intake, SLA, knowledge base, reports. I am not going to paste the spec sheet here. You can open the JED or JoomlaX page if you want every toggle.

This is the same native-vs-bolted-on choice we keep making across the Joomla stack in 2026. Keep the product on the CMS when the CMS is the business.

Why this matters for your support tickets

Joomla is already the product. Support is part of that product.

When you bolt osTicket on the side, you teach customers that help is “over there.” They already have a Joomla login. They will not create another one for a screenshot.

Here’s why this matters.

A native Joomla support ticket reuses the session they have. Guests can still open a ticket without an account if you allow it, then come back by email link or ticket number. Agents can work the queue on the frontend so they are not living in /administrator all day.

osTicket can look fine. It still does not become Joomla unless you pay for glue you will own forever. Teams that already do custom Joomla development feel that glue as soon as ACL and membership collide.

5 checks before you pick an osTicket alternative for Joomla

Use this as a buying filter. Not a slogan.

1. Where does the ticket live?
On your Joomla domain, or on support.somethingelse?

2. Who owns the user?
Joomla groups and ACL, or a second staff table?

3. How does email arrive?
Inside the same site’s scheduled tasks, or a mailbox only the other app understands?

4. Can agents work without the Joomla admin?
If the answer is no, your helpdesk will become a bottleneck.

5. Do you need one desk for every CMS?
If yes, stop. osTicket (or another standalone) is the honest fit.

If no, you want a native Joomla helpdesk.

Joomla helpdesk vs osTicket (the only table you need)

Bottom line: stay native if Joomla is the business. Stay on osTicket if the business is bigger than Joomla.

When you should still use osTicket

Do not force the alternative.

Use osTicket if you already trained a global team on it.

Use osTicket if WordPress, Shopify, and Joomla must share one queue.

Use osTicket if you want a free, CMS-agnostic core and you will treat hosting and upgrades as a second product.

Do not pick osTicket because it “sounds more enterprise.” A native Joomla desk can still do departments, SLA, canned replies, private notes, and ratings. The architecture is the differentiator. Not a vibe.

The money question, without the pitch

osTicket’s code is free.

A native Joomla helpdesk is usually a paid extension because someone has to keep it on Joomla 5 and 6.

You still pay for osTicket. You pay in extra server, extra logins, and tickets that never get filed.

That is the trade. Pick it with your eyes open.

Key takeaways

1. A Joomla helpdesk runs on Joomla. osTicket runs beside it.
2. Joomla support tickets should use your domain, your users, and your updates.
3. Easy Helpdesk 1.0.31 (August 2026) is one osTicket alternative for Joomla 5 and 6. It is not the only possible native desk. It is the one built for this exact gap.
4. Multi-CMS support still belongs on a standalone tool.
5. Choose the architecture first. Then choose the product.

Frequently asked questions

Is Easy Helpdesk an osTicket alternative for Joomla?

Yes, if your support is Joomla-only. You get queues, email, SLA, and a knowledge base without a second user database. No, if one desk must cover several platforms.

What is the difference between a Joomla helpdesk and osTicket?

A Joomla helpdesk is an extension. osTicket is its own application. Same job on paper. Different home in production.

How should a Joomla support ticket work for the customer?

They submit on your site. They track it on your site. They do not create a second password unless you force that on purpose.

Can I just embed osTicket in Joomla?

You can iframe almost anything. You still have two apps to patch, two UIs to brand, and two identity models. That is a workaround, not a Joomla ticketing system.

Do I need Joomla administrator access to answer tickets?

You should not. Daily work belongs on a frontend staff queue. Admin is for setup and reports.

Is there a free osTicket alternative for Joomla?

osTicket is free, and it is not a Joomla extension. Native Joomla helpdesks are usually paid. You are buying the integration, not a slogan.

Conclusion

You have two honest options.

Run a Joomla helpdesk so a support ticket in Joomla stays on the site you already maintain.

Or run osTicket because you need a desk that does not care which CMS is in front.

Do not mix those goals and hope the customer will not notice.

If native is the call, look at how Easy Helpdesk is put together on JoomlaX and the JED listing. Then decide. Now it is your turn: pick the architecture this week, before you install another stack you did not need.

Joomla still has a future in 2026 if you need a native multilingual, ACL-heavy, or custom CMS, not a blog starter. The project is 21 years old. Joomla 6.1.3 is the current 6.x line. Joomla 5.4.8 is still supported. Market share is small next to WordPress. The architecture is not.

A friend still asks the same two questions I hear every year: do people still use Joomla, and why would anyone pick it when WordPress and Shopify dominate? Those questions are fair. The 2025 answers are not. This is the 2026 version.

I have built on Joomla since the Mambo days. At Infyways we still ship Joomla work and extensions. If the CMS had no future, we would have stopped. We have not.

What you will learn

• Where Joomla stands in 2026: versions, support dates, and market share
• Why people still choose Joomla over WordPress for complex sites
• What Joomla 6 actually changed after the 14 October 2025 launch
• Who should pick Joomla now, and who should not

Joomla in 2026: the facts, not the nostalgia

Joomla launched from the 17 August 2005 Mambo fork. It turned 21 on 17 August 2026. That history is in our separate piece on Joomla at 21. This article is about whether the CMS still deserves a new build this year.

According to W3Techs, Joomla powers about 1.2% of all websites and roughly 1.7% of sites with a known CMS. WordPress is in a different league on those charts. Popularity is not the same as fit.

Those dates come from the official Joomla roadmap (updated 18 August 2026). If you are still on 5.x, the clock to move toward 6.x is real. If you are on 6.1.3, you have a supported major line into the late 2020s.

Why people still use Joomla

Not because it wins the blog market. Because a few core jobs are still easier in Joomla than in a plugin pile.

Native multilingual

Joomla still ships multilingual in core. If you run a government, university, or multi-country site, that is not a nice extra. It is the product.

ACL and structured content

Granular permissions, Custom Fields, and template overrides let you build portals and membership systems without bolting on half a store of plugins. That is why agencies still recommend Joomla for permission-heavy builds.

Security that lives in core

Joomla is not magic. You still patch. The difference is how much you outsource to third-party plugins. We cover that trade in Joomla security in 2026. Core updates and a smaller essential-plugin surface still matter.

No corporate owner

Joomla is still community-run. There is no single vendor who can flip the license. For public-sector and long-lived intranet work, that governance is a feature.

What is new in Joomla 6

Stop treating Joomla 5.0 (October 2023) as the news. That was two major lines ago.

On 14 October 2025 the project shipped Joomla 6.0 and Joomla 5.4 together. 5.4 is the bridge. 6.x is the current major line, with automatic core updates and a Backward Compatibility 6 plugin so upgrades are less of a cliff.

Joomla 6.1 (April 2026) added items such as POW-captcha, a graphical workflow editor, and new media custom fields for audio, video, and documents. 6.1.3 landed on 18 August 2026. 6.2 is scheduled for 13 October 2026.

If your mental model of Joomla is still “hard upgrades and a dusty admin,” you are describing 3.x to 4.x scars, not the 5.4 to 6.x path.

Who should choose Joomla in 2026

WordPress and Shopify are the right tools for a lot of work. Joomla is the right tool when the CMS has to behave like an application, not a newsletter.

If you need that kind of build, see our Joomla development and Joomla support and maintenance work. For content that has to show up in AI answers, pair the CMS with GEO for Joomla.

Bright or bleak: Joomla’s next years

Bleak if you only watch share of all websites. Bright if you watch whether 6.x is maintainable. Automatic core updates and a dated support window through 2028 and 2029 are the confidence signal the last decade was missing.

What still has to improve is the same list as before, just more urgent: easier onboarding, healthier extension businesses, and clearer marketing for the project types Joomla actually wins. The community does not need to become WordPress. It needs more developers who stay.

Key takeaways

1. Joomla in 2026 is Joomla 6.1.3, with 5.4.8 still on a closing support clock.
2. Small market share does not cancel native multilingual, ACL, and core security posture.
3. Joomla 5.4 to 6.x is a different upgrade story than the painful 3 to 4 years.
4. Pick Joomla for complex, multilingual, permission-heavy sites. Pick WordPress or Shopify when those products fit better.
5. The future is real for teams that will stay on supported 6.x and keep investing in extensions.

Frequently asked questions

Does Joomla have a future in 2026?

Yes, as a specialist CMS for multilingual, ACL-heavy, and custom sites. It will not overtake WordPress on raw market share. It does not need to.

What is the current Joomla version in 2026?

Joomla 6.1.3 on the 6.x line, and Joomla 5.4.8 if you are still on 5.x. 5.x regular bugfix support ends 13 October 2026. Plan the move to 6.x.

Is Joomla still worth using instead of WordPress?

Use Joomla when you need core multilingual, deep permissions, and a flexible architecture. Use WordPress when publishing speed and the plugin/theme market matter more than those native tools.

Should I start a new site on Joomla 5 or Joomla 6?

Start on Joomla 6 unless an extension forces a short stay on 5.4. New projects should not begin on a line that leaves regular support in October 2026.

Did Joomla die after WordPress took the market?

No. It lost the mass-blog market. It kept the niches where core ACL and multilingual still beat a plugin stack. That is a smaller future, not a dead one.

Conclusion

Joomla in 2026 is not the 2015 story and not the 2023 Joomla 5 launch story. It is a 21-year-old CMS on a 6.x line with a published support calendar. If your next site needs that kind of control, it still deserves a serious look. If you only need a theme and a checkout, pick the tool that already won that job.

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

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

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.

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

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

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

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.

Joomla turns 21 today, 17 August 2026. Twenty-one years after the Mambo fork on 17 August 2005, it is still a production-ready open-source CMS for multilingual, ACL-heavy, and enterprise-style websites. Market share is smaller than WordPress. The next chapter depends on developer confidence, smoother upgrades, and core strengths that still outpace many competitors.

I have used Joomla since the Mambo days. At Infyways we still ship Joomla extensions used worldwide. Looking only at market share, it is easy to say Joomla lost. Looking at architecture, security, and real project fit, that conclusion is incomplete. Today is a birthday, not a eulogy.

What you will learn

• Why 17 August 2026 is Joomla’s 21st birthday, and how the 2005 fork actually started
• Why Joomla’s decline was mostly confidence and migration friction, not weak technology
• Which core capabilities still make Joomla a strong CMS choice in 2026
• Where Joomla 5.4.x and 6.x stand on the current roadmap
• When to choose Joomla instead of trying to copy WordPress

17 August 2026: Joomla is 21

The date is not marketing copy. The Joomla project and the official 20 Years of Joomla timeline put the start of the story on 17 August 2005: a fork of Mambo so the CMS would stay truly open source. The name Joomla (from the Swahili jumla, “all together”) was announced on 1 September 2005. Joomla 1.0 shipped on 22 September 2005.

That makes today, 17 August 2026, twenty-one years of a volunteer-run CMS with no corporate owner. Last year’s 20th birthday week is documented in the Joomla Community Magazine. Year 21 is quieter, which is fine. The work is in releases, not merch shops.

Joomla market share vs WordPress in 2026

According to W3Techs, Joomla currently powers about 1.2% of all websites and roughly 1.7% of sites that use a known CMS. WordPress powers over 43% of all websites and nearly 62% of the CMS market.

Bottom line: market share measures popularity. It does not measure whether Joomla is still the better tool for a university portal, government site, membership platform, or multi-language enterprise build.

Joomla never lost because of technology

The most common misconception is that Joomla declined because it could not keep up technically. I disagree. Modern Joomla is one of the strongest releases the project has ever shipped.

• Native multilingual support
• Enterprise-grade Access Control Lists (ACL)
• Custom Fields for structured content entities
• Template overrides for full front-end control
• Web Services / API endpoints for headless and hybrid builds
• Modern PHP architecture, cleaner code, and a strong security posture

Many of these capabilities existed in Joomla before they became table stakes elsewhere. Technology was never the core weakness.

The real challenge was confidence

The harder problem was investment confidence. Major releases modernized the platform, but they also created painful migrations, broken extensions, template rewrites, and changing APIs.

Businesses delayed upgrades. Developers spent months on compatibility instead of new products. Agencies hesitated before recommending Joomla for long-term roadmaps. Some extension authors moved ecosystems or stopped shipping altogether.

That uncertainty, not a lack of features, slowed Joomla’s commercial momentum.

The biggest loss was developers, not just users

A CMS is only as strong as the ecosystem around it: extension developers, template creators, agencies, hosts, educators, and community contributors. When developers stop building, users eventually stop arriving. That developer attrition was Joomla’s deepest challenge over the last decade.

What Joomla still gets right in 2026

Joomla still wins on flexibility, security, scalability, and developer freedom. Unlike platforms that outsource essential capability to plugins, Joomla keeps many advanced features in core.

• Multilingual: still among the best native CMS implementations
• Permissions: ACL depth most competitors still struggle to match cleanly
• Architecture: enough freedom to build complex applications, not only brochure sites
• Trust: a long security track record with businesses, education, and public-sector projects
• Governance: still community-run. No venture owner can flip the license.

As cybersecurity and data ownership become non-negotiable, those strengths matter more, not less. For a practical hardening view, see our Joomla security 2026 guide.

Where Joomla 5.4 and Joomla 6 stand on its 21st birthday

On 14 October 2025, the project released Joomla 6.0 and Joomla 5.4. 5.4 is the bridge. 6.x is the new major line, with automatic core updates and a Backward Compatibility 6 plugin to reduce upgrade risk.

The Joomla roadmap (updated 16 August 2026) is the right snapshot for today:

• Joomla 5.x current: 5.4.7. Bugfix only. Regular bugfix support until 13 October 2026. Security-only until 12 October 2027.
• Joomla 6.x current: 6.1.2. Bugfix support until 17 October 2028. Security-only until 16 October 2029.
• Tomorrow, 18 August 2026: planned 5.4.8 and 6.1.3.
• Joomla 6.2.0 is aimed at 13 October 2026, with Beta 1 listed for 18 August 2026.

This week the community also runs Pizza, Bugs and Fun on 21 to 22 August 2026, a hybrid global event for testing, docs, and patches, including work toward Joomla 6.2. Birthdays are nice. Contributor weekends keep the CMS alive.

Why I still build with Joomla

People ask why I keep investing after two decades. Because the product still solves hard problems well. At Infyways we keep releasing and maintaining Joomla products, and we stay active on the Joomla Extensions Directory. If we did not believe Joomla had a future, we would not keep putting time and capital into that ecosystem.

For teams also optimizing content for AI search answers, pair this CMS strategy with our practical guide to GEO for Joomla.

Joomla does not need to become WordPress

Comparing Joomla only to WordPress misses the point. WordPress won by making publishing extremely simple. Joomla won by giving developers and organizations deep flexibility. That identity should stay.

Instead of chasing raw market share, Joomla should keep improving what already makes it exceptional, while making onboarding, upgrades, and sustainable extension businesses easier.

Key takeaways

1. Joomla is 21 today, 17 August 2026, counting from the 17 August 2005 Mambo fork.
2. Smaller market share does not mean the CMS is obsolete for complex builds.
3. Core multilingual, ACL, Custom Fields, and Web Services remain durable advantages.
4. Joomla 6.1.2 is the current major line. 5.4.x is still supported. 5.4.8 and 6.1.3 are on the calendar for 18 August 2026.
5. Joomla should double down on its identity, not imitate WordPress.

Frequently asked questions

When did Joomla turn 21?

On 17 August 2026. The project began as a Mambo fork on 17 August 2005, was named Joomla on 1 September 2005, and shipped 1.0 on 22 September 2005.

Is Joomla still worth using in 2026?

Yes, when you need native multilingual, deep ACL, structured content, or a flexible architecture for complex sites. It is not always the fastest path for a simple brochure blog, but it remains a strong CMS for demanding projects.

Did Joomla lose to WordPress because of bad technology?

No. Joomla’s harder problem was confidence: migration pain, extension compatibility risk, and uncertain long-term investment signals. The core technology stayed competitive.

What should I run on Joomla’s 21st birthday?

Joomla 6.1.2 on the 6.x line, or 5.4.7 if you are still on 5.x. Watch for 6.1.3 and 5.4.8 around 18 August 2026 on the official roadmap, then plan toward 6.2 later in 2026.

Who should choose Joomla over WordPress?

Teams building multilingual portals, permission-heavy applications, government or education sites, or custom systems that benefit from core ACL and overrides, rather than assembling the same stack from many plugins.

Conclusion

Twenty-one years in, Joomla’s next chapter will not be written by market-share charts alone. It will be written by developers who keep building, businesses that keep investing, and a community that treats security, ownership, and flexibility as first-class product values. I am still building extensions, still contributing on the JED, and still recommending Joomla when it is the right fit, not from nostalgia, but because the platform still has enormous potential.

Happy 21st birthday, Joomla. Here’s to the next 21 years.

Joomla security is strongest when you treat the CMS as a full stack: core access control, server configuration, updates, monitoring, and incident response. Joomla is still one of the most defensible open-source CMS platforms for serious sites because ACL, user groups, and many security controls live in core instead of a pile of plugins. WordPress can be secured too. It usually needs more third-party layers to reach the same baseline.

July and August 2026 proved the other half of that sentence. Popular add-ons such as JCE and SP Page Builder were the main takeover path, not Joomla’s architecture. If your site is already hacked, or you want it hardened without depending on one security extension, that is the work Infyways does: cleanup, hardening, upgrades, and ongoing maintenance.

What you will learn

• Why Joomla’s core security model still compares well with WordPress
• Why infection counts are not the same thing as “WordPress is weaker core”
• How to harden Joomla with hosting, ACL, updates, and process, not only a plugin
• What the July and August 2026 JCE, SP Page Builder, and core CVEs actually mean
• When to call for hack recovery versus a planned security upgrade

Why Joomla is still a strong security CMS versus WordPress

Joomla did not become “insecure” in 2026. The summer CVEs hit extensions that sit on top of Joomla, the same way WordPress incidents cluster in plugins and themes. The difference is how much security you get before you install anything extra.

That last row needs an honest citation. In Sucuri’s 2023 Hacked Website and Malware Threat Report, WordPress accounted for 95.5% of CMS infections in their cleanup data. Joomla was 1.7%. Sucuri is clear this tracks popularity and their customer mix, not a lab score of core code. Still, the operational fact remains: WordPress is the default target. Joomla’s smaller, more ACL-heavy footprint is an advantage if you actually maintain it.

The same report found 39.1% of infected CMS apps were outdated, 49.21% had at least one backdoor, and 13.97% had a vulnerable plugin or theme at cleanup. Those numbers are the real lesson. Security is a maintenance system. Joomla gives you better native controls. It does not forgive abandoned page builders.

Secure Joomla without betting everything on one extension

A firewall or “security” extension can help. It is not a substitute for hosting, permissions, and patch discipline. This is the stack we use when a client wants the site secured, not just a new plugin invoice.

Server and PHP

• Current PHP that Joomla 5 or 6 actually supports
• TLS everywhere, SSH keys not shared passwords, isolated hosting accounts
• Disable PHP execution in images, media, and tmp
• Restrict /administrator by IP, VPN, or HTTP auth where the business allows it

Joomla core controls

• MFA on every Super User and Manager
• Least-privilege ACL: editors should not be Super Users
• Global Configuration: strong session settings, HTTPS, sensible error reporting off on live
• Hide unused components, modules, and templates instead of leaving demo code online

Updates as a process

• Core on the current security line (Joomla 5.4.x or 6.1.x in 2026)
• Editors and page builders on a weekly check, not a yearly project
• Staging first for major upgrades, then production
• Off-site backups you have restored at least once

Infyways can run that as a one-off harden, a Joomla upgrade, or ongoing Joomla support and maintenance. If the site is already compromised, start with cleanup, then hardening. A plugin on a backdoored site only hides the problem.

July and August 2026: what actually broke

Use this section as a patch briefing, not as proof that Joomla “lost.” The pattern is familiar: commodity extensions with public endpoints, then automated scanning.

JCE CVE-2026-48907

JCE is a widely used editor, not Joomla core. CVE-2026-48907 let unauthenticated visitors create profiles and upload PHP. Fixed in 2.9.99.5, with 2.9.99.6 recommended. If this was unpatched on a live site, assume a backdoor until you prove otherwise.

SP Page Builder through 12 August 2026

Do not stop at 6.6.2 or 6.7.1. June’s CVE-2026-48908 was a no-login takeover. 27 July’s 6.7.1 closed unauthenticated SQL injection and a mail-relay issue documented by mySites.guru. 12 August’s 6.8.0 closed CVE-2026-67285 (PHP file inclusion) and CVE-2026-67286 (file write).

Joomla 5.4.7 and 6.1.2

The 7 July 2026 core release patched XSS and incorrect access control in media, contact, MFA, templates, installer, workflow, modules, privacy, and fields webservices. Apply it. It is still a smaller class of risk than unauthenticated editor and page-builder RCE.

If the site is already hacked

Patching a KEV-class RCE after weeks online is not a cleanup. Typical Joomla compromise leftovers are extra Super Users, PHP in tmp or image folders, modified templates, and poisoned .htaccess. Infyways handles that as incident work: isolate, take forensic copies, remove malware, rotate credentials, patch, then harden. See how we repair a hacked Joomla website if you need the recovery path.

What Infyways actually delivers

• Hacked site recovery: malware removal, backdoor hunt, Google Safe Browsing / host blacklist help
• Security hardening: server rules, ACL, MFA, admin lockdown, PHP-in-uploads blocks, backup design
• Extension and core upgrades: JCE, SP Page Builder, and Joomla 5/6 on a staging copy first
• Retainer maintenance: updates, monitoring, and a human response when the next CVE drops

We will install a reputable security extension when it fits. We will not pretend it replaces hosting controls, ACL, or a clean codebase. If you want a quote, use the contact form on this site and tell us whether you need emergency cleanup or a planned harden.

Key takeaways

1. Joomla’s core ACL and admin split still give it a security architecture WordPress usually buys as plugins.
2. Sucuri’s infection mix is mostly WordPress because WordPress is everywhere. Maintenance still decides who gets hacked.
3. Summer 2026 takeovers were JCE and SP Page Builder. Update those, then core.
4. Real Joomla security is server, ACL, updates, backups, and response, not one extension.
5. Hacked sites need cleanup first. Hardening a backdoor in place fails.

Frequently asked questions

Is Joomla more secure than WordPress in 2026?

Joomla’s core ACL, separate administrator app, and smaller install base are genuine advantages. WordPress is attacked more because it is the default CMS. Either platform fails if editors, page builders, or plugins stay unpatched.

Can I secure Joomla without a third-party security extension?

Yes. Start with current PHP and Joomla, MFA, least-privilege ACL, no PHP in upload folders, restricted administrator access, backups, and a patch process. A security extension can add WAF or scanning. It should not be the only control.

What were the main Joomla security issues in July and August 2026?

JCE CVE-2026-48907 (unauthenticated RCE), SP Page Builder’s June to August chain ending in 6.8.0, and Joomla 5.4.7 / 6.1.2 core XSS and access-control fixes from 7 July 2026.

Which SP Page Builder and JCE versions should I run?

JCE 2.9.99.6 or later, and SP Page Builder 6.8.0. Older “almost patched” builds still leave summer 2026 holes open.

We were hacked. Should we migrate to WordPress?

Usually no. Migration does not remove a backdoor and it throws away Joomla ACL you already paid for. Clean the site, patch, harden, then decide. Infyways can do the recovery without forcing a CMS change.

Conclusion

Joomla remains a strong security CMS when you use the controls it already ships: ACL, a real administrator app, and a smaller, more intentional extension set. The July and August 2026 headlines were about unpatched JCE and SP Page Builder, plus a normal core security release. Keep Joomla, patch the stack, and harden the server. If you need that done as a project, from hacked-site cleanup to a maintenance retainer, Infyways is built for that work.