Blog

If you published in Joomla and still see the old page, you are looking at a cache layer, not a failed save. The copy can sit in Conservative or Progressive view/module cache, in the System – Page Cache plugin (guests only), in Cloudflare or another CDN, or in the browser. Logged-in users and guests often see different HTML. Clear the layer that actually served the response. This article is “stale content.” If the Clear Cache button does not change storage at all, use Joomla cache not clearing properly.

Joomla 4, 5, and 6 expose cache under System → Global Configuration → System (Cache Settings): OFF, ON Conservative caching, ON Progressive caching, plus Cache Handler and Cache Time. Whole-page HTML is the System – Page Cache plugin, documented separately in Joomla Cache. Programmer view of the three mechanisms: Caching components and modules. Page Cache serves logged-out visitors. Logged-in requests rebuild. That single fact explains “I see the new article, my boss does not.”

Cloudflare (and Varnish, LiteSpeed, nginx reverse proxy) sit in front of Joomla. Joomla’s Clear Cache cannot purge them. Official Cloudflare purge: Purge cache.

Four layers. Guests hit Page Cache and CDNs. Logged-in users skip Page Cache. Progressive cache is the usual “wrong module” layer.

What you will learn

• Which Global Configuration cache mode you are on (and why Progressive looks “stuck”)
• How Page Cache differs from Conservative caching
• Why guests and logged-in users disagree
• How browser cache and “Use Browser Caching” hide a good origin
• How to purge Cloudflare without guessing
• When stale content is working as designed (Cache Time still valid)

The layers, in the order you should blame them

Official plugin note: Page Cache keeps serving until Cache Time in Global Configuration expires, unless you delete that cache. Default Cache Time in the Cache tutorial is 15 minutes.

Step 1: Prove it is cache, not a second page

Confirm you edited the article that the URL actually loads (right menu item, right language, right category blog vs single article). Then:

1. Open the URL in a private window, logged out.
2. Open the same URL logged in.
3. Compare.

If a private window logged out is new and your normal browser is old, it is browser cache. Hard refresh. If the Page Cache plugin has Use Browser Caching enabled, the visitor’s browser is allowed to keep the page until headers expire. Joomla cannot remotely smash that copy. Leave Use Browser Caching off unless you accept that.

Step 2: Read System Cache: Conservative vs Progressive

System → Global Configuration → System → Cache Settings.

OFF: Joomla is not keeping view/module cache. If you still see old HTML, it is Page Cache, CDN, browser, or a proxy. Global OFF does not disable Cloudflare.

ON – Conservative caching: Views and modules cache with context (pages and access levels). Modules may set Advanced → Caching to Use Global or No caching. Official Cache doc: enable Conservative, then set modules you want cached to Use Global.

ON – Progressive caching: Official docs: turn it on in the same System Cache dropdown. It is more aggressive. Module-level No caching is not a reliable guest escape hatch under Progressive (documented across Joomla cache explainers and the programmer manual’s progressive vs conservative split). Symptom: a module from another page, or a module that should have updated. Fix: set System Cache to Conservative on staging, Clear Cache, retest logged out.

Do not jump to Progressive to “fix stale.” Progressive makes more cache, not less.

Cache Handler File stores under cache/ (site) and administrator/cache/ (admin). Redis/Memcached/APCu store in memory. The dropdown is the source of truth, not the folder you happened to empty in FTP.

Step 3: Check the System – Page Cache plugin

System → Manage → Plugins → System – Page Cache.

Enabled means guests can receive a full HTML snapshot of the URL. That snapshot includes component and modules. It is supposed to be stale up to Cache Time. After you publish:

1. System → Maintenance → Clear Cache → Delete All (or the page cache group if you can identify it).
2. Reload logged out.

If it is immediately old again, something in front (CDN) re-cached, or Cache Time is so short you are confused with a different bug. If it never updates until you disable the plugin, the plugin is the layer. Use Excluded Menu Items / Exclude URLs for pages that must always be live (login, contact, cart), as the Cache documentation’s page-cache section implies by design: a full page snapshot is the least flexible option.

Page Cache does not apply the way people think for logged-in users. Do not use a super-admin window as proof that guests are fresh.

Step 4: Purge Cloudflare (and any other CDN) on purpose

If DNS is proxied through Cloudflare, you have at least two caches. Joomla Clear Cache is not a Cloudflare API call.

In Cloudflare: purge that URL, purge everything (heavier), or enable Development Mode while you test. Docs: Purge cache. Then retest logged out.

Other stacks (LiteSpeed cache plugin, Varnish, nginx proxy_cache) need their own purge. If you do not control the CDN, ask the host which cache sits in front.

Page rules that “cache everything” on HTML will fight Joomla. Bypass /administrator/ always. Bypass or respect origin headers for HTML if you need instant publishes.

Step 5: Clear Joomla cache the official way, then retest guests

System → Maintenance → Clear Cache deletes groups (or Delete All). Clear Expired Cache only drops items past Cache Time. Expired files can sit on disk until purge. If you need the new article now, use Clear Cache, not only expired.

After a template or override change, Delete All. After a routine article save, core often fires cache-clean events, but Page Cache and CDNs still need the steps above.

Retest:

1. Private window, guest: must match the editor.
2. Logged-in: already skipped Page Cache.
3. Phone on cellular: often a different CDN POP or a ruthless browser cache.

If Clear Cache reports success but Redis still serves old HTML, you did not fail to publish. The handler was not File. That failure mode is cache not clearing.

Speed after a correct clear: speed up Joomla. Do not disable all cache forever because one guest saw a 15-minute-old home page. That is Cache Time doing its job.

Guest vs logged-in first. Then Progressive vs Conservative. Then Page Cache. Then Cloudflare. Then the browser.

Key takeaways

1. Stale public HTML is a layer problem. The article in the database can already be new.
2. Page Cache is guest-only. Compare private-window guests to your logged-in editor.
3. Conservative is the usual System Cache. Progressive is the usual wrong-module stale.
4. Cloudflare does not listen to Joomla Clear Cache. Purge the CDN separately.
5. Use Browser Caching on Page Cache moves staleness into the visitor’s machine.
6. Cache Time (minutes, default 15 in core docs) means “old” can be correct until expiry.
7. If storage never changes when you click Clear, switch to the not-clearing article.

Frequently asked questions

Why does my Joomla site show old content after I publish?

A cache still holds the previous HTML. For guests that is often System – Page Cache or Cloudflare. For modules on the wrong page, Progressive caching is a frequent cause. Clear the matching layer and retest logged out.

Do logged-in users see Joomla Page Cache?

The System – Page Cache plugin is built to serve logged-out visitors. A logged-in Super User is a bad test for what the public sees. Use a private window without logging in.

What is the difference between Conservative and Progressive caching?

Both are System Cache modes in Global Configuration. Conservative respects per-module Use Global vs No caching more the way people expect. Progressive caches modules more aggressively and is a common source of stale or misplaced module output. Official options: OFF, Conservative, Progressive.

How do I clear Joomla cache in Joomla 4, 5, and 6?

System → Maintenance → Clear Cache, then Delete All or selected groups. Settings live under System → Global Configuration → System. Expired-only cleanup is Clear Expired Cache.

Does Cloudflare cache Joomla HTML?

If the zone is proxied and the page is eligible, yes. Purge in Cloudflare. Joomla’s cache/ folder is not the edge cache. See Cloudflare’s purge documentation.

Should I turn cache off to stop old content?

Only as a short staging test. Turning everything off makes the front end slow. Prefer Conservative, sensible Cache Time, Page Cache exclusions, and CDN purge on publish.

Why is the home page old but the article URL is new?

Different cache IDs and often a cached home module or Page Cache entry for /. Clear all, purge the home URL at the CDN, and check Progressive if a module is showing yesterday’s list.

Conclusion

Old Joomla content after a save means a layer still has the previous response. Split guest vs logged-in, then Progressive vs Conservative, then Page Cache, then Cloudflare, then the browser. Clear that layer. Keep cache on for speed once publish-and-purge is a habit. The how-to for performance is speed up Joomla. The how-to when the broom itself is broken is cache not clearing.

A slow Joomla administrator is usually update-site HTTP pings, Debug System left on, a locking session handler, too many modules on the Home Dashboard, or a long chain of enabled administrator plugins. It is not the same problem as a slow public site. Atum (the default admin template) is rarely the root cause. The Home Dashboard and com_installer talk to the network. The public Page Cache plugin does not save you here, because it is for guest HTML on the site, not for /administrator/.

Joomla 4, 5, and 6 paint the control panel with administrator modules. Sample data, backup dashboards, and extension “cpanels” add more tiles. Each tile is work. Separately, the installer update finder (com_installer / Joomla Update) contacts update sites. Dead or slow vendor URLs sit there until PHP times out. That matches what people see as “Checking extensions…” hanging on the dashboard. Core discussed this class of delay when update checks moved to AJAX on the control panel (joomla-cms discussion of update checks): expired update cache means one HTTP call per update server.

Filesystem PHP sessions can also serialise admin clicks (exclusive lock on the session file until the request ends). That is PHP behaviour, and it shows up with multiple admin tabs. Joomla’s own tracker has pointed people at the Database session handler when Filesystem locking bites (session start / Filesystem). Test handler changes on staging after a backup.

Public cache will not fix /administrator/. Look at update sites, Home Dashboard modules, Debug System, and the session handler.

What you will learn

• Why Atum is usually innocent
• How update sites and com_installer stall the dashboard
• That unpublished modules and disabled plugins do not run (and what still does)
• How Debug System makes every admin page heavier
• How to try Database vs Filesystem sessions without guessing on production
• How this differs from a slow Joomla front end

Admin slow vs site slow

If the public site is also slow, run the front-end diagnosis in parallel. Do not skip this article because you already turned on Conservative cache. That setting does not cache the administrator UI the way people hope.

Step 1: Confirm it is administrator, not the whole origin

Open a public URL logged out. If that is fast and /administrator/index.php is not, stay here. In the browser Network panel on the dashboard, watch:

• The document TTFB for administrator/index.php
• XHR/fetch calls to Joomla Update and installer update find (option=com_joomlaupdate, option=com_installer with task=update.find)
• Long-pending requests to third-party hosts (vendor update XML)

If those installer calls sit in pending for many seconds, you have an update-site problem until proven otherwise. If the document itself is slow with no update XHR, look at debug, sessions, and PHP.

Use staging for experiments. Take a backup before you disable update sites or switch session handlers.

Step 2: Audit update sites (com_installer), not the template

Atum is the core administrator template. A slow dashboard on stock Atum is almost never “pick a new admin theme.” Third-party admin templates can add JS, but start with installer traffic.

System → Install → Update Sites (Joomla 4+ System dashboard: Install → Update Sites). You will see one row per extension update server, plus Joomla core.

Then System → Update → Extensions (or Installer Update) and use Check for Updates once. If that screen is slow but Content → Articles is fine, the diagnosis is still update HTTP, not “Joomla admin is generally broken.”

Installed extensions live under administrator/components/, plugins/, modules/, components/. A crowded extensions tree means more update sites if those extensions registered one. Uninstall what you do not use (backup first). Unpublishing a module does not remove its update site. Disabling a plugin stops it running. It may still have an update site until you clean Update Sites.

Do not disable the Joomla core update site to “make admin fast.” You need core security releases.

Step 3: Cut Home Dashboard modules (the administrator cpanel)

The Joomla 4+ Home Dashboard is a module chrome. Extra “cpanel” tiles from backup tools, documentation, and sample data all load on that view.

System → Manage → Administrator Modules (client: Administrator). Unpublish tiles you do not need on the Home Dashboard. Unpublished administrator modules do not render. That is the correct way to slim the cpanel.

Do not confuse this with Site modules. Unpublishing a site footer module will not speed /administrator/.

Sample data packs are a frequent source of extra admin modules. If you installed sample data on a real site, remove the sample dashboard modules you do not use.

Step 4: Turn off Debug System on production

System → Global Configuration → System: Debug System = No for live administrator work. Server tab: Error Reporting = System Default (not Maximum or Development) on production.

Debug System Yes was the right move for a white screen. Left on, it prints query lists and debug chrome on administrator pages. That is extra work every click. It is a common “we fixed the outage and now admin is awful” leftover.

Step 5: Test the session handler, then enabled plugins

System → Global Configuration → System, Session section: Session Handler. Common options you will actually see: PHP / Filesystem-style, Database, and Redis when the extension and server exist. Exact labels follow your Joomla version.

Filesystem (PHP files) can lock: one slow admin AJAX holds the session file, other tabs wait. Database is the documented alternative when that happens. Change this on staging first. Changing session handler logs people out (new store). Backup configuration.php and the database.

If sessions are fine and update sites are clean:

1. List enabled plugins (System → Manage → Plugins). Sort by Status.
2. Disabled plugins do not execute. You do not need to hunt unpublished plugins for CPU.
3. Enabled system plugins still run on administrator requests when they subscribe to those events. Temporarily disable non-core ones on staging and retest a heavy screen (Extension Manage, Module list).

A huge plugins/ folder of disabled leftovers is disk clutter and update-site clutter. It is not per-request PHP unless something is still enabled.

PHP version still matters. Joomla 5 wants 8.1+; Joomla 6 wants 8.3+. Admin on an undersized PHP worker pool feels like “Joomla is slow” when the origin is queued. That is hosting, same as the front end. Recipe overlap: speed up Joomla for origin capacity, upgrade if the stack is ancient.

Installer pings first. Then cpanel modules. Then debug. Then session handler. Then enabled plugins.

Key takeaways

1. Slow /administrator/ is not fixed by System – Page Cache or Cloudflare HTML cache.
2. Atum is the default admin template. Update sites and dashboard modules are likelier than a template swap.
3. com_installer / Joomla Update will wait on every live update site. Disable dead vendor URLs.
4. Unpublished administrator modules do not render. Disabled plugins do not run. Enabled leftovers and leftover update sites still cost you.
5. Debug System Yes belongs off on production after you finish an outage.
6. Filesystem sessions can lock multi-tab admin. Try Database on staging. Expect a log-out.
7. If the public site is also slow, diagnose it separately.

Related Joomla troubleshooting

• Why is my Joomla website slow
• Website suddenly stopped working
• Cache not clearing

Frequently asked questions

Why is the Joomla admin dashboard slow when the site is fast?

The administrator does not use guest Page Cache. The Home Dashboard loads administrator modules and often waits on update-site HTTP. The public site can be cached at the edge while /administrator/ still talks to PHP, the database, and vendor URLs.

Do unpublished extensions still load in the administrator?

Unpublished modules do not render. Disabled plugins do not run. Extensions that are still installed can still have Update Sites, and enabled plugins still run. Clean Update Sites and uninstall what you do not need. Do not assume unpublished equals gone.

Is Atum making my Joomla 4, 5, or 6 admin slow?

Usually no. Atum is core. Profile the dashboard network tab for installer XHR before you buy an admin template. A third-party admin template can add its own cost, but it is not the first check.

How do update sites slow com_installer?

Check for Updates requests each update server whose cache expired. One dead host can stall the dashboard or the update view until PHP gives up. Disable that row under Update Sites and retest.

Should I enable Debug System to find admin slowness?

Briefly, on staging, if you need query times. On production it makes every page heavier. For update-site stalls, the Network panel is the clearer tool.

Will changing session handler to Database speed up admin?

It can, when Filesystem session locks are the bottleneck (many tabs, long requests). It is not a universal accelerator. Test on staging. You will need to log in again.

Does Cloudflare cache the Joomla administrator?

You should not cache /administrator/ at the CDN. If someone did, you get stale admin HTML and odd logins, not a speed win. Bypass admin in Cloudflare page rules. Public speed is the front-end article.

Conclusion

Treat a slow Joomla admin as a control-panel problem: update pings, dashboard modules, debug left on, session locking, enabled plugins. Leave Atum alone until those are clean. Take a backup, use staging for session and plugin tests, and keep the core update site enabled.

If you want someone else to keep update sites and PHP current, that is Joomla support and maintenance.

A slow Joomla front end is usually oversized images, cache left off, a high Time to First Byte (TTFB), heavy extensions, or hosting that cannot hold PHP and MySQL at the same time. Diagnose those causes here. When you know which layer is slow, follow the fix list in How to speed up a Joomla website. This article is the checklist. That article is the recipe. It is not a white-screen outage, and it is not a slow administrator (that is a different pipeline).

TTFB is the wait before the first byte of HTML arrives. If that is already hundreds of milliseconds to seconds, compressing CSS later will not save you. If TTFB is fine and the page still crawls, look at image bytes and third-party JavaScript. Joomla cache (Conservative / Progressive, Cache Handler, System – Page Cache) sits in the middle: off means every guest pays full PHP and SQL; on means you must still watch freshness (separate posts).

Official cache behaviour: Joomla Cache documentation and the programmer notes on caching views and modules. PHP floors: Joomla 4 / 5 / 6 technical requirements (Joomla 5.4, Joomla 6). Recommended PHP memory is at least 256MB. That is a floor, not a speed guarantee.

Measure TTFB first. Then weigh image transfer. Then check whether Joomla cache and Page Cache are even on for guests.

What you will learn

• How to split “slow HTML” (TTFB) from “slow assets” (images, JS, CSS)
• What “cache off” actually means in Global Configuration vs the Page Cache plugin
• Why huge images dominate front-end time even on a tuned PHP box
• How to spot an extension tax without guessing
• When hosting (CPU, I/O, PHP workers, distance to DB) is the real cause
• Which Infyways guide to open once you know the cause

Front end vs administrator vs down

Do not tune cache on production as your first experiment if you have never taken a backup. Use staging for Progressive cache and for turning Page Cache on.

Step 1: Measure TTFB and what the browser actually downloads

Open the public URL in a private window while logged out. Logged-in users skip the System – Page Cache plugin by design (it serves guests only). If you test while logged in, you will call the site “uncacheable” when guests would have been fine.

In the browser Network panel:

1. Reload with cache disabled (or hard refresh once to see uncached assets, then a second load for repeat-view).
2. Note the document request: status, waiting (TTFB), total time.
3. Sort by size. Note images, then JS, then CSS.
4. Note third-party hosts (fonts, tags, chat, maps). Those are not Joomla cache.

If the HTML document’s TTFB is already slow, stop blaming Cassiopeia’s CSS. Work the server/PHP/SQL/extension path. If TTFB is short and a 3 MB hero PNG is 80% of the waterline, that is an image problem. Joomla Media stores illustrations under images/ (not the media/ folder used for extension JS/CSS). Docs: Managing Media.

Record three URLs: home, a heavy article, a category blog. One slow template position can hide on the home page only.

Step 2: Check whether Joomla cache is off

System → Global Configuration → System (Cache Settings):

Full page HTML is not this dropdown. That is the System – Page Cache plugin: System → Manage → Plugins, find System – Page Cache, enable it. Official Cache doc: enable it under Plugins; it keeps serving until Cache Time expires. It is the fastest layer and the least flexible. Leave it off on staging until you exclude login, cart, and forms.

Cloudflare (or another CDN) is yet another layer in front of Joomla. Cache off in Joomla plus Cloudflare “cache everything” is a freshness problem. Cache off in Joomla plus Cloudflare bypass is a speed problem. Do not mix the two diagnoses.

If System Cache is OFF and Page Cache is disabled, you have a cause. The recipe to turn them on safely is in speed up Joomla, not here. If they are ON and the site is still slow, cache was not the bottleneck. Keep going.

Step 3: Weigh images and media

Front-end slowness is often bytes, not PHP. Check:

• Full-width photos uploaded at camera resolution (several megabytes each)
• PNG used where JPEG or WebP would do for photographs
• Slideshows that load every slide up front
• Background images in the template CSS pointing at huge files
• Missing width/height causing layout delay (Core Web Vitals), which is not TTFB but feels “slow”

Joomla 4+ can resize on insert in Media, but it will not shrink files you pasted as raw URLs in a custom HTML module. Template folders after a switch can also leave you loading two image trees. Broken images are a different article: Joomla images not loading. Here the files load. They are just too big.

Do not invent a compression ratio. Look at the Network size column. If one image is larger than the HTML, CSS, and JS combined, that is the first front-end fix in the speed-up guide.

Step 4: Count the extension tax

Every enabled plugin runs on the request types it is subscribed to. Unpublished modules do not render. Disabled plugins (enabled = 0) do not run. Installed-and-forgotten enabled plugins still run. That is the usual surprise.

On staging (backup first):

1. Note the TTFB of a logged-out URL.
2. Temporarily disable non-core system and content plugins you can name (analytics duplicates, old SEF, unused security scanners, leftover editors).
3. Measure again.

If TTFB drops, you found a class of cause. Re-enable one by one. Do not disable core plugins as a bundle. Do not do this fishing trip on production.

Other extension tells:

• A template that loads many extra JS libraries on every page
• Chat, heatmap, and A/B snippets in index.php or Custom HTML
• A page builder adding a large CSS/JS payload to articles that are “just text”

Core edits to “make it faster” are how sites get stuck. Keep changes in a child template and non-core customisation.

Step 5: Ask whether hosting can run this PHP and this database

Hosting is the rest of TTFB when cache is on, images are reasonable, and plugins are few:

• PHP workers exhausted (queueing)
• Slow disk for File cache and sessions
• Database on another host with high latency
• PHP below the version Joomla recommends (old PHP can be slower and unsupported)
• Shared neighbours saturating CPU
• Geographic distance (TTFB includes network)

Joomla 5 wants PHP 8.1+ (8.3 recommended). Joomla 6 wants PHP 8.3+ (8.4 recommended). Staying on an ancient PHP “because it works” is both a security and a performance dead end. Upgrade path: Joomla upgrade.

Debug System Yes on production adds query lists and overhead to every page, public and admin. If someone left it on after a white-screen incident, turn it off. Error Reporting Maximum belongs off too.

Cloudflare can hide origin TTFB for cached HTML (you see the edge). Test with a cache bypass or Cache-Control that misses, or you will think the origin is fast when only the CDN is.

Logged-out private window. Then TTFB, cache settings, image bytes, enabled plugins, origin hosting.

After you know the cause

Open How to speed up a Joomla website and apply the matching section. Do not turn on Progressive caching and Page Cache in the same hour on production without staging. If stale HTML appears afterward, that is cache showing old content. If Clear Cache does not change files, that is cache not clearing.

Ongoing care (PHP, updates, not leaving debug on): Joomla support and maintenance.

Key takeaways

1. Split TTFB (HTML generation) from asset weight (images, JS). They are different jobs.
2. Test logged out. System – Page Cache does not serve logged-in users.
3. System Cache OFF plus Page Cache disabled is a real, common cause. Confirm it in Global Configuration and Plugins.
4. Conservative vs Progressive vs Page Cache vs Cloudflare are different layers. Only one of them may be your bottleneck.
5. Enabled plugins and bloated media dominate many “Joomla is slow” tickets. Disabled plugins are not the tax. Enabled leftovers are.
6. Hosting and PHP version set the floor. Cache cannot fix a saturated origin.
7. Use this article to name the cause. Use the speed-up guide to apply the fix.

Frequently asked questions

Why is my Joomla website slow on the front end?

Most often: large images, Joomla cache and Page Cache left off, high TTFB from PHP/SQL/extensions, or hosting. Measure TTFB and transfer size in a logged-out private window before you change settings.

Does turning on Joomla cache always make the site fast?

No. System Cache (Conservative or Progressive) caches views and modules. Whole-page speed for guests needs the System – Page Cache plugin as well, and it still will not shrink a 4 MB photo. Official Cache docs describe those as separate switches.

Should I test speed while logged into Joomla?

Not if you care about visitors. Page Cache is guest-only. Logged-in TTFB is a different number. Use a private window signed out for the public diagnosis.

Is Progressive caching faster than Conservative?

It is more aggressive on modules. It is also a common source of the wrong module on the wrong page. Start with Conservative on staging. Progressive is not the first diagnosis step.

Can Cloudflare make Joomla look fast while origin is slow?

Yes. Edge cache serves old HTML quickly. Bypass cache or check origin logs when you need the real TTFB. Cloudflare will not fix admin, and it will not fix uncached HTML generation.

Why is the site slow only on mobile?

Sometimes the same huge images. Sometimes a mobile-only script. Sometimes a host or CDN geo path. Compare the same URL’s document TTFB and image bytes on desktop vs mobile throttling. Do not assume Joomla “detects mobile” unless you enabled Platform Specific Caching.

Where do I go for the actual speed fixes?

How to speed up a Joomla website. This page is causes. That page is the how-to.

Conclusion

A slow Joomla front end is a measurement problem first. Logged-out TTFB, image bytes, cache switches, enabled plugins, then hosting. Name the layer, then apply the speed-up recipe. Do not flatten all four into “we need Redis” before you have looked at a 3 MB PNG.

When a Joomla site suddenly stops working, treat it as a last-change problem, not a mystery. A white screen, an HTTP 500, or a red system error page almost always follows a PHP version bump, a bad .htaccess rule, an extension install, or a failed update. Turn error reporting on, read the stack (or error.php), and undo that change on a backup. This is for a site that is down. If the site loads but crawls, use the slow-site diagnosis instead.

A page that used to render and now returns nothing is PHP dying before Joomla can print HTML. A 500 is the same class of failure with the web server covering the message. Joomla can also show its own error page when the CMS still boots: the system error page (red background) or the template error.php layout. Official recovery starts with Debug System and Error Reporting, then the stack. See the Joomla User Manual: Fatal errors and the Joomla 4 docs mirror J4.x:FatalError.

Do this on a backup, and test destructive checks (rename .htaccess, disable plugins in the database) on staging first when you have a copy. Production is not the place to discover that mod_rewrite was the only thing keeping URLs alive.

White screen means PHP failed with display_errors off. 500 is the server wrapping that failure. error.php means Joomla still booted far enough to render an error layout.

What you will learn

• How to tell a white screen from a 500 from a Joomla error.php page
• Why the last change (PHP, .htaccess, extension, update) is the first clue
• How to turn on Debug System when the administrator is dead
• Which PHP versions Joomla 4, 5, and 6 actually require
• How to test .htaccess without burning production
• How to disable a bad extension from #__extensions if admin will not load
• What to revert after the site is up

White screen, 500, and error.php

Joomla’s error.php is an error layout, not a debugger. Core documents it as independent of the CMS plugin chain: no <jdoc:include />, no modules. Override path: copy templates/system/error.php into the active template. Docs: Custom error pages. If a custom error.php was edited badly, it can make a recoverable error look like a total outage. Compare it to the stock file from the same Joomla package before you chase plugins.

If the public site is down but /administrator/ still loads, you still have Global Configuration. If both are down, you edit configuration.php over SFTP or the host file manager.

Step 1: Take a backup and name the last change

Before you rename files or toggle plugins, snapshot files and the database. Host backup, Akeeba, or both. Write one sentence: “The host moved us to PHP 8.3 last night,” or “We installed extension X,” or “We turned on URL rewriting,” or “We ran a Joomla update.”

Typical last changes that take a site down:

• Host PHP upgrade or a MultiPHP selector change
• Joomla or extension update
• New plugin, module, or template
• .htaccess edit (security generator, RewriteBase, custom deny rules)
• Disk full, inode limit, or a restored backup that missed configuration.php

If you cannot name a change, check the host’s PHP version history and the Joomla #__extensions enabled / install dates anyway. Hosts often bump PHP without telling you. That is still a last change.

If the site is on an old Joomla 3 stack that a host just moved to PHP 8, the fix is not a one-line patch in core. Plan a proper Joomla upgrade.

Step 2: Confirm PHP matches this Joomla version

Joomla will fatal on a PHP that is too old or on a jump your extensions never saw. Minimums below are from the Joomla project’s technical requirements (Joomla 4.x, 5.x, and 6.x tables). Recommended versions are what the project tests against.

Required PHP modules listed there include json, simplexml, dom, zlib, gd, and mysqlnd or pdo_mysql (or pdo_pgsql). Recommended memory limit is at least 256MB.

If administrator still loads: System → Information → System Information (and the PHP Information tab). If it does not: phpinfo in a throwaway file on staging, or the host’s MultiPHP / Select PHP Version screen. Then compare to the table. A Joomla 5 site on PHP 7.4 will not boot. A Joomla 4 site whose third-party plugin is not PHP 8.3-ready will white-screen after a host bump even when core is fine.

Do not “fix” a PHP mismatch by editing core files. Switch PHP on the host (or staging) to a version that matches both Joomla and the installed extensions. Then update or replace the extension.

Step 3: Turn on Debug System and Maximum error reporting

If administrator works: System → Global Configuration. System tab: Debug System = Yes. Server tab: Error Reporting = Maximum. Save. Reload the broken URL. You want a stack trace, not a prettier blank page.

If administrator is dead, edit configuration.php in the site root. Official steps:

1. If the file is 444 / read-only, set it to 644 so you can write.
2. Set $debug to true and $error_reporting to 'maximum'.
3. Save. Reload the broken URL.

That wording is from the Fatal errors manual. After you save Global Configuration later, Joomla sets configuration.php back to read-only. That is intended.

Read the first frame that is not core bootstrap. A path under plugins/, modules/, components/com_something (not com_content / com_users unless you overrode them), or a template html/ override is the usual culprit. The official advice if you can name the extension: disable it. If admin is down, in phpMyAdmin (or equivalent) open #__extensions, find that row, set enabled to 0. Do not disable core Joomla extensions as a fishing trip.

Also read the PHP error log the host provides. A fatal that happens before Joomla loads configuration.php never appears in the Joomla debug console.

When you are done, set Debug System back to No and Error Reporting back to System Default. Leaving Maximum on a public site leaks paths.

Step 4: Test .htaccess on staging, not by deleting production

Apache 500s after “Use URL Rewriting” or after a security .htaccess generator are common. Joomla ships htaccess.txt. Enabling rewriting is: rename htaccess.txt to .htaccess, then Global Configuration → Site → Use URL Rewriting. Official walkthrough: SEF URLs on Apache. If mod_rewrite is missing, turning rewriting on is a 500. If RewriteBase is wrong for a subdirectory install, same class of failure.

Do not delete .htaccess on the live site to “see what happens.” Copy the site to staging, or at minimum copy .htaccess to .htaccess.bak and keep that backup off to the side.

On staging:

1. Confirm you have the backup copy.
2. Rename .htaccess to .htaccess.bak (Apache then ignores it).
3. Reload. If the site returns (often with /index.php/ in URLs), the rules were the problem.
4. Restore stock rules from the htaccess.txt that matches this Joomla version. Do not paste a Joomla 3 file onto Joomla 5.
5. If you use a subdirectory, set RewriteBase to that folder as the SEF docs describe.
6. Only then turn Use URL Rewriting back on and retest.

Extra Deny / Rewrite blocks from security tools belong in the “last change” list. Test those on staging too. A rule that forbids a PHP file you actually need is a 500, not a permissions mystery.

nginx does not use .htaccess. If the host is nginx, a rename test proves nothing about rewrite. Use the vhost config and the host error log instead.

Step 5: Read error.php, then disable the bad extension

If you get a template-styled error page, open the active template’s error.php only to read what it prints. Compare with templates/system/error.php. You are looking for the exception message and file path, not a design tweak.

Once the stack names an extension:

• Administrator working: disable the plugin/module/component there.
• Administrator dead: #__extensions.enabled = 0 for that row.
• Override involved: a layout in templates/{template}/html/ can fatal after a Joomla update if the parent view changed. Rename the override folder on staging (do not delete until you know). Safe customisation belongs in a child template, not in core. See customize Joomla without editing core.

The User Manual also points at the Forum Post Assistant (FPA), a standalone PHP script the Joomla Forum uses. Install it only while debugging, in the site root, then remove it when you clean up. It is not a substitute for a backup.

Disk space, memory, and script timeouts are on the official cause list too. A full disk makes Joomla look “suddenly dead” after a cache or log spike. Check the host panel before you rewrite configuration.php a third time.

Order: last change, PHP version, debug/stack, .htaccess on staging, then disable the named extension.

What this article is not

This is not “why is Joomla slow.” A slow site still responds. Diagnose that in Why is my Joomla website slow and fix it with How to speed up a Joomla website. Admin-only slowness is Joomla admin dashboard is slow.

If you cannot get a stack and cannot afford more downtime, that is a restore-from-backup moment, then a staged replay of the last change. Joomla support and maintenance is the human version of that loop.

Key takeaways

1. A white screen and a 500 are usually the same PHP fatal. error.php means Joomla still booted far enough to render an error layout.
2. Name the last change first: PHP version, .htaccess, extension, or update.
3. Match PHP to the official table for Joomla 4, 5, or 6, and to your third-party extensions.
4. Enable Debug System and Maximum error reporting in Global Configuration, or set $debug and $error_reporting in configuration.php when admin is down.
5. Test .htaccess by renaming a copy on staging after a backup. Restore from this Joomla version’s htaccess.txt.
6. Disable the extension named in the stack. Use #__extensions if the administrator will not load. Do not disable core as a guess.
7. Turn debug off when you are done. Remove FPA. Put configuration.php back to how Global Configuration saves it (read-only).

Frequently asked questions

Why is my Joomla site a white screen of death?

PHP hit a fatal error and display_errors is off, so you get no HTML. Enable Debug System and Maximum error reporting, or set $debug to true and $error_reporting to 'maximum' in configuration.php, then reload and read the stack and the PHP log.

What does an HTTP 500 mean on Joomla?

The web server failed to complete the request. On Joomla that is commonly a PHP fatal, a .htaccess / rewrite problem, or a missing mod_rewrite after Use URL Rewriting was enabled. Check the server error log and the same debug steps as a white screen.

How do I enable Joomla debug if I cannot log in to administrator?

Edit configuration.php in the site root. Make it writable if it is 444, set $debug to true and $error_reporting to 'maximum', save, reload. That is the official path in the Fatal errors user manual.

Should I delete .htaccess to fix a 500?

No. Copy it to .htaccess.bak and test the rename on staging (or after a verified backup). If the site returns, replace rules from this version’s htaccess.txt and fix RewriteBase if Joomla lives in a subdirectory.

Where is Joomla error.php?

Stock file: templates/system/error.php. If the active template has its own error.php, Joomla uses that instead. It displays the error. It is not where you patch the bug. See Custom error pages.

Can a PHP version change take Joomla down overnight?

Yes. Hosts change MultiPHP without a Joomla update. Joomla 5 needs PHP 8.1 or newer. Joomla 6 needs PHP 8.3 or newer. An old plugin can still fatal on a newer PHP even when core is compatible.

Do I edit core PHP to get the site back?

No. Disable the extension, restore the backup, or roll PHP back to a compatible version. Core edits vanish on the next update or block the update. Use overrides and a child template for lasting changes.

Conclusion

A Joomla site that “just died” almost never died of boredom. It died of the last change. Backup, name that change, match PHP, turn the errors on, test .htaccess on staging, then disable what the stack names. When the page renders again, turn debug off and keep the backup until the next day behaves.

If you are still on a Joomla version the host will not run, schedule the upgrade on a clone, not as a panic edit on production.