Joomla 6 and Joomla 6.2: What’s New and How to Prepare

Joomla 6 is the current major CMS line. Stable production today is Joomla 6.1.3. Joomla 6.2 is the next minor release: it is in feature freeze (Beta 2 as of 1 September 2026) with general availability planned for about 13 October 2026. Site owners still on Joomla 5.4 should note that Joomla’s bugfix window for 5.4 ends on that same October date. This guide covers what 6.x changed from 5.x, what 6.2 adds, and how to upgrade safely.

The old “Joomla 6 is coming” story is finished. Joomla 6.0 shipped. The 6.1.x line is receiving security and bugfix releases (6.1.3 announcement). Attention now moves to Joomla 6.2, which the project is testing in public betas (Beta 1, Beta 2). Betas are not for production.

If you need a managed path from 3.x, 4.x, or 5.x onto 6.x (or a staging dry-run before 6.2), use Infyways Joomla Upgrade services.

What you will learn

• Where Joomla 6.x stands in September 2026 (stable vs beta)
• What Joomla 6.2 is shipping (editors, multilingual, updates, APIs)
• The official 6.2 milestone calendar through GA
• How 6.x differs from 5.x and 4.x
• A practical upgrade checklist for site owners and developers
• When to call in Joomla upgrade or support help

Official schedule source: Joomla Project Roadmap.

Joomla 6.2 status: coming soon, already testable

Milestone	Planned date (roadmap)	Status
Alpha 1 to 3	May to July 2026	Done
Beta 1 (feature freeze)	18 August 2026	Done
Beta 2	1 September 2026	Current public beta
Beta 3	15 September 2026	Upcoming
RC1 (language freeze)	29 September 2026	Upcoming
6.2.0 stable (GA)	~13 October 2026	Planned
6.2.1+	Nov 2026 onward	Maintenance

Dates can slip. Treat them as planning targets, not contracts. Release managers for 6.2: Viviana Menzel and Martin Kopp (roadmap).

Production rule: run Joomla 6.1.3 (or the newest 6.1.x) on live sites. Install 6.2 Beta only on staging or throwaway test sites (launch.joomla.org is fine for experiments).

Calendar pressure for Joomla 5.4: official messaging around the 6.1.3 / 5.4.8 release notes that 5.4 bugfix support ends 13 October 2026, with security support continuing longer. That lands on the same week as planned 6.2 GA. If you are still on 5.4, plan the move to 6.x before bugfix ends, even if you wait for 6.2.0 stable rather than jumping into beta.

What is new in Joomla 6.2

Feature freeze started at Beta 1. No major new features after that. Below is what the project committed for 6.2, based on the Beta 1 feature notes and follow-up Beta 2 work. Always re-check the 6.1 to 6.2 migration guide and release notes before you upgrade.

Editors and content UX

Change	Why it matters
Native TinyMCE Readmore button	Replaces legacy readmore handling with a real TinyMCE plugin
Link selector modal	Unified link picker for article, contact, and menu editor buttons
TinyMCE uses Joomla text filter by default	Editor HTML follows core filter rules, not a separate TinyMCE whitelist
TinyMCE 8.8.x	Editor package bump for stability and security
Category / list sub-category images	Optional display of child category images in content (and related category list layouts)

Multilingual

Change	Why it matters
Language fallback chain	Missing language strings can fall through a configurable chain (example: regional → country → base), with overrides in Language options

Useful for agencies running many language packs where incomplete translations left English gaps or blank labels.

Updates, security visibility, media

Change	Why it matters
Security flag on updates	Installer UI and quickicons can mark security releases clearly
Highest-severity update preference	Updater prefers the update with the highest severity when multiple match
Clearer SVG upload error messages	Media Manager reports specific SVG validation failures instead of a generic XSS warning
Better installer error reporting	Failed web installs surface more precise diagnostics

APIs and developer tools

Change	Why it matters
EnumField form field	Build list options from PHP enums
Web Services: separate introtext / fulltext	JSON:API content endpoints expose both fields; combined text is deprecated (removal planned for Joomla 8.0)
Generic XOAuth2 support (Beta 2 line)	Broader OAuth2 plumbing for integrations (verify against final release notes)

Note on article preview tokens: Beta 1 announced signed preview tokens for unpublished articles without a frontend login. That work was reverted in Beta 2 for further work. Do not plan production workflows around it until it returns in a later release note.

Also in the 6.2 alpha/beta window: media/image manager improvements inside TinyMCE, accessibility tweaks (for example aria-disabled on toolbar buttons that need a selection), admin menu support-link polish, and assorted stability fixes aimed at larger sites.

What Joomla 6.x already changed vs 5.x and 4.x

Joomla 6.0 was the architectural jump. 6.1 and 6.2 are incremental on that base.

Area	Joomla 4.x	Joomla 5.x	Joomla 6.x
Focus	Bootstrap 5 admin, accessibility	Modern PHP, compatibility plugin era	Framework cleanup, new packages, stricter future path
PHP	7.2+ era evolving to 8.x	PHP 8+ focus	Modern PHP required (plan 8.1+ / 8.2+ on hosting)
Extensions	Many older extensions still ran	Compat plugin smoothed upgrades	Test every extension; compat is a bridge, not a forever plan
APIs	Mixed legacy	Deprecations increasing	Renderer, Console, Preload, DB/HTTP modernization
Support clock	Ended	5.4 bugfix ends ~13 Oct 2026	Active 6.1.x today; 6.2 GA planned same week

Core 6.0 themes that still matter for upgrades: stronger database patterns, HTTP / cryptography modernization, console tooling, preload helpers, and the compatibility plugin for migration. Details live in Joomla 6 migration docs and the roadmap.

Why you should prepare now

1. Support calendar. 5.4 bug fixes stop when 6.2 is due. Security patches continue longer, but feature and bug debt stacks up if you stay behind.
2. Extension vendors. Good vendors already ship Joomla 6 builds. Waiting until the week of GA means competing with every other late upgrader for support tickets.
3. 6.2 editor and language changes. TinyMCE filter defaults and language fallback can change what editors see. Staging catches that before clients do.
4. Headless / Web Services. If you use Joomla as an API, the intro/fulltext split needs client updates before the combined field disappears in a future major.

Need hands-on help: Joomla Upgrade, ongoing Joomla support and maintenance, or hire Joomla developers. For K2 sites stuck on old stacks, pair the CMS upgrade with K2 migration services.

Step 1: Inventory and hosting check

1. Export installed extensions, templates, custom overrides, and PHP version.
2. Confirm hosting meets Joomla 6 PHP requirements (modern 8.x). Upgrade hosting before the CMS if needed.
3. Mark every extension as: J6-ready, needs compat plugin, or replace.
4. Filter the Joomla Extensions Directory by Joomla 6 where vendors list readiness.

Step 2: Stage, never upgrade live first

1. Full backup (files + database).
2. Clone to staging with the same PHP version you will use in production.
3. On staging, update to the newest stable 6.1.x first if you are coming from 5.x.
4. Only then test 6.2 Beta on a separate staging copy if you want early validation. Beta is for discovery and extension testing, not go-live.

Official beta packages: Beta 2 announcement. Report issues at issues.joomla.org.

Step 3: Compatibility plugin, then remove the crutches

1. Enable the Joomla compatibility / BC plugin only while you patch or replace broken extensions.
2. Retest logins, checkout, forms, multilingual switching, and search.
3. Fix or replace templates that assume removed APIs.
4. Plan to turn the compat plugin off once everything is native-ready. It is a bridge.

Migration notes: 6.1 to 6.2 migration guide (update as the manual grows through RC).

Step 4: QA before production cutover

1. Frontend: home, menus, articles, category blogs, media, forms.
2. Admin: article edit (TinyMCE readmore/links), installer update view, language strings.
3. SEO: SEF URLs, redirects, sitemaps, canonical tags.
4. Performance: cache, CDN, image formats (WebP converter for Joomla).
5. Security: apply the latest 6.1.x / 5.4.x patches on whatever you run today; do not wait for 6.2 to install current security releases.

When staging is green, schedule production during low traffic, restore plan in hand. Infyways can run that cutover under Joomla Upgrade or white-label via outsource Joomla services.

Developer action plan for 6.2

1. Test extensions against 6.2 Beta / nightly builds before GA.
2. Stop depending on deprecated Web Services text for articles; use introtext and fulltext.
3. Adopt EnumField where enums already model your options.
4. Re-test TinyMCE integrations after the text-filter default change.
5. Watch language packs for fallback-chain behavior on incomplete translations.
6. Read B/C notes for 6.2 and file bugs early while betas are open.

Agencies maintaining many client sites: outsource Joomla services and Joomla extension development.

Key takeaways

1. Stable today: Joomla 6.1.3 (keep patched). Coming: Joomla 6.2 GA around 13 October 2026.
2. 6.2 is in feature freeze. Beta 2 (1 Sep 2026) is for testing only.
3. Headline 6.2 themes: better TinyMCE workflows, language fallback chains, clearer security updates, Web Services field split.
4. 5.4 bugfix ends around the same date as 6.2 GA. Plan the move to 6.x now.
5. Upgrade on staging first. Use Infyways Joomla Upgrade if you want a managed migration.

Frequently asked questions

When is Joomla 6.2 released?

The project roadmap targets about 13 October 2026 for 6.2.0 stable, after Beta 3 and an RC. Confirm on the roadmap as dates can move.

Should I install Joomla 6.2 Beta on my live site?

No. Betas are for testing. Production sites should stay on the latest stable 6.1.x until 6.2.0 ships and your extensions are verified.

What is the current stable Joomla 6 version?

As of late August 2026, Joomla 6.1.3 is the published stable download on downloads.joomla.org. Always check that page for newer 6.1.x patches.

How is Joomla 6.2 different from Joomla 6.0?

6.0 was the major platform jump. 6.2 is a minor release focused on editor UX, multilingual fallbacks, update severity visibility, API field clarity, and stability. It builds on 6.0/6.1 rather than replacing the architecture again.

Will my Joomla 5 extensions work on Joomla 6?

Some will, some need the compatibility plugin, some need vendor updates. Inventory and test on staging. Replace abandonware before you cut over.

Does Joomla 5.4 still get updates?

Bug fixes for 5.4 are scheduled to end around 13 October 2026. Security support continues longer per the project’s 5.4 / 6.1 release notes. Do not confuse “still gets security” with “good place to stay forever.”

How do I upgrade to Joomla 6 safely?

Backup, clone to staging, update hosting/PHP, update or replace extensions, test, then schedule production. Infyways documents and runs this under Joomla Upgrade services.

Where do I get help if the upgrade breaks?

Start with staging logs and vendor docs. For a full recovery or multi-site rollout, use Joomla support and maintenance or hire Joomla developers.

---

SEO Metadata

Field	Value
Meta Title	Joomla 6.2 Guide: What’s New, Timeline, Upgrade
Meta Description	Joomla 6.2 is in beta with GA planned for 13 Oct 2026. See new features vs 6.1, the roadmap, and how to upgrade from Joomla 5 safely.
URL Slug	joomla-6
Focus Keyword	Joomla 6.2

WebP Converter for Joomla: Why Google Ranking Needs It

A WebP converter for Joomla turns JPG, PNG, and GIF files into smaller WebP (and optionally AVIF) copies so browsers download less data while visitors still see the same picture. That matters for Google ranking because Google uses page experience and Core Web Vitals as ranking signals. On image-heavy Joomla sites, a slow hero JPEG often is the Largest Contentful Paint (LCP) element. Cutting image weight by up to 80% is one of the fastest ways to improve what Google measures and what users feel.

Joomla does not convert formats when you upload a photo. Templates and page builders keep printing whatever you stored. Over years you get a folder of large JPEGs and PNGs. Google PageSpeed Insights and Lighthouse then flag Serve images in next-gen formats. This article starts with why next-gen conversion is a must for websites that want to rank in Google, then covers how to do it on Joomla 4, 5, and 6.

Same visual, smaller file. Google’s crawlers and real users both benefit when LCP images load faster.

What you will learn

• How Google uses speed and Core Web Vitals in ranking
• Why heavy images are a must-fix for almost every website
• Why Joomla sites fall behind on Google PageSpeed image audits
• How WebP and AVIF help you pass Google’s next-gen format checks
• Practical ways to convert (manual, CDN, plugin) and which fits
• Step-by-step conversion on Joomla 4, 5, and 6, then how to verify in Google tools

Related speed work: Joomla website optimization and Joomla on-page optimization.

How Google ranking is affected by slow images

Google Search does not rank on keywords alone. Google also evaluates how usable the page feels. Official Google Search documentation describes page experience and Core Web Vitals as part of that picture. Core Web Vitals currently center on:

Metric	What Google measures	Why images matter
LCP (Largest Contentful Paint)	How fast the main content appears	Often a hero image or intro photo on Joomla templates
INP (Interaction to Next Paint)	How responsive the page feels	Heavy pages compete for main-thread time while large images load
CLS (Cumulative Layout Shift)	Visual stability	Late-loading images without size hints can shove content around

Google’s guidance for a “good” LCP is roughly 2.5 seconds or under for most users in the field data Google collects. When the largest paint is a 400 KB JPEG on a mid-range phone, that budget burns before PHP or MySQL even enter the story. Content quality still matters most, but when two pages are similar, Google can prefer the faster, better-experiencing URL. That is how image format work impacts ranking: it protects LCP and page experience so you are not the slower option in a competitive SERP.

You see the same problem in tools Google provides:

• PageSpeed Insights (lab + field / CrUX data)
• Search Console → Experience / Core Web Vitals reports
• Lighthouse audits: Serve images in next-gen formats, Efficiently encode images, Properly size images

Ignoring those Google reports does not freeze your rankings overnight. It does leave ranking headroom on the table, especially on mobile Google results where bandwidth and CPU are weaker.

Why next-gen image conversion is a must for websites

Every public website that wants organic traffic from Google has the same constraint: users and Googlebot both wait on bytes. Images are often the largest bytes on the page. Leaving them as unconverted JPG and PNG is optional only if you do not care about:

1. Google ranking and visibility. Weak Core Web Vitals and poor page experience make it harder to win when competitors already ship WebP or AVIF.
2. Mobile Google users. Most searches happen on phones. A desktop-optimized JPEG that looks fine in the office fails in the field data Google uses.
3. Bounce and conversion. Slow LCP means people leave before they read. Fewer engaged visits can reinforce weaker performance in Google Analytics and Search Console over time.
4. Crawl and index efficiency. Bloated pages waste crawl budget and delay rendering. Leaner HTML and lighter assets help Google fetch and understand the page faster.
5. Cost. Hosts and CDNs charge for bandwidth. Serving 80% less image data is free money after the conversion path exists.

WebP and AVIF are not trends. They are smaller encodings of the same pixels. At similar visual quality, WebP is typically much smaller than JPEG or PNG. AVIF can be smaller still when the host and browser support it. For any website that lives on Google traffic, converting to next-gen formats is a must, not a polish task after “real SEO.”

On Joomla, the must is stronger: the CMS will happily keep uploading camera JPEGs forever unless something converts them automatically.

Why Google PageSpeed hits Joomla sites especially hard

Joomla stores media under images/ and reuses those paths everywhere: articles, modules, custom fields, templates, and third-party components. Unlike a one-page static site, you cannot casually rename every file without breaking references. Google still evaluates the rendered page. If the live HTML points at a 400 KB JPEG, Google PageSpeed counts that JPEG.

Typical Joomla image debt looks like this:

• Hero and intro images uploaded as high-quality JPEG from a phone or camera
• PNG screenshots and UI graphics that were never compressed
• Gallery and news folders with thousands of files from years of publishing
• Template CSS that still points at .jpg or .png backgrounds
• Structured data and Open Graph tags that still list the old JPEG URL

Manual fix: download, convert on a desktop, re-upload, update every article and module. On a 500-article site that is a migration project, not a maintenance task. New uploads start the problem again unless conversion is automatic.

So the need is not only "use WebP once." It is continuous: keep originals for the editor and backup, serve modern formats on the front end, and handle new uploads without a weekly batch job on someone’s laptop.

WebP vs AVIF: what each format is for

Format	Typical size vs JPEG	Browser support	Role on a Joomla site
WebP	Often 25 to 35% smaller at similar quality (sometimes more)	All modern browsers	Safe default for almost every Joomla 4+ site
AVIF	Can be ~50% smaller than WebP at similar quality	Strong in Chrome, Firefox, Opera; Safari support has expanded	Use when PHP and hosting can create AVIF
Original JPG/PNG	Largest	Universal	Keep as fallback for older clients

You do not need AVIF on day one. WebP alone clears most of Google PageSpeed’s Serve images in next-gen formats warning for modern traffic. AVIF is the second step when hosting supports it (usually PHP 8.1+ with GD imageavif() or ImageMagick AVIF).

Ideal delivery uses a <picture> chain: AVIF first (if present), then WebP, then the original. The browser picks the first format it understands. Google’s crawlers that support modern formats get the lean file. Older clients still get a working image. You should not hand-write that markup in every Joomla article.

How conversion can be done (pick a method)

Method	When it works	When it fails
Desktop tools + re-upload	Few images, one-time redesign	Large archives, ongoing editors, broken paths
Free online converters	One-off assets	Privacy, no Joomla integration, no automation
CDN / edge image polish	Host already offers format negotiation	Less control per folder; admin and exclusions harder
Joomla system plugin	Ongoing sites, many folders, exclusions	Needs PHP GD (and AVIF libs if you want AVIF)

A solid WebP converter for Joomla should do at least this:

1. Keep originals so Media Manager and backups stay intact
2. Convert on page load and/or in bulk before traffic spikes
3. Support WebP, and AVIF when the server can
4. Serve fallbacks so old browsers still see an image
5. Let you exclude logos, animated GIFs, checkout pages
6. Run on shared hosting without SSH

Those requirements define the "how," not a brand pitch. One product that matches them on Joomla 4, 5, and 6 is WebP Converter by JoomlaX (Infyways). The rest of this guide uses that plugin as the concrete how-to, with official documentation for settings detail.

How it works once a converter is installed

Two workflows cover most sites:

On-the-fly. A visitor opens a page. The plugin finds image tags (and can handle CSS backgrounds and optional global URL rewrite). If a WebP or AVIF copy exists, the HTML points there. If not, it can create the copy during that request (with memory limits), then reuse it later. Good for new uploads and steady traffic.

Batch Generate Images. In the administrator, open the plugin’s Image Management tab, tick folders under images/, choose WebP Only, AVIF Only, or Both, and run Generate. Use this before launch, after a migration, or for a large stories archive.

Default layout: images/stories/photo.jpg gains a copy under images/webp/stories/photo.webp (and AVIF when enabled). Originals are never deleted. Deleting converted files only removes the modern copies.

Lazy conversion for ongoing traffic, or pre-warm folders when you control the launch date.

Step 1: Check hosting before you convert

Goal	What you need
WebP	PHP with GD WebP support (common on Joomla hosts)
AVIF	PHP 8.1+ with GD imageavif() or ImageMagick AVIF
Disk	Space for parallel copies (originals stay)
Joomla	4.x, 5.x, or 6.x

If AVIF is missing, start with WebP Only. That still solves most of the necessity case above.

Step 2: Install the converter plugin

From the install guide:

1. Buy or download from joomlax.com/webp-converter.html.
2. Unzip the outer WebPConverter_UNZIP.zip on your computer.
3. Install only the inner plg_system_webpconverter_….zip via System → Install → Extensions → Upload Package File. Do not upload the wrapper zip.
4. System → Maintenance → Clear Cache.
5. System → Plugins → search WebP Converter → enable System – WebP Converter.

Step 3: First-time settings that matter

Open the plugin → General Settings:

1. Image Format: WebP Only (add Both later if AVIF works)
2. WebP Quality: about 70 to 80 (100 is rarely worth the size)
3. Use Lightweight Processing: Yes on shared hosting
4. Debug Mode: No on production
5. Save, open the public homepage, hard-refresh

Proof: view source and search for .webp, or open an image in a new tab and check the extension.

Optional next: Exclusion Settings for GIF animations, no-webp class on logos, menu items like checkout, or folders such as headers. Details: Exclusion Settings.

Step 4: Convert a folder in bulk (recommended first test)

1. Plugin → Image Management
2. Tick one small folder (not Root on the first try)
3. Choose WebP Only
4. Click Generate Images and wait for completion
5. Clear Joomla cache and purge the CDN if you use one
6. Re-run PageSpeed Insights on a page that uses those images

If Generate does nothing, tick a folder and use Load more folders when the list is long. Stay logged in as an administrator.

Step 5: Features you turn on only when needed

You do not need every switch on day one. After basics work, these solve real gaps:

Need	Setting or capability
PageSpeed still shows JPG in meta or schema	Replace Image URLs Globally
Long pages	Native lazy loading (keep above-the-fold eager if offered)
Huge news archives	Flat output directory and/or hashed filenames
Checkout or shop quirks	Disable for menu items / components / URL patterns
Maximum compression	Image Format → Both (AVIF + WebP + original)
Shared hosting RAM pressure	Memory threshold and lightweight mode

Security extras (CSRF on AJAX, rate limits, logging) matter more on multi-admin sites than on a single-editor brochure site. Full feature list: product page.

After conversion: prove it helped in Google’s tools

1. Hard-refresh a key page. Confirm .webp (or AVIF) in Network or view-source.
2. Compare file sizes of hero images before and after.
3. Re-test mobile in Google PageSpeed Insights. Watch LCP and the next-gen image opportunities.
4. Check Google Search Console Core Web Vitals / Experience reports over the following weeks (field data updates slowly).
5. Purge CDN so Googlebot and users are not still hitting old JPEG URLs at the edge.
6. Spot-check Open Graph previews if you enabled global URL replace.

If images look wrong, lower quality slightly or exclude that asset. Originals are still on disk.

Plans if you use WebP Converter

From the official store, all with a 30-day money-back guarantee:

Plan	Price	Sites	Access
Tester	$19	1	30 days (testing)
6 Months	$29	2	Priority support
1 Year (recommended)	$49	3	VIP support channel
Lifetime	$99	Unlimited	Dedicated support

Pick Tester for a staging proof. Pick 1 Year or Lifetime if you maintain client sites. Docs: WebP Converter documentation. Support: support.joomlax.com.

AVIF-focused companion: Joomla AVIF converter and WebP optimizer.

Key takeaways

1. Google uses page experience and Core Web Vitals in ranking. Slow LCP images put you behind faster competitors.
2. Next-gen conversion is a must for websites that depend on Google: smaller files, better mobile UX, clearer PageSpeed reports.
3. Joomla keeps uploading JPG/PNG forever unless something converts them continuously.
4. Start with WebP. Add AVIF when hosting supports it.
5. Manual conversion does not scale. A system plugin fits ongoing editorial sites.
6. Verify in Google PageSpeed Insights and Search Console after you clear cache and CDN.

Agency help with speed and SEO: Joomla SEO services.

Frequently asked questions

Does WebP conversion help Google ranking?

Yes, indirectly but materially. Google uses Core Web Vitals and page experience as ranking signals. Faster LCP from smaller images helps you compete when content quality is similar. It will not replace good content, but it removes a common technical drag on Google visibility.

Why is a WebP converter a must for websites?

Because Google and users both punish slow pages. Images are often the heaviest assets. Without WebP or AVIF, mobile Google traffic pays the full JPEG cost, PageSpeed stays red on next-gen format audits, and ranking headroom goes to sites that already converted.

Why do I need a WebP converter for Joomla?

Because Joomla serves uploaded JPG and PNG as-is. Converting to WebP or AVIF cuts file size, improves LCP for Google, and clears common PageSpeed image warnings without redesigning the site.

Is WebP enough, or do I need AVIF?

WebP is enough for most sites. Use Both when the server can create AVIF and you want maximum compression with automatic fallbacks.

Will conversion delete my originals?

No, when you use a proper Joomla converter that writes parallel files. Originals stay under images/.

Can I convert without a plugin?

Yes, manually or at the CDN. Plugins win when editors keep uploading and you need folder exclusions and HTML replacement inside Joomla.

How do I know conversion worked?

View source for .webp or .avif, check Network sizes, and re-run PageSpeed after clearing cache and CDN.

Does this work on Joomla 5 and 6?

Yes for current WebP Converter builds aimed at Joomla 4, 5, and 6. Confirm your package version on the product page.

What if PageSpeed still shows old JPG URLs?

Enable global image URL replacement if your plugin offers it, regenerate, and purge CDN. Meta tags and schema often keep old paths until that pass runs.

Can I skip logos and animated GIFs?

Yes. Exclude formats, folders, filenames, or add a class such as no-webp on specific images.

What PHP do I need for AVIF?

PHP 8.1+ with GD imageavif() or ImageMagick with AVIF. Otherwise stay on WebP Only.

Where do I get setup help?

WebP Converter documentation and JoomlaX support. JoomlaX is Infyways’ extension store.

---

SEO Metadata

Field	Value
Meta Title	WebP Converter for Joomla: Google Ranking & Speed
Meta Description	How Google ranking and Core Web Vitals depend on image speed, why WebP/AVIF is a must, and how to convert on Joomla 4, 5, and 6.
URL Slug	image-to-webp-joomla
Focus Keyword	webp converter for joomla

Joomla Redirect Guide: 301, com_redirect, .htaccess, and nginx

A Joomla redirect sends visitors and crawlers from an old URL to a new one with an HTTP status code (usually 301). Joomla gives you three practical layers: server rules (.htaccess, nginx, or IIS) that run before PHP, the com_redirect component that runs after a 404, and Global Configuration switches that control how Joomla builds links. Pick the layer that matches whether the old URL still returns 200 or already 404s.

Redirects are not a cosmetic tweak. They are how you keep rankings when you rename an article, retire K2, force one hostname, or move HTTP to HTTPS without splitting authority across two URLs. Google treats a proper 301 as a strong signal to consolidate to the destination: Consolidate duplicate URLs.

This guide is the full map for Joomla 4, 5, and 6. For the "I saved a 301 and nothing happened" checklist, see Joomla 301 redirects not working.

Server rules run first. com_redirect only fires when Joomla has already decided the path is a 404.

What you will learn

• What 301, 302, and 307 mean in Joomla
• When to use .htaccess, nginx, com_redirect, or neither
• How to enable System – Redirect and publish rows in System → Redirects
• Exact .htaccess rules for www, non-www, and HTTP to HTTPS
• nginx and IIS equivalents when there is no .htaccess
• How to test headers, avoid redirect chains, and protect SEO after a migration

301, 302, and what Joomla actually sends

Code	Name	Use in Joomla
301	Moved permanently	Default for SEO migrations, retired aliases, www/HTTPS canonicalization
302	Found (temporary)	Short campaigns, A/B tests, maintenance you will reverse
307	Temporary redirect	Rare in Joomla admin; some server modules use it instead of 302

com_redirect defaults to 301 unless your Joomla version exposes per-row status codes under Redirects → Options. Server rules use [R=301] in Apache or return 301 in nginx.

A Menu Item Alias is not a redirect. It shows the same article at a second menu path while both URLs can still 200. Aliases are navigation. Redirects are HTTP responses. If two real menu items point at one article, you have duplicate URLs until you unpublish one or 301 the loser: Joomla duplicate URLs.

Pick the right layer

Layer	When it runs	Use it for
.htaccess (Apache / LiteSpeed)	Before PHP boots	www ↔ bare host, HTTP → HTTPS, /index.php/alias → /alias, folder moves, anything that still 200s
nginx server / location	Before PHP	Same jobs on nginx hosts (no .htaccess)
IIS web.config	Before PHP	Windows hosts
com_redirect + System – Redirect plugin	After Joomla returns 404	Old article aliases, retired menu paths, K2 URLs after uninstall
Global Configuration → Server → Force HTTPS	Link generation in Joomla	Makes Joomla emit https:// links. Pair with a server 301 for typed http:// visits
System – SEF	Rewrites URLs in HTML	Cleaner paths. Not a substitute for 301 when an old URL still resolves

Official component help: Redirects: Links (Joomla 5) and Redirects: New or Edit. Stock Apache snippets live in preconfigured htaccess.

If the old URL still loads a page, com_redirect never runs. Fix that at the server or unpublish the route.

Step 1: Set up com_redirect (Joomla 4, 5, and 6)

Use the component when the expired path is already a 404 and you want to manage dozens of mappings in the administrator.

Enable the plugin (not optional)

1. System → Plugins → search System – Redirect → Enable.
2. On fresh installs this plugin is often disabled. Rows in System → Redirects do nothing until it is on.

Do not confuse it with System – SEF. SEF builds pretty links. It does not send 301s for dead paths.

Create a redirect row

1. System → Redirects → New.
2. Expired URL: the full old address as you would type it (https://www.example.com/old-alias).
3. New URL: the full destination.
4. Status: Enabled (published). Collected 404s stay disabled until you add a New URL and publish.
5. Save.

Optional: turn on Collect URLs in the plugin so 404s appear in the list for you to map. Collection is logging, not redirecting.

Regex and bulk work

• Enable Regular expressions on a row when you need a pattern (example: all /blog/2019/ paths). Test one URL before importing hundreds.
• After a K2 removal, map /component/k2/... to new com_content URLs as part of Migrate K2 to Joomla articles. Do not leave public 404s while you "collect later."
• Joomla expects Use URL Rewriting on and a working rewrite file, or matching is unreliable. See Joomla index.php still in URLs.

If a row is published and the old URL still shows the old page, a menu item or alias is still serving it. com_redirect cannot help until that route 404s or you move the job to .htaccess.

Step 2: Redirect www and non-www in .htaccess

Pick one canonical host (www or bare) and 301 everything else. This belongs in server config, not in com_redirect.

Joomla ships a commented block in .htaccess labeled custom redirects. Place rules after RewriteEngine On and before the Joomla core rules, or inside the documented custom section from preconfigured htaccess.

Bare → www (replace example.com):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

www → bare:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

Notes:

• Use your real domain. Escape dots in the host (example\.com).
• If you also need HTTP → HTTPS, chain both conditions or use one rule that targets the final https:// host.
• [NC] makes the host match case-insensitive. [L] stops processing. [R=301] sends the permanent redirect.

After editing, purge CDN cache and test in a private window. The address bar should show your chosen host on the first hop.

Step 3: Force HTTPS at the server and in Joomla

Server (Apache / LiteSpeed)

Below RewriteEngine On, when SSL is working:

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

Better: combine host canonicalization and HTTPS in one rule set so you do not create a chain (http://example.com → https://example.com → https://www.example.com).

Joomla Global Configuration

System → Global Configuration → Server → Force HTTPS: set to Entire Site once the certificate is valid. That makes Joomla generate https:// links in HTML. It does not always redirect a visitor who manually types http://. Keep the server rule for that.

Step 4: Single-path and migration redirects in .htaccess

When one old path still 200s but must point elsewhere:

Redirect 301 /old-folder/page https://www.example.com/new-alias

Or with mod_rewrite:

RewriteRule ^old-alias/?$ https://www.example.com/new-alias [L,R=301]

Use this for:

• Renamed menu aliases while the old menu item still exists
• /index.php/seo-tips → /seo-tips after SEF is fixed
• Retired microsite folders

For large content moves, pair server rules for structural changes with com_redirect rows for long-tail aliases that already 404.

Step 5: nginx and IIS when Joomla has no .htaccess

nginx (inside the server block for the site):

# bare to www + HTTPS (adjust host names)
if ($host = example.com) {
    return 301 https://www.example.com$request_uri;
}
if ($scheme = http) {
    return 301 https://$host$request_uri;
}

Official Joomla nginx notes: Nginx. You still need try_files so SEF works: details in Joomla index.php URLs.

IIS: rename web.config.txt to web.config, install URL Rewrite, and add equivalent rules. Joomla documents IIS rewriting alongside Apache in Enabling SEF URLs.

Step 6: Test headers, chains, and loops

1. Browser Network tab → first document request → Status should be 301 (or 302 if intentional) with a Location header pointing at the final URL.
2. Command line: curl -I https://www.example.com/old-path and read HTTP/1.1 301 plus Location:.
3. Avoid chains longer than one hop (/a → /b → /c). Google will follow them but dilutes signals. Point /a straight to /c.
4. Loops (/old → /new → /old) crash the browser. Usually a com_redirect New URL points back at the expired path.
5. Clear Joomla cache and any CDN. Cached 404 HTML can hide a redirect you just published.

Canonical tags complement redirects but do not replace them when both URLs still 200: Joomla canonical URL problems.

Redirect mistakes that still waste SEO

Mistake	Why it hurts	Fix
302 instead of 301 for a permanent move	Search engines may not consolidate equity	Use 301 in server rules or Redirect options
Old URL still 200	com_redirect never runs	Unpublish menu item or use .htaccess
Plugin off, rows published	Looks configured	Enable System – Redirect
Slash / www / HTTP mismatch	Row does not match request	Add rows for each variant or force one host at server
Only fixing canonical, not 301	Two indexable URLs remain	301 losers after duplicate audit
Leaving K2 404s public	Crawl budget on dead paths	301 map during K2 migration

Key takeaways

1. 301 is the default for permanent Joomla URL changes that should pass ranking signals.
2. Server rules handle www, HTTPS, and paths that still return 200. com_redirect handles paths that already 404.
3. Enable System – Redirect. The component UI alone is not enough.
4. Publish redirect rows. Collected 404s are a log until Enabled with a New URL.
5. Match the full expired URL (scheme, host, slash) or canonicalize host at the server.
6. Test with response headers, not only whether the browser lands on the right page.
7. After migrations, map old aliases before you declare SEO done. Broader cleanup: Joomla on-page optimization and Joomla SEO services.

Frequently asked questions

What is a 301 redirect in Joomla?

An HTTP response that tells browsers and crawlers a URL moved permanently. Joomla can send it via com_redirect after a 404, or via .htaccess, nginx, or IIS before PHP runs.

Should I use com_redirect or .htaccess?

Use .htaccess (or nginx/IIS) for www, HTTPS, and any old URL that still loads. Use com_redirect when the old path already 404s, such as retired article aliases.

How do I redirect non-www to www in Joomla?

Add Apache rewrite rules after RewriteEngine On in .htaccess, or the nginx/IIS equivalent. Do not rely on com_redirect for hostname changes while both hosts still 200.

How do I redirect HTTP to HTTPS in Joomla?

Force HTTPS in Global Configuration → Server for link generation, and add a server 301 from http:// to https:// so manual HTTP visits redirect too.

Why is my Joomla 301 redirect not working?

Usually the System – Redirect plugin is off, the row is unpublished, or the old URL still returns 200. Full checklist: Joomla 301 redirects not working.

Does Joomla redirect preserve SEO?

A correct 301 tells search engines to consolidate signals to the new URL. Chains, 302s, and duplicate 200 URLs undermine that.

Can I bulk import redirects in Joomla?

Yes on many Joomla 4/5/6 builds via System → Redirects import (CSV). Test a few rows, then import. Regex rows need extra care.

Is a menu alias the same as a redirect?

No. An alias serves the same content at a second menu path. Both can 200. A redirect returns 301/302 and stops serving the old URL.

What about IIS servers?

Rename web.config.txt, install URL Rewrite, and add host and HTTPS rules there. com_redirect still works for 404 paths on IIS.

Where do I put custom .htaccess redirects?

Use the custom redirects section documented in Joomla's preconfigured htaccess, after RewriteEngine On, without breaking the core Joomla rewrite block.

---

SEO Metadata

Field	Value
Meta Title	Joomla Redirect Guide: 301, com_redirect & .htaccess
Meta Description	Set Joomla 301 redirects with com_redirect, .htaccess, nginx, or IIS. www, HTTPS, old aliases, and which layer to use. Joomla 4, 5, and 6.
URL Slug	joomla-redirect
Focus Keyword	Joomla redirect

To create a custom 404 page in Joomla 5 or 6, publish a Custom HTML (or other) module in the error-404 position on Cassiopeia or a child of Cassiopeia. Joomla still returns HTTP 404. The module replaces the default message inside error.php. Do not header('Location: …') to a normal article. That turns a missing URL into a 302 or 200, which is what the 2019 version of this page did, and it is the wrong signal for Google.

On Joomla 4 there is no error-404 position in core Cassiopeia. You copy error.php into a child template and edit that copy, or you add the same module include that Joomla 5 shipped. Known broken URLs that should move, not 404, belong in the Redirect component.

A custom 404 is still a 404. Pretty HTML does not mean a 200 OK.

What you will learn

• Why a redirect to an article is not a 404 page
• How Cassiopeia error-404 and error-403 modules work (Joomla 5.0+)
• How to put the same pattern in a child template or a club template
• What to put on the page (search, home, useful links)
• How to test status codes, not only the design
• When to 301 instead of 404

Official module positions: Custom Error Pages (Joomla 5.4 manual). Magazine walkthrough: The 404 That Could (JCM, November 2025).

The 2019 method, and why to stop using it

The old Infyways steps were: create a 404 article, noindex it, copy error.php, then:

header('Location: /index.php?option=com_content&view=article&id=292');
exit;

What you wanted	What that code does
“Page not found” for humans	A second request to a real article
HTTP 404 for Google	Usually 302 then 200 on the article
One branded error view	A normal com_content URL that can get indexed unless you fight robots

Search engines need 404 (or 410) for URLs that are gone with no replacement. Soft 404s (200 with “not found” text) waste crawl time. If the URL moved, use a 301 in System → Redirects, not a custom error page.

If your site still has that Location block in error.php, delete it before you add a module. Put the file in a child so the next Cassiopeia update does not restore a hack, and so your fix is not wiped. Rule: customize Joomla without editing core.

Joomla 5 and 6: the error-404 module (preferred)

Cassiopeia since Joomla 5.0 reads modules in:

• error-404 for not found
• error-403 for forbidden

If no module is published there, visitors still get the default language strings. Debug output still appears under the module when debug is on.

No error.php edit is required on stock Cassiopeia 5+. A child still needs the same include if you copied a thin error.php.

Step 1: Use a child template

Create and assign a Cassiopeia child if you do not have one. How to set up a Joomla child template.

Club templates: check whether they already declare error-404. If not, you will add the include in Step 4.

Step 2: Create the 404 content as a module

1. Content → Site Modules → New
2. Type: Custom (Custom HTML). Search, Latest Articles, or a menu module also work.
3. Title: something you can find later, for example 404 message. You can hide the title.
4. Write the message: short apology, home link, search, two or three real destinations. Keep it useful, not a joke that hides the next click.
5. Position: type error-404 if it is not in the dropdown. Cassiopeia 5+ accepts it even when the style UI is thin.
6. Status: Published. Menu assignment: On all pages. The error document is not a normal menu item. All pages is the safe assignment.
7. Save.

Use absolute https:// URLs for images and the home link. Relative src="images/…" often breaks on nested missing paths (/category/no-such-page). That is a known error-page path issue. Prefer full URLs until your Joomla patch level includes the error-page SEF fixes.

Step 3: Test the status, then the design

Open a URL that does not exist, for example https://www.example.com/this-page-is-not-real.

You should see your module. Then check the status:

• Browser Network tab, or
• curl.exe -sI https://www.example.com/this-page-is-not-real

You want HTTP/1.1 404 (or 404 from HTTP/2). If you see 200 or 302 to /404 or to an article, you still have a redirect in error.php or in .htaccess.

Step 4: Joomla 4, or a template without error-404

Copy parent error.php into the child (same filename at the child template root), then add the official include. Do not edit the parent Cassiopeia file.

<?php
$errorCode = $this->error->getCode();
?>
<?php if ($this->countModules('error-' . $errorCode)) : ?>
  <div class="container">
    <jdoc:include type="modules" name="error-<?php echo $errorCode; ?>" style="none" />
  </div>
<?php else : ?>
  <?php // keep the template's original default message here ?>
<?php endif; ?>

That snippet is the Joomla custom error pages pattern. Wrap it around the default heading so you do not delete fallback text.

A full branded layout is still error.php in the child: logo, user.css, maybe a search module. Same child rule as any other PHP file.

Step 5: 403, Redirects, and language strings

Need	Tool
Forbidden (logged-out vs ACL)	Module in error-403, same idea as 404
Old URL has a new home	System → Redirects, 301. Not a 404 page
Default “page not found” wording only	Language override, if you are not using a module
Pretty CSS	Child user.css, not a core Cassiopeia sheet

Do not noindex a real 404 URL in an article. There should not be a public article acting as the 404 document.

Key takeaways

1. A custom 404 page must keep HTTP 404. Do not redirect error.php to a com_content article.
2. On Joomla 5 and 6 Cassiopeia, publish a module in error-404.
3. Put PHP and CSS in a child template. Parent updates will replace error.php if you edited Cassiopeia itself.
4. Use absolute URLs for images and home on the error document.
5. Test with a fake path and with the response code.
6. Moved content is a 301. Gone content is a 404. Soft 200 is the worst of both.

Need a branded error page built into a client template? Joomla design services. Ongoing 404 cleanup: Joomla SEO services.

Frequently asked questions

How do I create a custom 404 page in Joomla 5?

Publish a Custom HTML module in the error-404 position on Cassiopeia (or a child that includes that position). Visit a missing URL and confirm HTTP 404.

Should a Joomla 404 page return HTTP 200?

No. 200 on a not-found URL is a soft 404. Keep 404. Redirects belong in the Redirect component when the page moved.

Does the error-404 module work on Joomla 4?

Not in core Cassiopeia 4. Copy error.php into a child and add the error-{code} module include, or run Joomla 5+ Cassiopeia.

Why are images broken on some 404 URLs?

The missing path is nested, and the image used a relative URL. Use absolute https:// links. Update Joomla when error-page SEF path fixes are in your branch.

Can I use an article as the 404 page?

You can, if you redirect to it. You should not. You lose a clean 404. Use a module on the error document instead.

Will a Cassiopeia update delete my 404 module?

No. Modules live in the database. A parent error.php you edited by hand can be overwritten. Keep PHP in a child.

To enable maintenance mode in Joomla, open System → Global Configuration, stay on the Site tab, set Site Offline to Yes, choose an offline message (and optional image), then Save. Guests see the offline page with a login form. The administrator stays available. This is core Joomla. You do not install a plugin. The same switch works on Joomla 4, 5.4, and 6. Joomla calls it Site Offline, not “maintenance mode.” Searchers use both names.

The 2019 version of this page stopped at “set Yes and Save.” That is still the click. In 2026 you also need Offline Access for staff who are not Super Users, a message that is not a language-file hack, and a way back in if Global Configuration will not save.

Site Offline hides the frontend from guests. It does not lock you out of administrator.

What you will learn

• Where Site Offline lives on Joomla 4, 5, and 6
• How to set a custom message and an offline image
• Who can still log in on the frontend while the site is offline
• How to grant Offline Access without making everyone a Super User
• How to restyle the offline page in a child template
• How to force the site online if configuration.php is stuck

Official walkthrough: Taking the website temporarily offline. User manual: Site Offline.

Site Offline versus a real outage

Situation	Use
Planned update, template work, extension install	Site Offline in Global Configuration
White screen, 500, or you cannot open administrator	That is a break, not maintenance. Start with diagnostics, not this switch
You want HTTP auth in front of Joomla	Directory privacy on the host. The Joomla guide covers that as a separate “all users” lock
You only want a banner, site still public	A module or a custom message, not Site Offline

Site Offline is a flag in configuration.php (public $offline). When it is 1, the frontend layout is the offline view. Administrator is unchanged.

Step 1: Open Global Configuration

Log in to administrator.

On Joomla 4, 5, and 6 go to System → Global Configuration. The Home Dashboard also has a Global Configuration icon. Both open the same form.

Stay on the Site tab. That is the first tab. If you landed on Server or Permissions, click Site.

Step 2: Set Site Offline to Yes

Find Site Offline. Set it to Yes.

Joomla then shows the offline-related fields: Offline Message, Custom Message, Offline Image.

Do not Save yet if you still need to write the visitor-facing text. An empty custom message with “Use Custom Message” selected looks broken.

Save last. Test the frontend in a private window after Save.

Step 3: Choose the message and image

Offline Message has three useful values:

Setting	What visitors see
Site language default	The string from the site language file. English is “This site is down for maintenance. Please check back again soon.” Other languages use their own translation
Use custom message	The text in Custom Message
Hide	No message block. The login form can still appear

Prefer Use custom message for a dated note: what you are doing, when you expect to return, a status URL if you have one. Do not promise a clock you cannot keep.

Offline Image is optional. The help screens still advise keeping it under 400px wide. Upload through Media, then select it here. A huge PNG on a maintenance page is a bad first impression.

If you only need to change the default English sentence and you are not using a custom message, use a language override for that string. Do not edit core .ini files.

Step 4: Save and test as a guest

Click Save or Save & Close.

Open the public site in a private window, or another browser, not the session that is already logged in as Super User. Super Users with frontend access will not see what guests see.

You should get the offline page and a login form. Administrator at /administrator/ must still load.

If Global Configuration refuses to save, configuration.php is not writable. Fix permissions or the FTP layer, then try again. Joomla documents this under Cannot save Global Configuration changes.

Step 5: Decide who may enter while it is offline

The user manual is explicit: Site Offline does not apply to administrator. People who can log in to the backend can still log in to the frontend. Frontend login is denied by default to Registered, Author, Editor, and Publisher.

Staff who are not Super Users need Offline Access.

1. System → Global Configuration → Permissions
2. Select the group (for example Manager, or a custom “Editors on call” group)
3. Set Offline Access to Allowed
4. Save

Do not grant Super User to “let them see the site during maintenance.” That is the wrong permission.

Step 6: Customize the offline page without editing core

The default offline layout is a PHP view. To change markup, copy the layout into a child template html/ override. Do not edit Cassiopeia or components/ in place. Same rule as every other file Joomla will overwrite: customize Joomla without editing core.

CSS for the offline page belongs in that child’s user.css, not in a compiled template sheet.

If the job is a full branded holding page and you do not want to own the override, Joomla design services.

Step 7: Turn maintenance mode off

When the work is done:

1. System → Global Configuration → Site
2. Site Offline → No
3. Save

Test as a guest again. If you still see offline, you are looking at cache (Joomla page cache, Cloudflare, or the browser). Purge those layers.

If you are locked out of the switch

If administrator is up but you cannot save Site Offline, or you need the site public from the server:

1. Backup configuration.php.
2. Open it in a file manager or SFTP.
3. Find public $offline.
4. Set it to '0' for online, '1' for offline.
5. Save. Confirm the file is not left world-writable.

Only do this when the admin form cannot save. A typo in configuration.php takes the whole site down.

Key takeaways

1. Joomla maintenance mode is Site Offline in Global Configuration on the Site tab.
2. No extra extension is required on Joomla 4, 5, or 6.
3. Save, then test in a private window. A Super User session is a bad test.
4. Custom Message plus an optional image under 400px is the visitor-facing layer.
5. Grant Offline Access to staff groups. Do not promote them to Super User for this.
6. Override the offline layout in a child template. Leave core files stock.
7. If the form will not save, $offline in configuration.php is the emergency switch.

Need this done during an upgrade window? Joomla support and maintenance.

Frequently asked questions

How do I enable maintenance mode in Joomla 5 or 6?

Open System → Global Configuration → Site tab, set Site Offline to Yes, set the message, then Save. The administrator stays online.

Is Site Offline the same as maintenance mode?

Yes, for Joomla. The product name is Site Offline. Searchers say maintenance mode. It is one switch.

Can visitors still log in when the site is offline?

Only groups with Offline Access (and users who can already use the backend). Registered, Author, Editor, and Publisher cannot, unless you change Permissions.

Does Site Offline hide the Joomla administrator?

No. /administrator/ stays available. Use host-level directory protection if you need to hide that too.

Why do I still see the live site after setting Site Offline to Yes?

You are logged in with access, or cache is serving the old HTML. Use a private window and clear Joomla plus CDN cache.

Can I change the offline page HTML?

Yes. Put an override in a child template. Do not edit core PHP. See Joomla child template.

What if Global Configuration will not save?

Make configuration.php writable long enough to save, or set public $offline by hand, then lock permissions down again.

To add a favicon in Joomla, change what the active site template (or a system plugin) prints in the page head as rel="icon". That is not always Cassiopeia, and it is not always three Joomla-named files. Helix, T4, Gantry, YOOtheme, and most club templates have their own favicon field or their own filenames. Cassiopeia is only the core default. View source, find the current href, then use that template’s option, replace that file, or inject a pack and strip the old tags.

A favicon is the mark in the browser tab, bookmarks, and (with extra sizes) on a phone home screen. Joomla 4, 5, and 6 all work the same way at the HTTP level: whatever is in <head> wins. This guide starts with that, then covers template options, Cassiopeia’s media files as one special case, cache, and when a generator plugin is easier than fighting five different template UIs.

The tab shows whatever the assigned template or a plugin put in the head. Cassiopeia is one of those templates, not the only one.

What you will learn

• How to see which URL Joomla is actually using for the icon
• Where commercial templates usually store the favicon (style options)
• The Cassiopeia-only three-file names, if that is your template
• Why Atum (administrator) is a separate pack
• How cache hides a correct upload
• When Easy Favicon is the template-agnostic manager

Do not edit parent index.php to hard-code a <link>. Same rule as CSS: customize Joomla without editing core. Prefer a child template when you must change files.

Step 1: See what is in the head

Open the public site. View source. Search for rel="icon", apple-touch-icon, and shortcut icon.

Write down:

• The href (that is the file you must replace, or the tag you must override)
• Whether there is more than one icon link (SVG plus ICO plus Apple is normal)
• Whether the path is media/templates/…, templates/…, images/…, or a CDN

If Helix (or another club template) prints a tag after Cassiopeia’s, the later tag often wins in the browser. Replacing Cassiopeia files then looks like “Joomla ignored me.” You were on the wrong template.

Also check System → Site Template Styles. The style with the star (and any menu assignment) is the one that must receive the change.

Step 2: Use the template’s own favicon control

Most paid templates never use joomla-favicon.svg. They expect an upload in Template Styles.

Template family	Where to look first
Helix Ultimate / JoomShaper	Template Options → a logo or favicon / favicon ICO field (name varies by version)
T4 (Joomlart)	Template style → theme / site identity
Gantry 5	Outline → Page Settings or atom for favicon
YOOtheme Pro	Customizer → favicon / apple-touch
Other club templates	Search the style for “favicon”, “icon”, or “site identity”
Cassiopeia (core)	No favicon field. Use the media files in the next section
Atum (core admin)	Separate administrator template. Frontend files do not change the backend tab

Upload a square PNG or ICO, 512×512 or larger if the field accepts PNG. Save the style. Then skip to cache (Step 4) and prove the new href in view source.

If the field only stores one ICO, you still will not get Apple 180 or Android adaptive icons unless the template generates them. That gap is why a pack plugin exists.

Step 3: Replace files only when the head points at files

This is the right move when view source shows a path under your template’s images or media folder.

Cassiopeia (and a Cassiopeia child) is the documented core case. It loads three names:

• joomla-favicon.svg (rel="icon")
• favicon.ico (rel="alternate icon")
• joomla-favicon-pinned.svg (rel="mask-icon")

Path on Joomla 4.1, 5, and 6:

media/templates/site/{template}/images/

If the assigned style is a child cassiopeia_brand, that folder is media/templates/site/cassiopeia_brand/images/. Replacing files only on parent Cassiopeia does nothing while the child is default.

If you replace only favicon.ico, Chrome can keep the SVG. Replace all three. Official map: Cassiopeia Template Folders and Files.

Any other template: do not invent those three Joomla filenames. Replace the file the href already names, or use the template option in Step 2. Joomla 4.0-era templates/{name}/images/ still appears on old forks. Match the live href, not a blog from 2017.

Root /favicon.ico: some bots still request it. It does not override a later SVG in Chrome.

Wrong template style, or the wrong filename, is why the Joomla mark remains.

Step 4: Clear cache and test in a clean browser

1. System → Maintenance → Clear Cache
2. Purge CDN cache if you use one
3. Private window, or a browser profile that has not seen the old icon

Chrome on phones caches favicons hard. View source again. The href must change. If it did not, you edited the wrong style or the template is still injecting the old URL.

Pick the method

Situation	Do this
Club template with a favicon upload	Step 2. Then view source.
Cassiopeia or Cassiopeia child	Three named files in that template’s media images/ folder
Head shows a path you do not recognise	Replace that file, or the template option that wrote it
Several icon tags from the template plus a plugin	Strip or disable one source. Two systems fighting is the usual mess
Apple, Android, dark mode, different admin tab	Pack plugin (next section), or a full generator ZIP plus template fields
Administrator tab still Joomla	Atum media files or an admin pack. Frontend changes never touch it

Managing icons across templates with Easy Favicon

Template options and Cassiopeia files are enough when you have one ICO and a cooperative theme. They are a poor manager when every client site uses a different template, or when Helix keeps printing the old apple-touch link.

Easy Favicon is a JoomlaX system plugin for Joomla 4, 5, and 6. It is template-agnostic: one master image, generate the pack, inject tags, optionally strip competing favicon and apple-touch tags so Helix, T4, or Cassiopeia defaults lose. That is the point of mentioning it here. It is not required to “add a favicon.”

From System → Plugins → System – Easy Favicon you can manage:

Need	What it does
One upload, usual sizes	16, 32, 48, Apple Touch 180, Android 192 and 512, optional ICO
Site vs administrator	Site pack, optional admin pack (reuse or a second master)
Dark OS theme	Optional dark masters
Android cropping	Maskable padding and background
Template still winning	Strip level for foreign icon tags
Mobile chrome	theme-color meta
Another PWA owns the manifest	Off, Generate, or Defer
Handoff	Preview, regenerate, ZIP. Files under images/easyfavicon/

PHP 8.1+, GD or Imagick. No jQuery. Icons stay on your server.

First run: install the inner plugin zip, enable it, choose a square master (512×512+ PNG or SVG), Generate all icons, clear cache, check the public tab, then the admin tab if the admin pack is on. If generate fails, check GD/Imagick. If the old icon remains, raise strip strength and purge CDN. If a PWA extension owns the manifest, set Defer or Off.

Docs: Easy Favicon documentation. Demo: Easy Favicon demo. JED listing. JoomlaX is Infyways’ extension store.

Key takeaways

1. The favicon is whatever the assigned template or plugin puts in <head>. Start with view source.
2. Most commercial templates use a style option, not Cassiopeia’s three filenames.
3. Cassiopeia is the core default: joomla-favicon.svg, favicon.ico, joomla-favicon-pinned.svg in that template’s media images/ folder, preferably a child.
4. Atum (admin) is a second template. Frontend files do not change the backend tab.
5. Prove the new href, then fight cache.
6. A pack plugin is for multi-size, admin, dark mode, and stripping template tags, not for every simple ICO swap.

Client branding across club templates: Joomla design services.

Frequently asked questions

How do I add a favicon in Joomla 5 or 6?

Find the assigned template style. Use its favicon option if it has one. On Cassiopeia, upload the three named files to that template’s media images/ folder. Clear cache and check view source.

Does this only work with Cassiopeia?

No. Cassiopeia is the core default and uses three specific filenames. Most live sites use Helix, T4, Gantry, YOOtheme, or another club template. Start from view source and that template’s style options.

Why does Chrome still show the old icon?

Wrong template style, a later tag from a club template, only one of several files replaced, or favicon cache. View source before you upload again.

Do I need a plugin?

No, if the template option or file replace already updates rel="icon". Yes, if you need a full size pack, a separate admin icon, or to strip Helix (or similar) tags.

Where do Easy Favicon files live?

Under images/easyfavicon/. The plugin injects head tags. You do not have to name Cassiopeia’s three files when it is managing the pack.

Will a template update delete my favicon?

A parent template media file can come back. A child, a template-style upload in the database, or plugin files under images/easyfavicon/ are safer.

---

SEO Metadata

Field	Value
Meta Title	Add a Favicon in Joomla: Any Template, Not Only Cassiopeia
Meta Description	Add a Joomla favicon from the assigned template: style options, Cassiopeia media files, or a pack that strips club-template tags. Joomla 4, 5, and 6.
URL Slug	add-favicon-in-joomla-website-howto-guide
Focus Keyword	add favicon in 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.