Blog

The benefits of Joomla migration are concrete: you leave an unsupported major (especially Joomla 3 after August 2023), land on a release that still receives security fixes, run on PHP 8.x hosting hosts still sell, and unlock core features that used to need third-party extensions. In project language, a migration is a major structural hop (typically 3.10 to 4.4). A upgrade is the smoother path the project documents for 4.4 to 5 and 5.4 to 6. Both are what buyers mean when they search for Joomla migration benefits.

Most articles on this topic stop at “security and speed,” or they stop at Joomla 5. Official docs explain why to migrate. Agency posts list three to ten reasons. Almost none combine official terminology, the full 3 through 6 hop map, Joomla 6 auto-updates, support end dates, when you should wait, the Behaviour – Backward Compatibility 6 rules, cleanup ROI, and a staging plan in one place. That is what this guide does, plus how Infyways runs the work from $149 with a free audit within 12 hours.

What you will learn

• Migration versus upgrade versus patch update (with the hop order that actually works)
• Every major benefit: security, PHP and hosting, performance, admin UX, SEO, accessibility, multilingual, core features, Joomla 6 auto-updates
• Official support windows so you know when urgency is real versus marketing panic
• Why migration is also a cleanup project (the angle official docs emphasize)
• What you lose by waiting on Joomla 3 or early 4, and when Joomla 5 owners can wait
• How to start with Infyways without treating “click Update” as a plan

Migration, upgrade, or patch: use the right word

Confusion here is why thin competitor posts mislead people into a one-click 3 to 6 fantasy.

Change	Official framing	Example	What you should expect
Patch	Update	5.4.2 to 5.4.3	Same major. Use System → Update → Joomla. See update errors
4.4 to 5.x	Upgrade (not a full migration)	4.4.x to 5.4.x	Many extensions work; Behaviour – Backward Compatibility helps. Plan on staging
5.4 to 6.x	Upgrade	5.4 to 6.0+	Disable Behaviour – Backward Compatibility (no number). Keep Behaviour – Backward Compatibility 6 enabled. See compat plugin guide
3.10 to 4.4	Mini-migration / migration	3.10 to 4.4	Template and extension triage. Protostar does not survive
3.x toward 5 or 6	Multi-hop migration	3.10 → 4.4 → 5.4 → 6	Never a single updater click. Path: 3 to 4, 5, and 6

Primary sources: Why Migrate, 4.4 to 5 planning, 5 to 6 planning, and the Joomla 6.0 / 5.4 announcement.

Support windows that decide urgency

Scare posts skip dates. The Joomla roadmap and project announcements make urgency measurable:

Line	Bugfix / regular support	Security-only support	What that means for migration
Joomla 3.10	Ended August 2023	Ended August 2023	Migrate now. There is no official patch line left
Joomla 4.x	Ended (security ended 14 October 2025)	Ended	Treat as EOL. Move to 5.4 then plan 6
Joomla 5.4.x	Through 13 October 2026	Through 12 October 2027	Safe to stay while extensions catch up for J6, if you are already on 5.4
Joomla 6.x	Through 17 October 2028	Through 16 October 2029	Active feature line. Finish here when staging is green

So: Joomla 3 and 4 owners have a real security deadline. Joomla 5.4 owners have a planning window, not a midnight panic, unless the host or an abandoned extension forces the move sooner.

Benefit 1: Security support that still exists

Joomla 3.10 reached end of life in August 2023. The site does not magically shut off. Official security patches stop. That is the first benefit of migrating: you are on a maintained line again.

• Core CVEs ship on current 5.x and 6.x.
• Abandoned Joomla 3 extensions stop being a permanent attack surface once you replace or rebuild them.
• Hosts and insurers increasingly treat EOL CMS stacks as unacceptable risk.

Thin “3 reasons” posts mention security once. The operational point is this: every month on EOL core is a month where your risk grows and your vendor options shrink.

Benefit 2: PHP and database versions you can still buy

Hosts retire PHP 7 and old MySQL. Joomla 5 needs PHP 8.1 or newer. Joomla 6 needs PHP 8.3 or newer (8.4 recommended), with MySQL 8.0.13+ / MariaDB in the supported range or PostgreSQL 14+ class. Requirements: Joomla technical requirements.

Target	PHP	Why migration unlocks hosting
Joomla 5	8.1+	Matches mainstream shared hosting in 2026
Joomla 6	8.3+ (8.4 recommended)	Keeps the next renewal cycle viable

Official docs also warn that hosts will not keep ancient stacks forever. Migration is often forced by the server long before the marketing team asks for new features.

Benefit 3: Performance without the legacy JS tax

Current Joomla uses modern PHP, a cleaned codebase, and the Web Asset Manager so templates load scripts only when needed. Core no longer ships MooTools. Default templates are built for current Core Web Vitals expectations.

The caveat competitors skip: speed appears when the template and bloated extensions move with the core. Migrating the CMS and keeping a Joomla 3 club template untouched does not deliver the performance benefit. Related: remove MooTools from Joomla.

Benefit 4: An administrator people will actually use

From Joomla 4 onward the back end is a different product: clearer navigation, Guided Tours, a usable media manager (including AVIF on modern releases), and Dark Mode that editors notice. Magazine writers call out the adjustment period from Joomla 3, then the productivity gain. That matches what we see on client handovers.

Benefit 5: Core features that replace paid extensions

This is the benefit Why Migrate stresses and most agency blogs underwrite. Current Joomla can cover work that used to need a stack of third-party tools:

• Custom fields for structured content
• Workflows for editorial approval
• Tags and Smart Search instead of legacy Search
• Media manager improvements instead of a separate DAM for small sites
• Cassiopeia child-style customization on recent releases without forking the whole template

Migration is the moment to uninstall unused modules, kill “great ideas” that never launched, and reduce license sprawl. That lowers cost after go-live, not only risk.

Benefit 6: SEO you can defend

Joomla does not rank higher because the version number changed. You benefit because:

• Modern routing and SEF stay maintainable
• You can keep aliases and ship a 301 map when something must change
• Schema and accessibility improvements support how Google evaluates pages
• The site stays fast enough and online during crawl windows

Rankings die on broken SEF, 500s after a botched live update, or months of downtime. Staging protects that. Troubleshooting: Joomla upgrade issues and Joomla SEO.

Benefit 7: Accessibility, multilingual, and compliance

• Accessibility: current admin and Cassiopeia-oriented front ends take WCAG-oriented patterns seriously. Public sector and education RFPs increasingly require that.
• Multilingual: language handling and related tooling are stronger than on Joomla 3-era stacks, which matters for EU and multi-region sites.
• Support window: majors follow a planned lifecycle (on the order of multi-year support per major). You get time to plan the next hop instead of living in permanent panic.

Benefit 8: Joomla 6 features worth finishing the path for

Posts that stop at “move to Joomla 5” are already dated. From 5.4 into 6 you also gain reasons to complete the journey:

• Automatic core updates with the secure update framework introduced across 5.4 and 6.0
• Behaviour – Backward Compatibility 6 so more extensions survive the hop while vendors catch up
• Extended versioning that reaches further into custom fields and related content structures
• Language file caching and media manager improvements
• Editor updates (TinyMCE on the current 6.x line) for day-to-day publishing
• Child templates and richer content tools that reduce forking Cassiopeia for small design changes

Before the hop: prove every third-party extension runs on Joomla 5.4 with the older Behaviour – Backward Compatibility plugin disabled. Then upgrade with Behaviour – Backward Compatibility 6 enabled. After vendors ship native J6 builds, disable BC6 to drop the compatibility overhead. Full rules: 5 to 6 planning.

Product overview: Joomla 6. Community write-up: What is new in Joomla 6.0.

Benefit 9: The cost of not migrating

If you stay on	What usually happens next
Joomla 3	No official security line, vendors gone, PHP upgrades break the site
Early Joomla 4 on PHP 8.0 hosts	Host forces PHP up; site fatals; emergency weekend work
Joomla 5 without a 6 plan	You miss auto-update and lifecycle planning; the next hop becomes a fire drill
Heavy abandoned extensions	Every delay makes rebuild cost higher, not lower

Waiting rarely saves money. It concentrates risk into a single emergency project.

Who benefits most (urgency map)

Situation	Main benefit	Urgency
Still on Joomla 3	Security + PHP + vendors	High
Joomla 4, host retiring PHP	Stay online	High
VirtueMart / custom components	Commerce on supported builds	High if vendors dropped your major
Government / education	Supported CMS for audits	High
Joomla 5.4, PHP 8.3+, extensions J6-ready	Joomla 6 features + lifecycle	Upgrade on staging now
Joomla 5.4, critical extensions not J6-ready	Stay secure on 5.4 while vendors catch up	Medium: schedule, do not freeze forever
Agencies with many client sites	One standard stack, fewer snowflake servers	High for white-label ops

What thinner articles leave out

Topic	Typical competitor post	This guide
Versions covered	Joomla 3 to 5, or 5 to 6 only	3 through 6 with hop order
Migration vs upgrade	Mixed or wrong	Official project language in a table
Support end dates	Vague “EOL soon”	Roadmap dates for 3, 4, 5.4, and 6
Joomla 6 auto-updates	Often missing	Called out as a finish-line benefit
BC6 plugin rules	Skipped or one line	Disable old BC, keep BC6, retire later
When waiting is OK	Rarely said	J5.4 security window through October 2027
Cleanup / core replacements	Mentioned lightly	Tied to Why Migrate and cost reduction
Staging + SEO cutover	Generic “take a backup”	Steps, Pre-Update Check, 301 map, Search Console
Commercial next step	Vague contact form	Audit in 12 hours, packages from $149

Step 1: Inventory version, PHP, and extensions

1. System → System Information: Joomla, PHP, database.
2. Export or screenshot Manage → Extensions.
3. Mark each extension: has a current build, needs rebuild, or can be replaced by core.
4. Pick only the next hop from the table above.

Step 2: Back up with a restore test

A migration benefit is worthless without rollback. Take files + database, store a copy off-server, and confirm restore once. Method: how to backup a Joomla website.

Step 3: Prove it on staging

1. Clone production to staging.
2. Run Pre-Update Check. Fix or replace blockers.
3. Complete the hop. Run Database Fix. Clear caches.
4. Click through login, forms, multilingual switchers, and checkout if you have a store.
5. Only then book the production window.

When something breaks, use the issue map: common Joomla upgrade issues.

Step 4: Cut over with SEO and support intact

• 301 map ready for any alias that must change
• Search Console checked in week one
• CDN and page cache purged
• 30 days of watch for extension edge cases

How Infyways delivers those benefits

We are not a generic “we love Joomla 5” essay. We migrate production sites:

• Free compatibility audit within 12 hours (credentials optional for the first pass)
• Fixed packages from $149 small / $299 medium / custom enterprise and stores
• 100+ JED extensions in-house, so rebuilds are normal work, not a surprise
• Staging-first cutover and 30 days of post-launch support on migration defects

Start: Joomla Upgrade Services.

Key takeaways

1. Migration benefits are security, hosting, performance, admin UX, fewer extensions, SEO resilience, accessibility, and Joomla 6 lifecycle features.
2. Use official words: 3 to 4 is a migration; 4.4 to 5 and 5.4 to 6 are upgrades.
3. Hop order is 3.10 → 4.4 → 5.4 → 6. No shortcuts.
4. Urgency follows support windows: EOL on 3/4 is immediate; 5.4 still has a security lane into late 2027.
5. Cleanup is part of the ROI: drop unused extensions and replace them with core where you can.
6. Speed and SEO appear only when template and extensions move with the CMS.
7. Waiting on EOL core increases cost. Fixed-price staging work is cheaper than an emergency rebuild.

Frequently asked questions

What are the benefits of Joomla migration?

You regain security updates, PHP 8 hosting, a modern administrator, vendor-supported extensions, better performance potential, stronger accessibility and multilingual options, and a path into Joomla 5 and 6 features such as automatic core updates.

Is Joomla 4 to 5 a migration or an upgrade?

The Joomla project treats 4.4.x to 5.x as an upgrade, not a full migration. Extension checks and staging are still required.

Is Joomla 5 to 6 a migration?

No. From 5.4.x it is an upgrade, with Behaviour – Backward Compatibility 6 involved. From Joomla 3 it is still a multi-hop migration.

Do I need to upgrade from Joomla 5 to Joomla 6 immediately?

No. Joomla 5.4 remains on a security path through 12 October 2027. Upgrade when templates and extensions are J6-ready and staging is green, not because a headline says “now or never.”

What is the Behaviour – Backward Compatibility 6 rule before upgrading?

On Joomla 5.4, disable the older Behaviour – Backward Compatibility plugin (no number in the name) only after extensions run without it. Keep Behaviour – Backward Compatibility 6 enabled for the move into Joomla 6. Disable BC6 later when every extension is native.

Does my Joomla 3 site stop working after end of life?

No. It keeps running without official security fixes while hosts and vendors move on.

Will migration improve Google rankings by itself?

No. It protects the technical baseline (uptime, SEF, modern HTML performance). Content and links still decide rankings.

Can core Joomla replace some of my extensions after migration?

Often yes. Custom fields, workflows, tags, and Smart Search cover many older third-party use cases. That is a deliberate benefit of migrating now.

How much does Joomla migration cost with Infyways?

Packages start at $149 for small sites and $299 for medium sites. Enterprise and stores are custom after the free audit.

How long does it take?

Small brochure sites can finish in days after staging is ready. Stores and custom components take longer. The audit sets the timeline.

Where do we start?

Request a Joomla upgrade audit or contact Infyways.

Disabling right click in Joomla means stopping the browser context menu on the public site so casual visitors cannot open “Save image as” or similar shortcuts in one click. On Joomla 3, 4, 5, and 6 the reliable way is a system plugin that injects the behaviour sitewide (or for images only) without editing the template. It is a soft deterrent, not real copy protection.

This guide explains what the feature does, when it helps, how to turn it on with Right Click Disable from Infyways, and what still fails if you expect it to stop theft.

What you will learn

• What right-click disable blocks, and what it never blocks
• How to disable right click in Joomla with the Right Click Disable plugin
• Why a plugin beats pasting scripts into a commercial template
• Images-only versus sitewide scope
• UX, accessibility, and SEO trade-offs before you enable it

What disabling right click does

Browsers open a context menu on right click (and on some long-press gestures). A Joomla right-click plugin cancels that default menu on the front end. Official event behaviour is documented on MDN’s contextmenu page.

Goal	Plugin helps?	Better approach
Stop casual “Save image as”	Partially	Watermarks, low-res previews, licensed galleries
Stop View Source / Inspect	No	Source is always available in the browser
Stop scrapers and bots	No	Rate limits, firewall rules, non-public assets
Reduce casual image grabs on a portfolio	Often yes	Combine with watermarking
Protect paid downloads	No	Login walls and expiring file links

Some browsers still offer ways around a cancelled menu (for example Firefox with Shift held while right-clicking). Mobile long-press menus vary. Treat the feature as a UX preference for galleries and content sites, not as security.

Plugin versus custom code

Approach	Who it fits	Risk
Right Click Disable plugin	Most site owners and agencies	Low. Toggle in the administrator. Survives template updates
Hand-edited template JavaScript	Developers who own the whole template	High. Commercial template updates wipe custom files. Easy to break the admin or forms
Random “paste this in index.php” snippets	Nobody long term	Breaks on Joomla 4+ asset changes and child-template setups

If you only need the outcome, use the plugin. Custom scripts belong in a maintained child template when you already have a developer on retainer, not as a substitute for an extension that is built, tested, and update-safe.

Step 1: Decide the scope

1. Whole site: every public page loses the context menu. Avoid this on heavy form or SaaS-style sites.
2. Images and media: visitors keep normal menus on text and links. Best default for portfolios and magazines.
3. Selected sections: only a gallery or a protected category. Use when the rest of the site should stay normal.

Pick the narrowest scope that solves the complaint you actually get (usually image saving).

Step 2: Install Right Click Disable

1. Get the package from the Joomla Extensions Directory listing or your JoomlaX download area. Live behaviour: Right Click Disable demo.
2. In the administrator open System → Install → Extensions (Joomla 4, 5, 6) or Extensions → Manage → Install (Joomla 3).
3. Upload and install the ZIP.
4. Open System → Plugins (or Extensions → Plugins on Joomla 3).
5. Search for Right Click Disable and open it.
6. Set Status to Enabled.
7. Enable Disable Right Click. Choose images-only or related options if your build offers them.
8. Save & Close.
9. Clear Joomla cache, then test the public site in a private window.

Confirm /administrator/ still has a normal context menu. The plugin is meant for the site front end. If the admin UI is affected, disable the plugin and contact support with your Joomla version.

Step 3: Configure for your content type

• Portfolio / photography: prefer image-focused protection so writers and clients can still use browser menus on text.
• Brochure marketing site: sitewide can be acceptable if you have few forms.
• Membership or course site: do not use right-click disable as the paywall. Protect files on the server.
• Multilingual: enable once. The front-end script applies per page load, not per language pack.

Step 4: Test before you call it done

1. Right-click a paragraph and an image. Confirm the scope you chose.
2. Open a contact or login form. Confirm paste and browser tools still feel usable.
3. Check Chrome, Firefox, Edge, and Safari, plus one phone long-press.
4. Clear CDN cache if the old page without the script is still served.

Why template hacks fall apart

Forum snippets that dump JavaScript into index.php or a random module chron look easy. They fail when:

• You update Helix, T4, Gantry, or another commercial template and lose the edit
• Joomla 4+ expects assets through the Web Asset Manager, not ad-hoc script tags
• The script also runs in the administrator and blocks your own workflow
• A cache or optimisation extension reorders scripts and the listener never binds

A dedicated system plugin is built for those edges. That is the product Infyways maintains on JED so agencies do not babysit template forks for a five-line behaviour.

Accessibility, UX, and SEO

• Accessibility: some people use the context menu for browser features. Prefer images-only when you can.
• UX: silent blocking beats an alert on every click.
• SEO: crawlers do not need the context menu. Enabling or disabling right click does not move rankings by itself. Content quality still does.
• Legal: watermarks and copyright notices matter more than this feature.

When to skip right-click disable

• Documentation hubs and apps full of forms
• Products that teach “right-click to download”
• Any pitch that this “secures” paid media. Use authentication instead

Need the plugin installed on a client site, wired to a gallery, or bundled in a white-label stack? Infyways can handle that under Joomla plugin development or contact us.

Key takeaways

1. Right-click disable is a soft deterrent for casual copying, not security.
2. Use Right Click Disable for a maintained, toggleable solution on Joomla 3 through 6.
3. Prefer images-only when the complaint is photo theft.
4. Avoid pasting one-off scripts into commercial templates.
5. Test the administrator and forms after enabling.
6. SEO neither rewards nor punishes this feature on its own.

Frequently asked questions

How do I disable right click in Joomla?

Install and enable the Right Click Disable system plugin, set Disable Right Click to Yes, clear cache, and test the front end.

Does disabling right click protect my images?

Only against casual use. Anyone can still download images from the page source, a screenshot, or the image URL.

Does Right Click Disable work on Joomla 5 and Joomla 6?

Yes. Use a current package from JED or JoomlaX that lists your Joomla major.

Can I disable right click on images only?

Yes, when the plugin options (or your project brief) include image-focused mode. That is usually better than a sitewide block.

Will this hurt SEO?

No. Search engines do not use the context menu. Rankings still depend on content and technical SEO.

Why not paste JavaScript into the template instead?

Because template updates overwrite custom edits, and sitewide scripts are easy to mis-scope into the administrator. A system plugin is the durable approach.

Where do I download Right Click Disable?

From the Joomla Extensions Directory or the Infyways / JoomlaX download linked from that page. Try the live demo first.

Caching in Joomla means storing rendered HTML, component views, and module output so the next guest request skips most database and PHP work. In Joomla 4, 5, and 6 you control three layers: Global Configuration System Cache (Off, Conservative, or Progressive), the System – Page Cache plugin for whole guest pages, and per-module Advanced caching. Handlers decide where copies live (File, APCu, Redis, or Memcached).

Official docs explain the switches. Deep technical posts explain com_cache internals. LiteSpeed magazine pieces cover one host stack. This guide is the operator map: which mode to pick by site type, what breaks Progressive and Page Cache, Redis and Memcached setup gotchas, how to clear and purge safely, and when caching alone cannot fix a slow EOL site. Infyways upgrades and tunes production Joomla from $149 with a free audit within 12 hours.

What you will learn

• The three cache layers and the order they win
• Conservative vs Progressive vs Page Cache with a decision table
• File, APCu, Redis, and Memcached: when each handler is right
• Exclusions for carts, forms, login, and personalised modules
• Clear vs purge, CLI clean, and stale-content fixes
• How LiteSpeed (or another edge cache) should sit beside Joomla cache
• A staging checklist and when to call Infyways

How Joomla caching is layered

Think of three increasing levels of aggressiveness. The first layer that can answer usually wins.

Layer	Where you set it	What it caches	Who it serves
System Cache (Conservative or Progressive)	System → Global Configuration → System → Cache Settings	Component views and modules (rules differ)	Mostly guests for core content views; access levels are part of the cache id
Module Advanced tab	Each module → Advanced	That module only (Use global or No caching)	Respects Conservative; ignored for guests under Progressive
System – Page Cache plugin	System → Manage → Plugins	Whole HTML page by URL	Guests only. Fastest built-in option

Primary sources: Joomla Cache user guide, caching views and modules (manual), and the LiteSpeed Cache and Redis magazine article.

Important: turning System Cache to Conservative does not by itself cache the full page. Full-page guest caching needs the System – Page Cache plugin enabled separately.

Conservative vs Progressive vs Off

Mode	What happens	Use when	Avoid when
Off	No view or module cache from Global Configuration	Debugging, template work, chasing a stale bug	Busy production brochure sites
Conservative (recommended default)	Caches eligible component views and modules that allow caching. Module “No caching” is respected	Almost every site: membership, forms, stores, multilingual	Never the wrong starting point
Progressive	For logged-off users, all modules are cached. Module “No caching” has no effect. Module output often shares a com_modules group file	Static brochure sites after careful staging tests	Menus that change by page, random modules, login-aware chrome, anything that must differ per Itemid

Myth to kill: Progressive is not “caching for logged-in users.” Official docs are explicit that core view cachability rules do not flip that way. Progressive is more aggressive module caching for guests.

Classic Progressive failure: the wrong module appears on the wrong page because one cached module blob was reused across Itemids. If you see that, switch back to Conservative immediately.

System – Page Cache plugin

This is the fastest built-in path. On a hit, Joomla can return stored HTML before most of the site boots. It only serves guests. Logged-in visitors always get a fresh build so names, carts, and private menus stay private.

• Enable: System → Manage → Plugins → System – Page Cache
• It uses the same handler and Cache Time as Global Configuration
• Exclude menu items and URL patterns for anything dynamic
• Use Browser Caching sends browser cache headers. Leave it off unless you understand that visitors can keep a page after you clear server cache

Always exclude (or never page-cache): contact and other forms, search results, login and registration, carts and checkout, tokenised or one-time pages, and any URL that must reflect the current session. Editing an article does not always clear every page that embeds it. Clear the page cache group after content launches that must be instant.

Cache handlers: File, APCu, Redis, Memcached

Handler	Stores in	Best for	Watch outs
File	cache/ and administrator/cache/	Default on shared hosting and most single servers	Many tiny files on slow disks; purge expired regularly
APCu	PHP shared memory	Single server speed win for small items	Not shared across nodes; cleared on PHP restart
Redis	Redis server or Unix socket	Clusters, high traffic, LiteSpeed object cache stacks	Wrong host or socket causes 500s; change handler before killing Redis
Memcached	Memcached server or socket	Shared cache across web nodes	Often labelled experimental in host UIs; test persistence settings

Modern Joomla no longer relies on old handlers such as XCache or eAccelerator. If a host guide still lists them, ignore that part.

Redis tip from real support threads: if you disable System Cache while Redis is already unreachable, you can still get connection errors until you switch the handler back to File (or a working Redis), save, then turn caching off. Flush cache after handler changes.

Global Configuration fields that matter

Setting	Meaning	Practical default
System Cache	Off / Conservative / Progressive	Conservative
Cache Handler	Where items are stored	File, then Redis on capable hosts
Platform Specific Caching	Adds device type into the cache id	No, unless desktop and mobile HTML truly differ on the same URL
Cache Time	Lifetime in minutes (default 15)	15 for mixed sites; lower for news; higher for static brochures
Path to Cache Folder	Custom file path	Leave blank unless you know why

Module Cache Time is in seconds. Global Cache Time is in minutes. Mixing those units is a common misconfiguration.

Per-module caching

• Open the module → Advanced → Caching: Use global or No caching
• Set No caching for login status, live counters, random quotes, carts, and anything personal
• Under Progressive for guests, No caching is ignored. That is why Progressive breaks dynamic chrome
• Some modules declare a cache mode in code (static, itemid, and similar). A badly coded static mode can freeze wrong content even on Conservative

Breadcrumbs is a safe module to use when testing Conservative caching on staging.

Decision guide by site type

Site type	System Cache	Page Cache plugin	Handler	Notes
Brochure / marketing	Conservative (try Progressive only after tests)	On, with form pages excluded	File or Redis	Biggest easy win
Membership / ACL content	Conservative	On for public pages only; exclude member areas	File or Redis	Access levels belong in cache ids; still exclude personal dashboards
Multilingual	Conservative	On	File or Redis	Language is part of identity; clear cache after language or SEF changes
VirtueMart / Hikashop / carts	Conservative	On only for static CMS pages; exclude cart, checkout, account	File or Redis	Page Cache on cart URLs causes classic “empty cart” bugs
Heavy community / logged-in traffic	Conservative	Limited; focus on guest landing pages	Redis preferred on busy hosts	Page Cache helps guests only
LiteSpeed host	Conservative	Often rely on LiteSpeed full-page; keep Joomla Conservative	Redis as object cache when offered	Magazine guidance: Conservative with LiteSpeed + Redis reduces conflicts

LiteSpeed, CDN, and Redis together

Edge page cache (LiteSpeed Cache for Joomla, Cloudflare, or a reverse proxy) sits in front of Joomla. Redis or Memcached as the Joomla cache handler speeds object and view cache behind that. Do not stack three aggressive full-page systems without a purge story.

• Prefer Conservative when an external full-page cache is already on
• Let the edge plugin purge on article save when it supports automatic purge
• Use Redis for shared or high-traffic object cache, not as a substitute for excluding dynamic URLs
• ESI and logged-in edge features vary by LiteSpeed edition. Test on staging

Clear Cache vs Clear Expired Cache

Action	Path	Removes	Use when
Clear Cache	System → Maintenance → Clear Cache	Selected groups or everything	After template, override, or extension updates; stale homepage; debugging
Clear Expired Cache	System → Maintenance → Clear Expired Cache	Only past-lifetime items	Routine housekeeping so File handler folders do not fill forever
CLI clean	php cli/joomla.php cache:clean	All (or expired with the expired argument)	Deploy scripts and cron

With the File handler you can also empty cache/ via SFTP if the admin is down. That is equivalent to a full clear. Joomla cache is not a database table.

Step 1: Set a safe baseline on staging

1. Clone production to staging.
2. System → Global Configuration → System → Cache Settings: System Cache = ON – Conservative caching, Handler = File, Platform Specific Caching = No, Cache Time = 15.
3. Save. Browse as a guest. Confirm pages load and dynamic modules still update.
4. Only then introduce Redis or Progressive on a second staging pass.

Step 2: Enable Page Cache with exclusions

1. Enable System – Page Cache.
2. Exclude contact, search, login, cart, checkout, and account menu items.
3. Leave Use Browser Caching off for the first week.
4. As a guest, load a public article twice. Confirm a cache/page entry appears when using the File handler.
5. Edit that article, clear the page group, and confirm the front end updates.

Step 3: Tune modules and handlers

1. Set personal or random modules to No caching (Conservative only).
2. If the host offers Redis, set handler to Redis, enter socket or host, port 0 for Unix sockets when required, save, then Clear Cache.
3. Retest guest and logged-in paths, forms, and checkout.
4. Optional: try Progressive only on a static brochure clone. Revert at the first wrong-module symptom.

Step 4: Production cutover and monitoring

• Apply the proven staging settings during a low-traffic window
• Clear Cache after deploy
• Watch Core Web Vitals and server CPU for a week
• Schedule Clear Expired Cache or CLI purge if you stay on File
• Document exclusions so the next editor does not enable Page Cache on checkout

Troubleshooting stale or broken cache

Symptom	Likely cause	Fix
Old article text on guests	Page Cache still holding URL	Clear page group; shorten Cache Time if launches are frequent
Wrong module on a page	Progressive guest module cache	Switch to Conservative; clear com_modules
Empty cart or stuck form	Page Cache on dynamic URLs	Exclude those menu items and URLs; clear page cache
Redis connection 500 after “turning cache off”	Handler still Redis while server is down	Set handler to File while Redis is up, save, then disable caching
Logged-in users see no speed gain from Page Cache	By design	Rely on Conservative + Redis; Page Cache is guest-only
Mobile gets desktop chrome	Platform Specific Caching off while serving different HTML	Enable only if HTML truly differs; prefer one responsive template

Related reading: Joomla upgrade issues and fix Joomla update errors when cache problems appear after a version hop.

When caching is not enough

Cache multiplies a healthy stack. It does not replace an unsupported Joomla 3 site, an abandoned template full of blocking scripts, or PHP that the host is about to retire. If Time to First Byte stays poor after Conservative + Page Cache on staging, fix the CMS and template path first.

Infyways runs that path as a service:

• Free compatibility and performance audit within 12 hours
• Fixed packages from $149 small / $299 medium / custom for stores and clusters
• 100+ JED extensions in-house when a cache-hostile extension needs a rebuild
• Staging-first cutover and 30 days of post-launch support on defects we introduce

Start: Joomla Upgrade Services.

What thinner articles leave out

Topic	Typical post	This guide
Versions	Joomla 3 or 4 screenshots only	Joomla 4 / 5 / 6 settings that still apply
Conservative vs Progressive	One paragraph or a myth about logged-in users	Decision table + Progressive failure mode
Page Cache	“Turn the plugin on”	Guest-only rule, exclusions, browser caching warning
Handlers	File only, or outdated APC lists	File, APCu, Redis, Memcached with cluster notes
Edge cache	Missing or vendor-only	LiteSpeed + Redis layering with Conservative default
Operations	Clear Cache button	Clear vs purge, CLI, deploy hygiene
Site types	Generic speed claims	Brochure, ACL, multilingual, cart matrix
Next step	Affiliate plugin link	Staging steps + Infyways audit from $149

Key takeaways

1. Start with Conservative caching. Add System – Page Cache for guests with strict exclusions.
2. Progressive is optional and dangerous for dynamic modules. It is not “logged-in caching.”
3. Full-page cache is a separate plugin. Global System Cache alone is not full-page cache.
4. File is fine for most sites. Redis or Memcached help clusters and high traffic.
5. Global Cache Time is minutes. Module Cache Time is seconds.
6. Clear the page group after launches that must be instant. Purge expired on File hosts.
7. Edge cache plus Joomla Conservative plus Redis is a common modern stack. Test purge behaviour.
8. If the site is EOL or template-bound, upgrade first. Cache cannot patch an unsupported core.

Frequently asked questions

What is caching in Joomla?

It is storing views, modules, or whole guest pages so repeat requests skip most PHP and database work. You control it with System Cache, module Advanced settings, and the System – Page Cache plugin.

Should I use Conservative or Progressive caching?

Use Conservative for almost every site. Use Progressive only on static brochure sites after staging tests, because guest modules are force-cached and “No caching” is ignored.

Does System Cache cache the whole page?

No. Conservative or Progressive cache views and modules. Whole-page guest caching needs the System – Page Cache plugin.

Does Page Cache work for logged-in users?

No. The plugin serves guests only so personalised HTML is never shared between users.

Is Progressive caching for logged-in users?

No. That is a common myth. Progressive changes how guest modules are cached. Core view rules for logged-in users stay separate.

What cache handler should I choose?

File for standard shared hosting. APCu for a fast single server. Redis or Memcached when you need shared memory cache across nodes or your host recommends it with LiteSpeed.

Why is my cart empty after enabling cache?

Page Cache is almost certainly covering cart or checkout URLs. Exclude those menu items and clear the page cache group.

How do I clear Joomla cache from the command line?

Run php cli/joomla.php cache:clean from the site root. Use the expired variant for purge-only cleanup in cron.

Will caching fix a slow Joomla 3 site by itself?

No. It can help guests, but unsupported core, old PHP, and abandoned templates still need an upgrade path. See benefits of Joomla migration.

How much does Infyways charge to tune or upgrade a slow Joomla site?

Packages start at $149 for small sites and $299 for medium sites. Stores and multi-node setups are custom after the free audit.

Where do we start?

Request a Joomla upgrade audit or contact Infyways.

Disabling cookies for visitors on a Joomla website does not mean deleting the core session cookie. That cookie is strictly necessary for forms, CSRF tokens, and login safety. What site owners usually need is to stop non-essential cookies (analytics, marketing, embeds, preference trackers) until the visitor gives informed consent under GDPR, ePrivacy, and similar laws. On Joomla 4, 5, and 6 the practical path is a consent module such as Easy Cookie Alert by Infyways, not a core hack that turns sessions off.

Thin “7 steps to disable cookies” posts still tell people to kill Global Configuration settings that do not exist, or to patch index.php so guests have no session. That breaks forms and security. This guide is the operator correction: cookie categories, what Joomla core actually sets, how to gate third-party tags, how to configure Easy Cookie Alert, and how to verify the result without inventing a free DIY banner that fights your template.

What you will learn

• Necessary vs optional cookies on a real Joomla site
• Why you should not disable the guest session cookie
• How consent, Reject all, and prior blocking differ from an information-only bar
• Step-by-step setup with Easy Cookie Alert on Joomla 4, 5, and 6
• Google Consent Mode v2, embed freeze, and consent proof
• How to test in DevTools and what still fails if tags stay in the template

What Joomla sets by default

Core Joomla is not an ad network. The Joomla Project’s own cookie policy treats the random session cookie as strictly necessary. It ties the browser to a server-side session so CSRF tokens and forms work. Official core does not ship Google Analytics or marketing pixels. Most compliance risk comes from extensions, template scripts, GTM, and embeds you add later.

Cookie / data	Typical source	Consent needed?	What to do
Session cookie (random name)	Joomla core	No (strictly necessary)	Keep it. Document it in your privacy policy
Session metadata for guests	Global Configuration → Session	No for the cookie itself	You can reduce guest metadata tracking for performance; the session still exists
_ga, _gid, marketing IDs	Analytics / ads / GTM	Yes before set	Load only after Analytics or Marketing consent
Social / chat widgets	Third-party scripts	Usually yes	Gate with Functional or a custom category
YouTube, Maps, Vimeo embeds	Articles and modules	Often yes (third-party cookies)	Freeze embeds until the required category is allowed

Primary references: Joomla cookie policy, the long-running discussion that core does not ship a full cookie manager, and EU ePrivacy rules that require consent before non-essential storage on the device.

Do not disable the guest session cookie

Older forum advice suggests editing index.php to start the site application with session => false for guests, or hacking session table inserts. That belongs in the museum next to Joomla 1.5 tips.

• Sessions power form tokens. No session means weaker CSRF protection and broken logins.
• Bots and humans still hit login URLs even if you hide the menu item.
• Security vendors (including Akeeba guidance historically) treat guest session cookies as required for safe forms.
• “Disable cookies” in a privacy sense means do not set tracking cookies, not “run a CMS without sessions.”

If your goal is fewer database writes from guests, use Session settings such as limiting session metadata for non-registered users where your Joomla version supports it. That is a performance tweak. It is not a consent solution and it does not remove the cookie.

What “disable cookies for visitors” should mean

Goal	Wrong approach	Correct approach
Stop tracking until opt-in	Information-only bar that never blocks scripts	Prior blocking + Reject all + category prefs
GDPR / ePrivacy readiness	Kill Joomla session	Keep necessary cookies; gate optional ones
CCPA / CPRA “Do Not Sell”	EU-only banner copy	Optional Do Not Sell link and prefs for US traffic
GTM / GA4	Fire tags in the template head always	Consent Mode v2 default denied, then update on choice
Embeds	Paste iframes freely	Freeze until Analytics / Marketing / Functional is allowed

Why lead with Easy Cookie Alert

Infyways builds Easy Cookie Alert for Joomla 4, 5, and 6. It is a module (vanilla JS, no jQuery) with Accept all, Reject all, Cookie settings, layouts (Bar, Floating, Modal, Overlay), category script slots, Google Consent Mode v2, embed blocking, optional consent proof logging, and CCPA Do Not Sell support. Full setup notes: Easy Cookie Alert documentation.

Vendor CMP suites and generic “paste this banner” snippets can work, but on Joomla they often fight template assets or leave tags in index.php. A native module that owns the script slots keeps the consent decision and the tags in one place.

Step 1: Inventory cookies and scripts

1. Open the site as a guest in a private window.
2. DevTools → Application → Cookies. Note first-party and third-party names.
3. Network tab: find analytics, ads, chat, and social hosts.
4. List every extension or template feature that injects those tags.
5. Write a short privacy policy section that names necessary cookies and optional categories.

If the inventory is mostly session cookies and nothing else, you may only need a clear policy statement. The moment you add GA4, Meta Pixel, Hotjar, or third-party embeds, you need consent gating.

Step 2: Install and publish Easy Cookie Alert

1. Download the package from the JED listing and unzip it.
2. System → Install → Extensions → upload mod_cookiealert_…zip.
3. Content → Site Modules → Easy Cookie Alert.
4. Status: Published. Hide Title.
5. Assign a module position (debug is fine; the banner portals to the document body).
6. Assign menu items for every public page that needs consent.
7. System → Clear Cache.

Step 3: Configure content, layout, and categories

• Content: message, privacy policy link, Accept / Reject / Settings labels, optional CCPA Do Not Sell copy
• Layout: start with Bar Bottom; use Overlay or Modal with Force consent when choice must happen first
• Categories: Necessary stays on; enable Analytics, Marketing, Functional, and custom categories you need
• Consent days: how long a choice is remembered
• Consent version: bump when the policy changes so returning visitors are asked again

Reject all must be as easy as Accept all. A banner that only offers OK is not enough for modern EU expectations.

Step 4: Move tags into category scripts

1. Remove GA / ads / chat snippets from the template head and from “custom code” plugins that always fire.
2. Paste each tag into the matching category script slot in Easy Cookie Alert.
3. If you use Google Tag Manager, enable Consent Mode v2 so defaults are denied in the head before tags run, then update after the visitor chooses.
4. Turn on embed blocking if articles include YouTube, Vimeo, or Maps.
5. Optional: enable consent proof logging when you need anonymised receipts.

If tags remain hard-coded in the template, the banner cannot undo them. Consent UI without prior blocking is theatre.

Step 5: Verify as a guest

1. Private window, no prior consent cookie.
2. Confirm Reject all leaves analytics and marketing cookies unset.
3. Confirm Accept all (or category save) loads only what was allowed.
4. Submit a contact form and confirm it still works (session cookie present).
5. Reopen Cookie settings from the floating control and change a choice.
6. Bump consent version on staging and confirm the banner returns after a policy change.

Multilingual, shops, and logged-in users

Site type	Extra care
Multilingual	Separate Easy Cookie Alert modules per language filter, with translated copy and the same category ids
VirtueMart / Hikashop	Keep checkout and cart cookies in the necessary / functional story; never page-cache checkout; gate only marketing tags
Membership	Logged-in users still need session cookies; consent still applies to marketing tags on public pages
Heavy GTM	Consent Mode v2 first; do not duplicate the same tags in both GTM and module slots

What thinner articles get wrong

Claim	Reality
“Turn off cookies in Global Configuration”	There is no master switch that removes the session cookie while keeping a safe dynamic site
“Disable sessions for guests in index.php”	Breaks CSRF and forms; outdated advice
“A notice bar is enough”	Non-essential cookies need prior consent and a real Reject path
“Joomla core tracks users like an ad platform”	Core session is necessary; tracking usually comes from what you installed
“HTTP Headers plugin manages cookies”	System – HTTP Headers is for security headers (CSP, HSTS), not consent UI

When you also need an upgrade

Consent modules expect a current Joomla 4 / 5 / 6 stack and PHP 8. If the site is still on Joomla 3 with abandoned analytics plugins, fix the platform first. Infyways runs migrations from $149 with a free audit within 12 hours: Joomla Upgrade Services.

Key takeaways

1. Do not disable the Joomla session cookie for visitors. It is strictly necessary.
2. “Disable cookies for visitors” means block non-essential cookies until consent.
3. Use Accept all, Reject all, and category preferences with prior blocking.
4. Move analytics and marketing tags out of the template and into consent-controlled slots.
5. Easy Cookie Alert covers Joomla 4, 5, and 6 with Consent Mode v2, embed freeze, and optional proof logs.
6. Verify in a private window. A banner that never changes the Network panel is not compliance.

Frequently asked questions

Can I fully disable cookies for Joomla visitors?

No, not if you want a safe dynamic site. Keep the necessary session cookie. Disable or delay optional tracking cookies until consent.

Does Joomla core require a cookie consent banner by itself?

Often no, if you only use the session cookie and document it. Yes as soon as you add analytics, ads, or many third-party embeds.

Is an information-only cookie bar enough for GDPR?

No. Visitors need a real choice, including Reject all, and non-essential scripts must not run first.

Will Reject all break my contact form?

It should not. Forms rely on the necessary session cookie, which stays available.

What is Google Consent Mode v2 in this context?

It tells Google tags to default to denied until the consent module updates the choice, so tags do not behave as if consent already existed.

Where do I get Easy Cookie Alert?

From the Joomla Extensions Directory listing. Setup details are in the JoomlaX documentation.

Does System – HTTP Headers disable cookies?

No. That plugin manages security headers such as CSP and HSTS. It is complementary hardening, not a consent manager.

How do I re-ask visitors after a policy change?

Increase the consent version in the module so stored choices are invalidated and the banner shows again.

Where do we start if the site is old and full of abandoned trackers?

Request a Joomla upgrade audit, then install a current consent module on the upgraded stack.

Adding custom JavaScript to Joomla means loading your own .js files, CDN scripts, or trusted inline snippets on the public site (and sometimes the administrator) without breaking the template on every update. On Joomla 4, 5, and 6 the modern stack is the Web Asset Manager. For site owners who do not want to edit index.php, the practical path is a system plugin such as Easy Includes by Infyways, which registers scripts the Joomla way.

Old guides still tell people to paste raw <script> tags into Cassiopeia, hard-code CDN URLs in the head, or call deprecated Document::addScript helpers. Those patterns fight updates, duplicate libraries, and often load tracking before consent. This guide is the operator map: which method to pick, how Easy Includes works, how templates and overrides should use assets, and what to avoid.

What you will learn

• When to use Easy Includes vs a child template vs a one-off override
• How Web Asset Manager replaces old addScript habits on Joomla 4, 5, and 6
• Defer, async, modules, SRI, and cache busting without guesswork
• Where tracking scripts belong (hint: after cookie consent)
• How to test load order and clear caches safely

Pick the right place for your JavaScript

You need to…	Best place	Why
Add sitewide JS/CSS without touching the template	Easy Includes	Admin UI, Web Asset Manager, exclusions, survives template updates
Ship behaviour that belongs to one template design	Child template + joomla.asset.json	Assets travel with the theme; parent can still update
Fix one component view only	Template override tmpl + useScript	Loads only where needed
Build a reusable feature	Module, plugin, or component media folder	Proper extension packaging
Fire analytics / ads tags	Consent module script slots	See disable cookies for Joomla visitors

Official references: Web Asset Manager and Adding JavaScript in the Joomla manual. Product page: Easy Includes for Joomla 4, 5, and 6.

Why not paste scripts into the template

• Template updates overwrite index.php and media files you edited in the parent
• Hard-coded tags skip dependency ordering and duplicate jQuery or core scripts
• Document::addScript / addStyleSheet patterns are deprecated in favour of Web Asset Manager (removal targeted for Joomla 6 era tooling)
• Tracking pasted in the head often runs before visitors can Reject non-essential cookies
• Article editors pasting <script> into HTML is fragile, hard to audit, and often stripped

Recommended path: Easy Includes

Easy Includes 2.0 is Infyways’ system plugin for Joomla 4, 5, and 6. It keeps custom CSS and JavaScript in plugin settings: site-relative files, CDN URLs, or trusted inline blocks. Each row can be enabled or disabled. Scripts register through Web Asset Manager with Normal, Defer, or Async loading, plus ES module, nomodule, crossorigin, and SRI options. Cache busting modes (Off, Auto, Aggressive) and exclusions for user groups, components, and URL fragments keep checkout and login clean.

Step 1: Install and enable Easy Includes

1. Download from the JED listing or your JoomlaX account.
2. System → Install → Extensions → upload the package.
3. System → Manage → Plugins → find System – Easy Includes.
4. Enable the plugin. Leave administrator loading off unless you intentionally need admin assets.
5. System → Clear Cache.

Step 2: Add a JavaScript file or CDN URL

1. Upload your file under a stable path (for example media/templates/site/cassiopeia/js/site.js or a custom media folder you control).
2. Open Easy Includes and add a JavaScript file row.
3. Path: site-relative such as media/templates/site/cassiopeia/js/site.js, or a full https:// CDN URL. Do not use .. traversal.
4. Choose Normal, Defer, or Async. Prefer Defer for non-critical UI behaviour.
5. Add SRI integrity and crossorigin when the file comes from a CDN you control the hash for.
6. Enable the row, save, and clear cache.

Step 3: Inline JavaScript only when you must

Inline JS is trusted administrator input. Use it for tiny fixes, not for large libraries. Prefer a file on disk so version control and reviews stay sane. Only accounts that should edit PHP should edit inline script rows.

• Keep snippets short and named in a comment at the top
• Do not paste secrets, API private keys, or unreviewed third-party blobs
• Turn Debug logging on while testing exclusions, then off on production

Step 4: Exclude pages that must stay clean

Exclude	Example	Why
URL fragment	/checkout, /cart	Avoid JS that breaks payment or cart flows
Component	com_users	Keep login and reset pages minimal
User group	Special / admin groups on the front end	Stop experimental scripts for staff while guests still see them, or the reverse

Step 5: Verify in the browser

1. Open the front end as a guest. View source or DevTools → Network → JS.
2. Confirm your file loads once, with the expected defer/async behaviour.
3. Confirm excluded URLs do not load it.
4. After editing a local file, use Auto cache busting once, then return to Off on stable production if you prefer clean URLs.
5. If you use page cache or a CDN, purge those layers too. Related: caching in Joomla.

Template and Web Asset Manager path (developers)

When the script is part of the theme, use a child template so parent updates do not wipe your work.

• Place the file under the template media JS folder
• Declare it in joomla.asset.json with a clear name, type script, uri, and dependencies (often core)
• In the template PHP, call the Web Asset Manager useScript for that asset name
• Ensure the template still outputs scripts via the normal Joomla script include

For a single view, call useScript from that override only. For a packaged extension, ship media + joomla.asset.json and register the registry file from the plugin or module as the manual describes. Prefer the official manual examples over copying ancient addScript snippets from Stack Overflow.

Custom JavaScript vs cookie consent

Marketing and analytics tags are still “custom JavaScript,” but they are not a design asset. Put them in a consent-aware slot so Reject all actually prevents them from running. Easy Includes is for UI and site behaviour you control. Easy Cookie Alert (or your CMP) owns GA, ads, and similar tags. Mixing those concerns is how sites fail privacy checks while the banner looks fine.

What thinner articles leave out

Topic	Typical post	This guide
Joomla versions	Joomla 3 template hacks	Joomla 4 / 5 / 6 Web Asset Manager
No-edit path	Missing or random free module	Easy Includes with WAM, defer/async, SRI, exclusions
Load strategy	“Paste in head”	Normal / Defer / Async and when to use each
Updates	Edit parent template	Plugin or child template so updates survive
Tracking	GA snippet in index.php	Consent-first placement
Verification	Hope it works	Network checks, exclusions, cache purge

When the platform is the real problem

If the site is stuck on Joomla 3 with a club template full of inline scripts, adding more JS will not fix Core Web Vitals or security. Upgrade first, then add assets cleanly. Infyways migrations start at $149 with a free audit within 12 hours: Joomla Upgrade Services.

Key takeaways

1. Use Web Asset Manager concepts on Joomla 4, 5, and 6. Stop relying on deprecated addScript habits.
2. For sitewide custom JS without template edits, use Easy Includes.
3. Prefer files on disk over large inline blocks.
4. Defer non-critical scripts. Use SRI for CDN libraries.
5. Exclude checkout, login, and other sensitive paths when scripts are experimental.
6. Put analytics behind consent, not in the template head.
7. Clear Joomla cache (and CDN/page cache) after every change.

Frequently asked questions

How do I add custom JavaScript to Joomla without editing the template?

Install and enable Easy Includes, add a file or CDN row, choose Defer when appropriate, save, and clear cache.

What is the Web Asset Manager?

It is Joomla’s system for registering and loading CSS/JS with names, dependencies, and attributes so extensions do not step on each other.

Should I still use Document::addScript?

No for new work. Register and use assets through Web Asset Manager as the current manuals describe.

Can I add JavaScript to a single Joomla article?

Avoid pasting scripts into article HTML. Prefer a module assignment, an override for that view, or a consent/plugin slot that targets the right pages.

What is the difference between Defer and Async?

Defer runs after HTML parsing and keeps order relative to other deferred scripts. Async runs when ready and may reorder. Prefer Defer for most site UI scripts.

Where should Google Analytics go?

In a consent-controlled script slot, not as always-on custom JS. See the Joomla cookies for visitors guide.

Will Easy Includes work on Joomla 6?

Yes. Easy Includes 2.0 supports Joomla 4, 5, and 6 with Web Asset Manager registration.

How do I stop my script on checkout pages?

Use Easy Includes exclusions for the checkout URL fragment or the shop component name, then verify in Network.

Where do we start if the template is full of hard-coded scripts?

Request a Joomla upgrade audit, move assets into Easy Includes or a child template, and remove the hard-coded tags.

A Joomla browser compatibility issue is a page that works in one current browser and fails in another. On Joomla 4, 5, and 6 the supported browsers are current Chrome, Edge, Firefox, and Safari. Internet Explorer is not supported. A layout that breaks at the same width in every browser is a responsive CSS problem, not a browser bug.

Most tickets that get called “compatibility” are a cached stylesheet, a browser extension, a template that still targets Joomla 3, or a cookie scoped to the wrong host. Start with the console and a private window. Do not add HTML5 Shiv or Respond.js.

What you will learn

• Which browsers Joomla 3, 4, 5, and 6 actually support
• How to tell a browser bug from a responsive bug, a cache, or an extension
• Why Internet Explorer cannot be patched back into Joomla 5 or 6
• The Safari login failure that is really the site URL
• When the template is the product you need to replace

Supported browsers

Joomla	Browsers to test	Do not spend time on
3.10	Current Chrome, Edge, Firefox, Safari. The old project list still names Internet Explorer, and that list is not a 2026 requirement	IE8, IE9, IE10. Joomla 3 itself is end of life
4	Current Chrome, Edge, Firefox, Safari. The admin and Cassiopeia use Bootstrap 5	Internet Explorer 11. Bootstrap 5 does not support it
5 and 6	The same four, current versions. Core JavaScript is modern (ES2018). Joomla 5 stopped shipping the old IE11 script builds	IE11, and any plan to load es5.js shims for it

Bootstrap’s own rule, which Joomla’s UI follows, is the latest stable browsers, not Internet Explorer: Bootstrap browsers and devices. The drop of the IE11 bundles is recorded in the Joomla 4.4 to 5 removal list. The page Joomla Browser Support is a Joomla 3 document. Do not use it as the matrix for Joomla 5 or 6.

Name the failure before you edit CSS

What you see	In which browsers	What it usually is
Layout wrong only on a phone width	All of them	Responsive CSS or a missing viewport. Not a browser bug
IE11 admin is unstyled or dead	IE only	Unsupported. Move the user to Edge
One browser shows yesterday’s CSS	One	Cache, or a service worker
Styles missing everywhere	All	CSS 404, mixed content, or .htaccess. See 500 on mod_rewrite
Login works in Chrome, drops in Safari	Safari	Site URL, www versus apex, or HTTP versus HTTPS. Cookie scope, not WebKit
A slider or menu dies in one browser	One	An extension script. Read the console
Only the administrator is broken	One or all	Atum, or an admin module. The site template is innocent
Blank page, no layout talk	All	A PHP fatal, not CSS. Read the host log

Step 1: Write down the browser, the version, and the URL

1. Note the browser name and a major version (Chrome 131, Safari 18, Firefox ESR). “Doesn’t work on Mac” is not a report.
2. Note the exact URL. Site homepage, one article, and /administrator/ are three different products.
3. If the browser is Internet Explorer, stop. On Joomla 4, 5, or 6 that is expected. Send the user to current Edge, Chrome, Firefox, or Safari.
4. If every current browser fails the same way, you are not debugging compatibility. Fix the error, the missing file, or the template, then come back.

Step 2: Rule out cache and extensions

1. Open a private window with extensions disabled. Retest the same URL.
2. If the private window is fine, the cause is a cached file or an extension (ad blockers often block scripts and fonts). Clear that browser’s cache for the site. Then clear Joomla’s cache (System → Maintenance → Clear Cache) and any CDN.
3. If the private window is still broken, the site is serving the failure. Continue.

A hard refresh in one browser does not clear another browser’s cache. That is why “it works on my machine” survives for weeks.

Step 3: Read the console, not the homepage

1. Open developer tools in the broken browser. Console and Network.
2. Reload. Copy the first red error. The file name is the extension or the template.
3. On Network, filter CSS and JS. A red row is a 404 or a blocked mixed-content request. An unstyled page with a 404 on template.css is a path problem, not a rendering engine.
4. Mixed content (HTTPS page calling http:// assets) is blocked hardest by Chrome and modern Safari. Fix the URLs in the template. Do not tell users to allow insecure content.

Step 4: See if the template is the only broken piece

1. On a staging copy, set the site template to Cassiopeia (System → Site Templates).
2. Retest the broken browser.
3. If Cassiopeia is fine, your template or one of its overrides is the bug. Update it to a build for this Joomla major, or replace it. Joomla 3 templates (Bootstrap 2, IE conditional comments, MooTools menus) will not become compatible by adding a script.
4. If Cassiopeia fails too, the template is not the cause. Look at modules on that page.

Confirm the template prints a viewport tag. Cassiopeia does. A custom index.php that omits it makes phones look “broken in Safari” while the desktop looks fine:

<meta name="viewport" content="width=device-width, initial-scale=1">

Step 5: Disable the extension named in the console

The first console line usually names a file under /media/, /templates/, /modules/, or /plugins/. Disable that extension on staging and reload.

• A menu or slider that calls MooTools or an ancient jQuery will fail in current browsers even when the rest of the page is fine. Background: remove MooTools from Joomla.
• Do not “fix” it by loading jQuery again. Joomla 4, 5, and 6 core UI does not need jQuery. A second copy fights over $ and creates a new one-browser failure.
• HTML5 Shiv and Respond.js were IE8 hacks. They do nothing useful on Joomla 4+ and they add a script current browsers do not need. Remove them if a ten-year-old tutorial put them in the template.

Step 6: Fix Safari login separately from CSS

If the page looks right in Safari but login or the administrator session dies, stop comparing stylesheets.

1. Global Configuration → Site → Site URL, and the live host, must be the same scheme and host. https://example.com and https://www.example.com are different cookie hosts. Chrome is more forgiving of the redirect. Safari drops the session.
2. Force one host in the server redirect, then clear cookies and test again.
3. If the Joomla page is inside an iframe on another site, Safari blocks that cookie. Do not embed the login.

Step 7: Retest the four current browsers

• Chrome or Edge (same engine, still check Edge once if the client uses it)
• Firefox, including ESR if the client is a locked office build
• Safari on a Mac or an iPhone. Desktop Chrome does not stand in for iOS Safari
• The administrator, not only the homepage

A paid cross-browser lab is optional after the console is clean. It is not the first step, and it will not make Internet Explorer run Joomla 6.

Do not sniff the browser

Joomla’s old browser class, and any template switch based on the user-agent string, will mislabel current Edge, Brave, and in-app webviews. Serve one template. Fix the CSS. User-agent hacks are how a site ends up with a broken stylesheet that only one browser ever loads, which then looks exactly like a compatibility bug.

When the honest fix is an upgrade

If the site is Joomla 3 and the goal is “works in current Safari and Chrome”, Protostar and a pile of IE scripts are the wrong project. Move to a Joomla 5 or 6 template built on Bootstrap 5, on staging, then retest. Path notes: Joomla upgrade issues. Infyways runs those jumps from $149, with a compatibility audit within 12 hours: Joomla Upgrade Services.

Key takeaways

1. Joomla 4, 5, and 6 support current Chrome, Edge, Firefox, and Safari. Not Internet Explorer.
2. Same failure in every browser is not a browser bug.
3. Private window first, then the console, then Cassiopeia, then the extension named in the error.
4. Safari login failures are usually the site URL and cookies.
5. Do not add HTML5 Shiv, Respond.js, or a second jQuery.
6. A Joomla 3 template will not become compatible by hiding the IE comments. Upgrade the template with the CMS.

Frequently asked questions

Which browsers does Joomla support?

For Joomla 4, 5, and 6, test current Chrome, Edge, Firefox, and Safari. Internet Explorer is not supported. The old Joomla 3 browser list is not the matrix for current releases.

Why does the site look fine in Chrome and broken in Safari?

Check a private window, then the console. If only login fails, compare the Global Configuration site URL with the host Safari is using, including www and HTTPS.

Why is the administrator broken in Internet Explorer?

Joomla 4 and newer use Bootstrap 5 and modern JavaScript. IE11 is outside that support. Use Edge or another current browser.

Will HTML5 Shiv or Respond.js fix it?

No. Those scripts patched Internet Explorer 8. They do not fix Joomla 4, 5, or 6, and they should come out of the template.

The layout breaks on phones but not on desktop. Is that a browser bug?

No. If every browser breaks at the same width, it is responsive CSS or a missing viewport tag.

One browser still shows the old design after I changed the template. Why?

That browser cached the CSS. Test in a private window, then clear Joomla cache and the CDN.

Should I load jQuery so older browsers work?

No. Extra jQuery copies cause $ conflicts. Current Joomla does not need jQuery for the core layout.

Does Cassiopeia work in all browsers?

It works in the browsers Joomla supports. Use it as the control. If Cassiopeia is fine and your template is not, fix or replace the template.

Who can fix a template that only fails in one browser?

Infyways traces the console error and upgrades templates that cannot be patched. Request a Joomla upgrade audit.

The Joomla generator meta tag is a single line in the HTML head, <meta name="generator" content="Joomla! - Open Source Content Management">. Joomla adds it in the document class. There is no switch for it in Global Configuration on Joomla 3, 4, 5, or 6. Remove it with setGenerator('') before the head is rendered, or with a system plugin. An empty string omits the tag. null is the wrong value and can fatal on PHP 8.

The tag does not contain your version number. Removing it does not change Google rankings. It only drops one fingerprint. RSS feeds, the administrator login page, and administrator/manifests/files/joomla.xml still identify the CMS unless you handle those separately.

What you will learn

• The exact tag Joomla prints, and why it is not a version number
• How to see it in HTML and in RSS
• The template one-liner, and why it disappears on the next template update
• Why setGenerator(null) is unsafe
• What still gives the site away after the tag is gone

What the tag is

HTML’s generator meta names the software that built the page. Joomla sets that string when it creates the HTML document. It is not read from a menu item, not stored in the database, and not a language string you can override. The same property is written into RSS and Atom as a <generator> element.

On current Joomla 3.10, 4, 5, and 6 the content is only:

<meta name="generator" content="Joomla! - Open Source Content Management">

Very old releases (Joomla 1.5 and early 2.5) put the version in that string. That stopped years ago. If a scanner claims it learned “Joomla 3.9.28” from this meta tag, it learned it somewhere else.

What removing it does, and what it does not

Claim	Reality
Hides the Joomla version from attackers	The version is not in this tag. It is in administrator/manifests/files/joomla.xml and in the administrator’s System Information screen
Improves Google rankings	No. Google does not use meta name="generator" as a ranking signal
Hurts SEO	No, as long as you do not also delete the robots meta tag
Makes the site invisible to scanners	No. /media/system/js/core.min.js, /administrator/, and Cassiopeia paths still look like Joomla
Removed by a Joomla or template update if you only edited index.php	Yes. A template update replaces that file
Removed from RSS if you only call setGenerator inside <head> after the head include	No. Feeds never render that head block

Treat this as housekeeping, not as a security patch. An outdated Joomla site with the tag removed is still outdated. Update path: how to update Joomla.

Step 1: See the tag before you change anything

1. Open the public homepage.
2. View source (not only the inspector). Search for generator.
3. You should find the meta line above. Joomla 3 often writes it self-closed (/>). Joomla 4 and newer usually do not.
4. Open the feed: add ?format=feed&type=rss to the site URL, or use the RSS link in the page. Search for <generator>. The same sentence is there.
5. Optional: open /administrator/ and view source. The login page carries the tag too.

If the line is missing already, a plugin or the template is stripping it. Do not add a second strip until you know which one.

Step 2: Prefer a plugin over a template edit

A system plugin runs on every HTML and feed response and survives template updates. Infyways publishes Remove Meta Generator for this. Version 1.4 is for Joomla 4, 5, and 6. It clears or replaces the generator on the public site, can clean RSS and Atom, and can drop the X-Powered-By header. It does not touch the administrator. Listing: Joomla Extensions Directory.

1. Install the zip and enable System – Remove Meta Generator.
2. Set generator to remove, or replace it with your own brand text if you want a tag with different content.
3. Leave the robots option alone unless you have a reason to change indexing. Deleting meta name="robots" can drop a noindex you still need, or strip a normal index directive.
4. Clear Joomla cache and any CDN cache.
5. View source on the homepage and on one article. Then check the RSS feed.

Joomla 3 is not a target of the 1.4 build. On 3.10 use the template line in the next step, or stay on a plugin build that still lists Joomla 3.

Step 3: Or set an empty generator in the template

This works on Joomla 3, 4, 5, and 6. In templates/YOUR_TEMPLATE/index.php, before <jdoc:include type="head" /> and before <jdoc:include type="metas" />:

<?php
$this->setGenerator('');
?>

Use an empty string. Do not pass null. The document API types setGenerator as a string. On PHP 8 a null argument becomes a fatal once that type is enforced. An empty string is what makes the renderer skip the tag. Joomla only prints the meta when getGenerator() is non-empty.

Put the line at the top of the file if you are unsure. Code after the head include is too late: the meta block has already been built.

A template update overwrites index.php. Put the line in a child template, or use the plugin. Do not edit libraries/src/Document/HtmlDocument.php or libraries/joomla/document/html/html.php. The next Joomla update puts the tag back and can break the core file.

Step 4: Cover feeds, not only the homepage

The template line never runs for format=feed. A plugin event does. This is the body of a system plugin method. On Joomla 3.8 and newer, and on 4, 5, and 6, Joomla\CMS\Factory is available without the compatibility plugin:

public function onBeforeRender()
{
    $app = Factory::getApplication();

    if (!$app->isClient('site')) {
        return;
    }

    $doc = $app->getDocument();
    $type = $doc->getType();

    if ($type !== 'html' && $type !== 'feed') {
        return;
    }

    $doc->setGenerator('');
}

onBeforeRender is early enough for HTML and for RSS. onBeforeCompileHead is HTML-only, so a head-only hook leaves the feed element in place. Skip non-HTML types such as JSON and raw so you do not touch component output that is not a document head.

On Joomla 3.7 and older, swap Factory::getApplication() for JFactory::getApplication() and isClient('site') for isSite().

Step 5: Confirm it is gone, including cache

• View source on the homepage, an article, and a category blog.
• Search for name="generator". No match means the Joomla tag is gone. A match with different content means a template or extension hardcoded its own tag. setGenerator will not delete a string that was echoed by hand. Search the template for generator and remove that line.
• Open the RSS URL and confirm there is no <generator>Joomla! element, if you used the plugin or onBeforeRender.
• Clear System → Maintenance → Clear Cache, then the host cache or Cloudflare, or you will keep seeing the old HTML.
• Check /administrator/ only if you intended to change it. The JoomlaX plugin leaves admin pages alone on purpose.

Other fingerprints people confuse with this tag

Signal	What it is	Removed by setGenerator?
meta name="generator"	HTML fingerprint, no version	Yes, if you set an empty string in time
RSS <generator>	Same property, feed renderer	Only if the call runs for feed documents
X-Powered-By: PHP/x.y	Server header, not Joomla’s meta tag	No. Turn it off in PHP or in the plugin’s header option
administrator/manifests/files/joomla.xml	Core manifest, includes the version	No. This file is the real version leak
/media/system/js/core.min.js and /administrator/	Paths and the login screen	No
meta name="robots"	Indexing instructions	Should stay. Unrelated to the generator

Blocking the manifest is a hosting or Admin Tools job, not a meta-tag job. Hiding files is still weaker than installing updates. If the site is on Joomla 3, plan the move instead of collecting hide-the-CMS tricks: Joomla upgrade services.

SEO

Removing the generator tag does not move rankings. Google indexes the visible page, links, and a handful of meta tags it actually reads (description, robots). generator is not one of them. More on what does matter: Joomla SEO.

The change that does hurt SEO is a plugin option that deletes every robots meta. Leave that control on “leave” unless you are setting a specific policy, such as index, follow on purpose.

Key takeaways

1. The tag says Joomla. It does not say which version.
2. There is no Global Configuration checkbox. Use setGenerator('') or a plugin.
3. Never pass null. Never edit files under libraries/.
4. A template edit dies on the next template update and never touches RSS.
5. Removing the tag does not change SEO. Do not remove the robots meta while you are there.
6. Update Joomla. Hiding the tag is not a substitute.

Frequently asked questions

How do I see the Joomla generator meta tag?

View source on the homepage and search for generator. The default content is Joomla! - Open Source Content Management. The same text is in the RSS <generator> element.

How do I remove the Joomla meta generator from the head?

Call $this->setGenerator('') in the template before the head include, or enable a system plugin that does it on onBeforeRender. Empty string, not null.

Will removing the generator tag affect SEO?

No. Google does not use that meta tag for ranking. Leave meta name="robots" in place.

Does this tag reveal my Joomla version?

Not on Joomla 3.10, 4, 5, or 6. The version is in administrator/manifests/files/joomla.xml, not in the generator meta.

Does Joomla 5 or 6 still add the tag?

Yes. There is still no core switch. The same setGenerator('') call works, or use Remove Meta Generator 1.4.

Will a Joomla update put the tag back?

A core update does not restore a plugin setting. A template update does restore index.php if you edited the parent template. Core file hacks under libraries/ are overwritten.

Does the template line remove it from RSS?

No. Feeds do not load index.php. Use onBeforeRender or a plugin that cleans feed output.

Is setGenerator(null) safe on PHP 8?

No. Pass an empty string. Null does not match the string argument and can fatal.

Can I remove it without editing files?

Yes. Install Remove Meta Generator, enable it, clear cache, and view source.

Call to a member function setState() on null (also “on bool”, “on boolean”, or “on a non-object”) means Joomla tried to call setState() on a model that was never created. getModel(), JModelLegacy::getInstance(), or createModel() returned false or null, and the next line did not check. This is not a session error, and clearing the cache does not create the missing class.

The line that dies is almost always a content module or an old component controller preparing a list query. The fix is to load the model, or to update or disable the extension named in the stack trace.

What you will learn

• What setState() does on a Joomla model, and why this is not React and not the session
• Why the same bug is worded three different ways on PHP 7 and PHP 8
• How to read the file path and name the extension in one minute
• The Joomla 3 include-path failure, and the Joomla 4, 5, and 6 bootComponent() pattern
• What to do when the administrator will not open

What the error actually means

Joomla list screens do not read $_GET inside the query. They park filters on the model first:

$model->setState('filter.published', 1);
$model->setState('list.limit', 5);
$model->setState('params', $params);
$items = $model->getItems();

setState() only exists on a model object (ListModel, BaseDatabaseModel, and the older JModelLegacy). If $model is false or null, PHP stops with a fatal error before getItems() runs. The message changes with the PHP version, not with the bug:

What PHP says	What $model is	Typical PHP
on a non-object	false from getInstance() or getModel()	PHP 5
on boolean	Same false	PHP 7
on bool	Same false	PHP 8 and newer
on null	createModel() found nothing	PHP 7.0+ and Joomla 4+

A different sentence, Call to undefined method ... setState(), means you do have an object, but it is the wrong class. Do not mix those up. This article is only the null or false case.

This is not the session, and it is not React

Session data in Joomla is $app->setUserState() and getUserState(). Deleting files in /tmp, logging out, or emptying #__session does not make getModel() return an object. Do that only when the error text actually names the session handler.

React’s setState() is a JavaScript method on a component. A PHP fatal in a .php file under modules or components has nothing to do with a React build. If the stack trace is a .js bundle, you are in a different app that happens to be hosted beside Joomla.

Where it breaks

Path in the error	What failed	Fix
modules/mod_articles_latest, mod_articles_category, mod_articles_news, mod_related_items	The articles model was not booted before setState('params')	Use the core helper pattern below, or replace a cloned module
components/com_SOMETHING/controller.php or controllers/cpanel.php	$this->getModel() returned false, then the controller called setState anyway	Update that component. Pass the model name. Check the return value
administrator/components/com_SOMETHING	Same failure, backend only	Disable that admin component. The public site can stay up
libraries/legacy/controller or libraries/src/MVC/Controller	Core ran. The component in the URL did not provide a model	Read option=com_... in the URL. Fix that extension, not the library
templates/YOUR_TEMPLATE/html	An override copied an old helper	Compare it with the current core file and drop the stale copy

The classic core case was Joomla 3.5.0: mod_related_items/helper.php line 44 called setState() on false because com_content models were not on the lookup path. That was fixed in 3.5.1. The report is still the best illustration of the bug: Related Articles module fatal error. Third-party modules still copy the broken pattern.

Step 1: Get the file and the line

1. If the page is a blank 500, open the host PHP error log or administrator/logs/. The fatal is one line: message, file, line number.
2. On a staging copy you can set Global Configuration → Server → Error Reporting to Maximum. Turn it off again on production. Do not leave display_errors on a public site.
3. Copy the first fatal only. Later errors are fallout.
4. A white page with no setState text may be .htaccess instead. Check that only after the log is silent. Guide: Joomla 500 on mod_rewrite.

Step 2: Confirm the variable is empty

Open the file at the line number. You want a call shaped like one of these:

• $model->setState(
• $this->getModel()->setState(
• $defaultModel->setState(

Look up three to ten lines. The assignment is getInstance, getModel, or createModel. There is no if (!$model) before setState. That missing check is the crash. Adding a return when the model is empty stops the fatal. It does not by itself bring the module back. You still have to make createModel succeed.

Step 3: Name the extension from the path

• mod_ prefix: a module. Unpublish that module to confirm the homepage returns. System → Manage → Extensions, or published = 0 on that row in #__modules if you cannot log in.
• com_ prefix: a component. The menu item or the URL option= is what triggers it. Note the folder name before you disable anything.
• plg_ or plugins/: a plugin. Rename that plugin’s folder over FTP if the administrator is already dead.
• Path contains libraries/joomla or libraries/src and your Joomla version is current: core is the messenger. The broken model belongs to the component in the request.

Take a backup before you rename folders or edit PHP. Method: how to backup a Joomla website.

Step 4: Load the articles model the way core does now

On Joomla 4, 5, and 6, article modules boot the component, then set state. This is the current core pattern in Latest Articles:

$model = $app->bootComponent('com_content')
    ->getMVCFactory()
    ->createModel('Articles', 'Site', ['ignore_request' => true]);

if ($model === null) {
    return [];
}

$model->setState('params', $app->getParams());
$model->setState('filter.published', 1);
$model->setState('list.limit', (int) $params->get('count', 5));

$app is Factory::getApplication(). ignore_request stops the model from reading the page URL as its own filters, which is what you want inside a module. Core reference: ArticlesLatestHelper.php.

If createModel still returns null, com_content is missing, half-updated, or the model name is wrong. Reinstalling random core files is not the first move. Confirm components/com_content exists and that System → Maintenance → Database shows no schema errors. A partial update leaves new PHP calling old tables, or the reverse. Update path: update Joomla and fix update errors.

Step 5: Fix the Joomla 3 version of the same bug

Joomla 3 will not boot a component. You add the model folder, then ask for the class prefix ContentModel:

JModelLegacy::addIncludePath(
    JPATH_SITE . '/components/com_content/models',
    'ContentModel'
);

$model = JModelLegacy::getInstance(
    'Articles',
    'ContentModel',
    array('ignore_request' => true)
);

if (!$model) {
    return array();
}

$model->setState('params', $params);

The file on disk must be components/com_content/models/articles.php and the class must be ContentModelArticles. A renamed class returns false from getInstance, and the next setState is this fatal.

Do not paste the Joomla 3 block into Joomla 4, 5, or 6. JModelLegacy is legacy. On current Joomla the failure mode changes: either the class is missing (see class not found after an upgrade) or getInstance returns false and you are back to setState() on bool. Use bootComponent().

Step 6: Update or disable the extension in the trace

If the file sits in a commercial component, you cannot invent its model name from the articles example. The controller is calling $this->getModel() with no name, the default model file is gone or not autoloaded after a Joomla 3.10 or Joomla 4 hop, and setState runs on false. That is an extension bug.

• Update it to a build that lists your Joomla major.
• If there is no update, disable it and unpublish its modules and menu items.
• Do not edit libraries/ to hide the message. The next core update overwrites the library and the fatal returns.
• A template override of a module helper is a copy. Delete the override and let the current module file run. Then retest.

Major-version breakage of this kind is covered in Joomla upgrade issues. Hop order still matters. A Joomla 3 controller will not start loading models correctly just because the site folder was copied onto Joomla 5.

Step 7: Clear cache after the page renders

Module HTML is often cached. A cached fatal, or a cached empty module, can linger after you fix the PHP. Clear it only once the uncached page works:

1. System → Maintenance → Clear Cache, or the cache button on the module.
2. Clear the host or CDN cache if the HTML is stored there.
3. Reload the page that crashed. The log line for setState should be gone.

If you clear cache first and the model is still null, the error comes straight back. Cache was never the cause.

Step 8: Get the administrator back

1. Read the log. If the path contains /administrator/components/com_ or /plugins/, rename that one folder via FTP or the host file manager. Joomla skips an extension whose folder is missing.
2. If a site module crashes every admin page because it is assigned to the admin menu, unpublish it in #__modules (published set to 0). Match module to the mod_ name from the log.
3. Leave com_content, com_users, and com_login in place. Renaming those locks you out for a different reason.
4. When the administrator loads, update or uninstall the extension properly, then restore the folder name only if you still need it.

What a correct call looks like

Core always sets state after it knows the model exists. The states you will see in article modules are the query, not user session keys:

• params: component or module parameters
• filter.published, filter.category_id, filter.access, filter.language, filter.featured
• list.start, list.limit, list.ordering, list.direction

If your code sets those on a model that failed to load, fix the load. If your code sets them on $app, you wanted setUserState() and you are in the wrong API.

When to stop patching the module

Stop if any of these are true:

• The trace names a component you cannot update, and the site still runs Joomla 3
• Several modules fatal with the same createModel null after a half-finished upgrade
• You already renamed folders and you are not sure which ones the business needs

Infyways runs those repairs and version jumps from $149, with a compatibility audit within 12 hours. Start at Joomla Upgrade Services.

Key takeaways

1. setState() on null or bool means the model object was never created.
2. It is not the session, not React, and not fixed by emptying /tmp.
3. The file path is the extension name. Start there.
4. Joomla 4, 5, and 6 load article models with bootComponent('com_content') and createModel('Articles', 'Site').
5. Joomla 3 needs addIncludePath plus ContentModelArticles. Check getInstance before setState.
6. Clear cache after the page renders, not before.

Frequently asked questions

What does Call to a member function setState() mean in Joomla?

PHP called setState() on null or false. In Joomla that value was supposed to be a model from getModel(), getInstance(), or createModel().

Is this a session or login error?

No. Session storage uses setUserState(), which is a different method. Logging out or deleting /tmp does not load a missing model.

Why does it say on bool on one site and on null on another?

Same failure. getModel() and getInstance() return false, so PHP 8 says “on bool”. createModel() returns null, so PHP says “on null”.

Which file should I open?

The file and line in the error. That line is the setState call. The extension folder in that path is what you update or disable.

Will Clear Cache fix it?

No. Clear cache only after the model loads, so Joomla does not keep serving a cached copy of the crash.

Does Joomla 5 or 6 still use setState()?

Yes. Article modules still call $model->setState() after createModel('Articles', 'Site'). The method is fine. A null model is not.

Can I fix it by reinstalling Joomla core?

Only when the trace points at a core file that does not match a stock copy of your version. If the path is a third-party component, reinstalling core leaves the bug in place.

The administrator is a white screen. How do I get in?

Rename the plugin or admin component folder named in the log. Do not rename com_login or com_users. Unpublish a site module from #__modules if that module is what crashes.

Who can fix setState() fatals across an upgrade?

Infyways traces the model load and finishes the version jump when the extension has no update. Request a Joomla upgrade audit.

A Joomla module is not showing when the module row is not allowed to render for that request: Status is not Published, Access or Language excludes the visitor, Menu Assignment is No pages (or the ticks do not include this Itemid), publishing dates are outside now, or cache still holds an empty slot. A Note in the module list is not a status. This article is that checklist. It is not position wiring (name vs jdoc). It is not “the module appears, but on the wrong pages.”

If Status, Access, Language, Assignment, and dates are already correct and the region is still empty on every page that uses this template, stop here and open Joomla module position not showing. If the module shows, just not where you meant, open Joomla module showing on the wrong pages. Official assignment help: How do you assign a module to specific pages? and Module display by menu item. Site module overview: Site Modules.

Published is not enough. Access, Language, Menu Assignment, Start and Finish dates, and cache each get a veto. A Note in the list is only an admin reminder.

What you will learn

• How to read Status versus the Note column
• Why a Super User still “proves nothing” until you test as a guest
• What Menu Assignment No pages does (without the full wrong-pages deep dive)
• How Language Filter hides a module that is Published
• How Start Publishing and Finish Publishing hide a Published module
• When module cache or Page Cache makes a fixed module look missing
• When to hand off to the position article (and when not to)

What you see	Likely cause	Wrong rabbit hole
Missing everywhere, including Home	Unpublished, Trashed, No pages, dates, or Access	Reinstalling the module type
Missing for guests, visible when you are logged in	Access is Registered (or higher)	Position names
Missing in one language	Module Language is not All / not that language	CSS
Missing only after a date you set	Finish Publishing passed, or Start is still in the future	Cache only
You “fixed it,” guests still see empty	Page Cache or Progressive module cache	Editing index.php
Empty slot, ?tp=1 shows the position name	Position wiring or chrome/CSS	This article’s Status toggles
Module HTML in View Source, invisible on screen	Chrome or CSS	Publishing dates

Step 1: Confirm Status is Published (Note is not Status)

System → Site Modules. Filter carefully. Administrator modules are a different list (Administrator Modules). A login module you edited in the backend list will never appear on the site.

Open the module you think is missing. Status must be Published. Unpublished and Trashed do not render. A yellow or grey icon in the list is easy to miss if you sorted by Note.

The Note field (Administrator Note) is a private reminder in the module list. It does not publish anything. It does not unpublish anything. Operators scan the Note column, see a comment such as “hold” or “old,” and assume Joomla unpublished the row. Read the Status column, then the module header Status dropdown.

Also check you are not editing a Save as Copy draft. Two rows, same title, one Published on Home, one Unpublished. The frontend uses the published id. Confirm the id in the URL (id=) matches the row you intend.

If Status is Published and you still see nothing, do not toggle it twice “to refresh.” Leave it Published and continue.

Step 2: Match Access to the visitor you are testing

Access is a veto.

• Public: guests can see it (if every other check passes).
• Guest: logged-in users may not see it (depending on your ACL). Super Users testing while logged in will swear the module is missing.
• Registered and above: guests will not see it. That is correct ACL, not a bug.

Test a private window logged out if the module should be public. Test a registered account if it should be members-only. Do not debug Access while logged in as Super User unless you also check a guest.

ACL background: Access Control List and the user manual Access Control.

If the site is multilingual, Access still applies per request. Language is a separate veto (Step 4).

Step 3: Rule out Menu Assignment of No pages

Open Menu Assignment.

If Module Assignment is No pages, the module never renders. That looks identical to Unpublished on the frontend. Set it to On all pages for this diagnosis, save, retest one URL. If it appears, Assignment was the veto. Then set the real map using module showing on the wrong pages. Do not rebuild that whole Itemid article here.

If Assignment is Only on the pages selected and the tree has no ticks (or only a hidden-menu item you are not visiting), the module is effectively No pages. Expand: All. Confirm the item for the URL you have open is ticked.

If Assignment is On all pages and the module is still missing everywhere, Assignment is not the problem. Continue. If it is missing on some URLs and present on others, you are on the wrong-pages article, not this one.

Default for a new module is often On all pages. Copies inherit whatever the original had, including No pages from a test.

Step 4: Set Language to All, or to the language of the page

Language on the module must be All, or the same language as the page Joomla is serving.

With System – Language Filter published, a module set to English is omitted on the French page even when Status is Published and Assignment includes that menu item. That is Language Filter doing its job.

Test:

1. Set Language to All. Save. Clear cache. Retest.
2. If you need per-language modules, duplicate the module (Save as Copy), set each copy’s Language, and assign each to the matching menu items. Do not expect one English module to print on every language.

Site vs Administrator language packs do not apply here. This is the module’s Language field on Site Modules.

Step 5: Check Start Publishing and Finish Publishing

Open the Publishing tab.

• Start Publishing in the future: Status can say Published. The module still waits. Site timezone is Global Configuration, not your laptop clock.
• Finish Publishing in the past: the module has expired. Published-looking rows still vanish.
• Empty dates: no date veto.

A campaign module you scheduled last quarter will “randomly” disappear on the Finish day. That is not cache and not a template update.

If you use scheduled tasks or a workflow elsewhere, they do not replace these two fields. Read the Publishing tab on the module itself.

Step 6: Clear module cache and Page Cache after a real fix

Once Status, Access, Assignment, Language, and dates are correct, an empty guest page can still be yesterday.

1. System → Maintenance → Clear Cache. If that does nothing, the handler may be Redis: Joomla cache not clearing.
2. Module Advanced → Caching. A cached empty output can survive your publish click until the cache key expires. Set to No caching on staging to prove it, then put a sane cache back.
3. System – Page Cache: guests get a full HTML snapshot from before the module was published. Logged-in Super Users skip it and think the site is fine. Test a private window. Layers: cache showing old content.

Progressive System Cache is aggressive about module combinations. If a module “won’t come back” after you publish it, Progressive plus Page Cache is a usual pair. Conservative is enough for most sites.

Do not “fix cache” by deleting cache/ in FTP when Cache Handler is Redis.

Step 7: Only then ask whether the position exists

If every check above passes and View Source still has no module HTML on a page that should include it:

• The position string may not exist on this template (position-7 on Cassiopeia, or a name with no jdoc). That is module position not showing.
• The menu item may use a different template style whose index.php never includes that position. Still a position/style problem, not Status.

If View Source has the module HTML, the module showed. Chrome, CSS, or a script hid it. CSS: Joomla CSS changes not showing. JS emptying the node: Joomla JavaScript not working.

Do not add a jdoc to parent Cassiopeia to “make it show.” Extra positions belong on a child template. Safe file rule: customize without editing core.

Custom HTML inside the module that looks stock is an override or chrome issue, not unpublished: template override not working.

Status, then Access, then Assignment plus Language, then cache, then dates. Treat Note as a label, not a switch. Position wiring is a later article.

Key takeaways

1. A Joomla module is not showing when a veto failed: Status, Access, Language, Menu Assignment, dates, or cache. Note is not a veto.
2. Test as a guest in a private window. Super User Access proves little for Public modules.
3. No pages (or Only-on-selected with no ticks) looks like Unpublished on the frontend.
4. Language Filter hides modules whose Language is not All and not this page’s language.
5. Start Publishing in the future and Finish Publishing in the past hide a Published row.
6. Page Cache and module cache keep an empty guest page after you fix the row.
7. Position name vs jdoc is module position not showing. Wrong URLs are wrong pages.
8. Do not edit core index.php to compensate for Unpublished.

Frequently asked questions

Why is my Joomla module not showing?

Status is not Published, Access or Language excludes the visitor, Menu Assignment is No pages or unticked, Start or Finish dates hide it, or cache still has the empty page. Check those before you touch the template.

What is the difference between a Note and Unpublished?

Note is an administrator reminder in the module list. Unpublished is Status. Only Status (and dates, Access, Language, Assignment) control the frontend.

Should I fix the template position first?

Only after this list passes. If the module is unpublished, a perfect jdoc still prints nothing. Position wiring is Joomla module position not showing.

Why do I see the module when logged in but guests do not?

Access is not Public, or Page Cache is serving guests an old empty HTML page. Test a private window after Clear Cache.

Can Language hide a published module?

Yes. With Language Filter on, a module set to one content language is omitted on the other. Set Language to All to prove it.

The module shows on Home but not on Contact. Is that this guide?

That is Menu Assignment / Itemid. Use Joomla module showing on the wrong pages. This page is for modules that show nowhere (or nowhere for that visitor).

Where are the official module assignment docs?

How do you assign a module to specific pages? and Module display by menu item.

Conclusion

When a Joomla module is not showing, read the module row like an operator: Published, Public (or the Access you intend), Assignment that is not No pages, Language All or matching, dates that include now, then cache. Ignore the Note column as a status. If that list is clean and the slot is still empty, the position name or the template style is next: module position not showing. If the module is visible on the wrong URLs, that is wrong pages.

If production has copies, languages, and Page Cache stacked, Joomla support and maintenance is faster than toggling Status. Layout and chrome work: Joomla design services.