Blog

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

Where it hurts	Typical causes	Not the first lever
Home Dashboard / every admin view	Update site pings, dashboard modules, debug, session locks, admin plugins	System – Page Cache, Cloudflare HTML cache
Public articles only	Images, cache off, TTFB, site plugins	Uninstalling administrator modules
Both	Host CPU, PHP version, Debug System Yes, disk	“Install a new admin template first”

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.

What you find	What to do
URLs for extensions you uninstalled years ago	Remove or disable those update sites
A vendor domain that times out in the browser	Disable that site. Contact the vendor or replace the extension
Dozens of sites after a “template club” history	Disable unused ones. Core Joomla update site stays
Dashboard fast after they are disabled	You confirmed the ping tax

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

Symptom	Article
Public pages take seconds, admin is fine	This checklist, then speed up Joomla
/administrator/ crawls, public site is acceptable	Joomla admin dashboard is slow
White screen, 500, or error page	Joomla website suddenly stopped working
Page loads fast but shows yesterday’s article	Joomla cache showing old content

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):

Setting	What it does on the front end
System Cache OFF	No conservative/progressive view and module cache. Every guest rebuilds those pieces.
ON – Conservative caching	Views and modules can cache. Per-module Advanced tab can set Use Global or No caching. Default path for most sites.
ON – Progressive caching	More aggressive module caching. Module “No caching” does not protect guests the way people expect. Test on staging.
Cache Handler	File (default, cache/ and administrator/cache/), or APCu / Memcached / Redis when those PHP extensions and servers exist.
Cache Time	Minutes. Default in core docs is 15.

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

What you see	What it usually means	First move
Blank white (or empty) page	PHP fatal with display_errors off. Joomla never printed output.	PHP error log, then Debug System in configuration.php
HTTP 500 from Apache or nginx	Same class of failure. The server hid the PHP message.	Same, plus the vhost / host error log
Red system error page	Serious error before the site or admin template rendered	Read the message. Enable debug if it is incomplete
Template-styled error page	Error in content code. Joomla used templates/{name}/error.php or templates/system/error.php	Read the message and stack. Do not “fix” the crash by rewriting 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.

Joomla	PHP minimum	PHP recommended (project tables)	Source
4.x	7.2.5	8.2	Hosting setup
5.x	8.1.0	8.3	Joomla 5.4 technical requirements
6.x	8.3.0	8.4	Joomla 6 technical requirements

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.

A Joomla extension is installed but not working when files exist (or a zip succeeded) and the site still has no working feature: the package is undiscovered, the row is disabled, the database schema never ran, PHP is too old or too new, a menu type was never created, or a module instance was never published. “Installed” in the installer message is not the same as enabled, assigned, and given a menu item. This is a readiness checklist, not a 500 hunt and not a two-plugin conflict hunt.

If the administrator or site is a 500, stop: find which extension causes a 500. If two enabled add-ons fight, use extension conflict. If the zip never finished, stay in System → Install → Extensions and read the installer message. This page assumes the installer said success, or you uploaded files by SFTP, and the feature is still dead.

A green install is a database row and files. The feature still needs Discover or enable, schema, PHP, a menu type, and often a module you create by hand.

What you will learn

• The difference between Upload, Discover, and Enable
• How to see the extension in System → Manage → Extensions
• When System → Maintenance → Database (Update Structure) is the real fix
• How to match PHP version to the extension’s requirements
• One check for Behaviour – Backward Compatibility on Joomla 5 (not a full compatibility essay)
• Why a component can install with no menu item type until you create one
• Why a package’s module is not on the page until you create and assign it

Official: Installing an extension, Help5.x Discover, Version update, database check.

Installed, discovered, enabled, configured

State	What is true	What you still must do
Files on disk only	You unzipped into components/ or plugins/	Discover then Install
Installer success	#__extensions row exists	Enable plugins, create menu, create module
Enabled plugin	enabled = 1	Check ordering, access, and that you enabled the right plugin in a package
Component enabled	Admin menu may show it	Create a menu item of that type for the site
Module type exists	You can pick it under New Module	New, publish, position, assignment
Schema out of date	Files newer than SQL	Maintenance → Database → Update Structure

Most “not working” tickets are the right-hand column, not a corrupt zip.

Step 1: Find the row in Manage Extensions

1. System → Manage → Extensions.
2. Search the extension name and the com_, mod_, plg_ element if you know it.
3. Confirm Status (enabled). A lock icon means protected core. Third-party rows should be enableable.
4. Open the details. Note type (component, module, plugin, package, library, file).

A package installs several rows. The component can be enabled while the plugin that injects the feature is disabled. Filter by the package name and enable every non-core row the vendor documents.

If the search is empty, the installer did not register the extension. Either the zip failed silently (host upload limit) or someone copied folders by FTP. Go to Step 2. Do not keep uploading the same zip on top without checking Discover.

Step 2: Discover is not Enable

Discover is for files already on the server that Joomla does not have in #__extensions. Official help: Extensions: Discover.

Use it when:

• The package was too large for the web uploader, so you extracted into components/com_example, administrator/components/com_example, media/com_example, and language folders as the installing guide describes.
• A deploy process copied a git checkout of an extension into those paths.

Then:

1. System → Install → Discover (some sites label this under Manage → Discover).
2. Toolbar Discover.
3. Tick the extension. Install.

Discover does not turn a disabled plugin on. It creates the row. Then you enable in Manage Extensions or Plugins.

If Discover finds nothing, the files are in the wrong tree (nested extra folder, or site files only without administrator files). Fix the paths. Do not invent a second copy under tmp/ and expect Joomla to see it.

Normal small zips should go through System → Install → Extensions (upload). Discover is the exception path.

Step 3: Enable the plugin (packages hide this)

System → Plugins. Search the vendor or feature name.

Many components ship:

• A system plugin that loads language or routing
• A content plugin that prints a button or shortcode
• An actionlog or privacy plugin you can leave off

If the system plugin is disabled, the component admin screen may open and the site view stays empty. Enable it. Then check Access on any module the package added.

Installer sample data sometimes creates an unpublished module. Published component + unpublished module = “not working” on the frontend.

Step 4: Fix the database schema

If the Home dashboard warns that the database is out of date, or the extension errors about a missing table or column:

1. System → Maintenance → Database.
2. If problems are listed, select the extension and Update Structure.

That replays skipped SQL. It is the documented fix after a partial Joomla or extension update: Version update, database check.

If Update Structure fails, the extension’s sql/updates files may not match the database engine, or a previous update died. Restore a backup and reinstall on staging. Do not create tables by hand unless the vendor gives you SQL.

A component that “installed” but never ran install.sql (Discover on incomplete files, or a failed package) will 500 or show empty lists. That can look like “not working.” Check error_log if the view fatals: 500 article.

Step 5: Match PHP version (and host extensions)

Open System → System Information (site and PHP tab). Note PHP version.

Open the extension’s documentation for minimum PHP and maximum tested. Joomla 5 itself needs a current PHP (see technical requirements for the Joomla version you run). An add-on that last shipped for PHP 7.4 will not run on PHP 8.3.

Also check System → Manage → Warnings and System Information for missing PHP modules (intl, gd, mbstring, zip). The installer may have succeeded while runtime needs curl for an API.

Host “PHP selector” can differ between the site and CLI cron. A plugin that works in admin and fails on cron is often two PHP versions.

Step 6: One Joomla 5 compatibility plugin check

On Joomla 5, core ships Behaviour – Backward Compatibility (plg_behaviour_compat). It loads Joomla 4 class aliases so older extensions can run. Official note: Compatibility plugin.

Check, do not redesign your stack around it:

• System → Plugins, search Backward Compatibility or compat.
• If a Joomla 4-era extension is installed and this plugin is disabled, enable it on a staging copy first and test. The Joomla docs warn that disabling it on production can fatal old extensions, and that you may need the database to turn it back on.
• If you are preparing Joomla 6, this plugin must be disabled before that upgrade, and you need extensions that do not rely on it. That is an upgrade project, not this article.

This is one checkbox in the “installed but dead” list. It is not a substitute for a vendor’s Joomla 5 build. Prefer an updated extension. Do not treat the compat plugin as a permanent architecture.

Joomla 5.4 also installs Behaviour – Backward Compatibility 6 for the later jump. Do not disable that in a way the Joomla 6 migration guide forbids. Read Compatibility plugins (5.4 to 6) when you upgrade. For “not working today on Joomla 5,” the plg_behaviour_compat enable check is enough.

Step 7: Create the menu item (missing menu type)

A component can install a menu item type (Articles → Archived Articles is the core example). Your add-on is the same. Until you create Menus → your menu → New and select that type, the site has no URL.

Symptoms:

• Administrator component works. Frontend 404 or Home never changes.
• You look for a module. The feature is a component view, not a module.
• The type is missing from the New Menu Item list: the component is disabled, Discover never ran, or the XML submenu / menu section failed. Reinstall or Discover. Confirm the component is enabled in Manage Extensions.

Create the menu item, set Access, set a template style if needed, save. Open that URL. Do not expect the installer to inject a menu item on a production menu. Many packages do not.

If the type appears but the view is empty, you may still need to create records inside the component (a first category, a first item). That is configuration, not a failed install.

Step 8: Create and publish the module

System → Site Modules → New. If the module type is in the list, the module type is installed. A type in the list is not an instance on the page.

Packages often do not create a published module. You must:

1. New → pick the type.
2. Set Position to a name the template actually prints (position not showing if the slot is empty everywhere).
3. Menu Assignment (wrong pages if it appears in the wrong place).
4. Publish. Public access. Language All or the right language.

If the type is not in New Module, the module file never installed (package incomplete, or you only installed the component zip). Install the full package. Discover if you dropped modules/mod_example by hand.

Editor buttons (editors-xtd) are plugins, not modules. Enable them under Plugins. They will not appear as Site Modules.

Language, ACL, and cache (short)

• Install the extension’s language pack if the vendor ships one, or you will see KEY_NAMES as titles. For core string tweaks, language overrides.
• Super User sees a module a Guest does not: Access.
• Clear cache after enable. Page cache can hide a module you just published.

Custom fields inside an extension are not core article fields. Core article fields have their own empty-frontend guide: custom fields not showing.

Warnings, update sites, and a second install attempt

System → Manage → Warnings (or Installer warnings) lists environment problems Joomla already detected: PHP version, missing modules, memory. If a warning names the same constraint the vendor lists, fix the host before you reinstall the zip. Reinstalling will not add intl.

System → Update → Update Sites (or Manage → Update Sites): if the extension installed from a URL and later “does nothing” after you expected a patch, Rebuild the update sites, then System → Update → Extensions. An old build that “installed fine” on Joomla 5 can still be a Joomla 4 package. The update site is how you learn a Joomla 5 zip exists.

If you install twice, Joomla may refuse or may leave the first schema in place. Prefer Uninstall (after a backup) then install the matching Joomla 5 package, over copying folders on top of a half Discover. Uninstall removes #__extensions rows. It can drop the extension’s tables. That is why the backup exists.

A library or file package can install with no admin menu. The feature then lives inside another component. Read the vendor’s “where to click after install” once. Searching Site Modules for a library is a dead end.

Files and a green installer are the start. Enable, schema, PHP, menu type, and a published module instance are the rest.

Key takeaways

1. Installer success means a registry row. It does not mean enabled, schema-current, or on a menu.
2. Discover registers FTP-copied files. Enable turns plugins on. They are different buttons.
3. Packages hide a disabled system plugin. Search Plugins after every component install.
4. Maintenance → Database → Update Structure when files and SQL diverged.
5. Check PHP version and System Information warnings before you blame Joomla.
6. On Joomla 5, confirm Behaviour – Backward Compatibility if the add-on is old. Prefer a native Joomla 5 build. This is one check, not a strategy.
7. Components need a menu item type you create. Modules need a New instance, position, and assignment.
8. If it 500s, leave this checklist and read the log. If it works alone and fails with a neighbour, that is a conflict.

When a vendor package is registered but the live site still has no menu, no module, and no plugin enabled, a maintainer can finish the wiring: Joomla support and maintenance.

Frequently asked questions

Why is my Joomla extension installed but not working?

The zip registered files, but a plugin is still disabled, Discover was skipped after an FTP copy, the schema is behind, PHP does not match, or you never created a menu item or module instance.

What is the difference between Discover and Enable?

Discover finds manifests on disk and creates #__extensions rows (then you click Install on that screen). Enable turns an existing row on. Uploading a zip uses Install Extensions, not Discover.

Do I always get a module on the page after install?

No. You often get a module type. You still click Site Modules → New, publish it, and assign a position and pages.

Why is there no menu item type for my component?

The component is disabled, not fully discovered, or you are looking at the wrong client (site vs administrator). Enable the component, run Discover if files were copied, reinstall the package, then Menus → New.

Should I disable the Joomla 5 compatibility plugin to test?

Only on staging, and only if you can re-enable it in the database when admin dies. For an old extension that is “not working,” try enabling the plugin first. Plan a real Joomla 5 build before Joomla 6.

Update Structure did nothing. Now what?

Confirm you selected the extension that listed errors. If SQL still fails, restore a backup and reinstall on staging. Do not drop random tables on production.

Could this be a template problem?

Yes, if it is a module in a position the template does not print, or an override that errors. Check position names and child-template overrides after the extension is enabled and assigned.

Last updated Oct 21, 2026. We will update this guide as hosts and Linux vendors ship fixed packages.

Short answer: PHP2Shell is the name for two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS v4.0 9.2 and can let an attacker run code on your server without logging in. The only complete fix is to run PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or newer, released on 21 October 2026 (php.net advisory). Nothing in Joomla or WordPress fixes it, and no plugin or extension does either. If your site runs PHP 8.1 or older, there is no official fixed release: you need to move to PHP 8.3 or later, or get a patched package from your Linux vendor.

The fix in five steps: 1) find the PHP version your site actually serves, 2) get it onto a fixed build, 3) confirm the fix is really running, 4) add the interim hardening if you are still waiting, 5) plan an exit if your host will not move. Each step has its own section below, with steps for cPanel, Plesk, CloudLinux, VPS servers, Joomla 4, 5 and 6.2, and WordPress.

What is PHP2Shell, in plain English?

PHP is the engine that runs Joomla and WordPress. Every page of your site, from the home page to the admin login, is built by PHP on your web server. PHP is installed by your hosting company, not by you and not by your CMS.

PHP2Shell is a fault in that engine. A stranger can send your server one specially crafted web request, just like a normal visit but built to trigger the fault. The server can then run the stranger’s commands. No password is needed and no account is needed.

Because the fault sits in PHP, it hits before Joomla or WordPress even starts. Your admin password, two-factor login, security plugin or Joomla access rules never get a say. php.net confirms there is a working attack that triggers before any application code runs on the most common Apache setup.

An analogy: your Joomla or WordPress security is the lock on your apartment door. PHP2Shell is a broken lock on the building’s front door, and it opens the service corridor behind every apartment. A better apartment lock does not help. The building manager, your host, has to replace the front-door lock, which here means installing the fixed PHP release.

What can happen to your site if you ignore it?

Running commands on your server means an attacker can do roughly what your site itself can do. These are the usual results of that kind of access on any hacked site, not specific reported PHP2Shell cases:

• Defacement. Your pages are replaced or altered with the attacker’s content.
• Hidden malware or spam. Code is slipped into your files or database that redirects visitors, shows spam links or infects visitors’ browsers.
• Stolen data. The site can read its own database, so customer details, orders, contact form submissions and user accounts can be copied.
• Your server attacks others. The site is used to send spam email, host phishing pages or attack other websites, often without you noticing.
• Google warnings and lost rankings. Google may label the site This site may be hacked in search results or show a red browser warning, and visitors and rankings drop while that lasts. See Google’s Security Issues report help.
• Hosting suspension. Hosts commonly suspend accounts that send spam or host malware, which takes the whole site offline.
• Cleanup cost and downtime. Removing malware, restoring backups, resetting every password and asking Google for a review takes time and money, and data that was stolen cannot be taken back.

If you sell online, handle bookings or collect personal data, a breach can also bring legal duties to report it to customers or regulators, depending on where you and they are.

Which PHP versions are safe, and which are not?

Check the first two numbers of your PHP version (the branch), then the last number (the patch level). Versions are from the PHP 8 changelog, the CERT-FR alert and NVD; support dates are from php.net’s supported versions and end-of-life pages.

Your PHP branch	Vulnerable	Fixed in	Branch support (php.net)	What you do
8.5	8.5.11 and below	8.5.12	Active support to 31 Dec 2027	Update to 8.5.12
8.4	8.4.26 and below	8.4.27	Active support to 31 Dec 2026, security to 31 Dec 2028	Update to 8.4.27
8.3	8.3.35 and below	8.3.36	Security fixes only, to 31 Dec 2027	Update to 8.3.36
8.2	8.2.34 and below	8.2.35	Security fixes only, ends 31 Dec 2026	Update to 8.2.35, then plan 8.3+
8.1	All	No official release	End of life since 31 Dec 2025	Move to 8.3+ or use a vendor backport
8.0, 7.x, 5.x	All	No official release	End of life	Move to a supported branch
8.6 release candidates	Not covered by the fixed releases	None yet	Testing only, not for production	Do not run in production

The PHP team also published minimal source-only patches for 7.4, 8.0 and 8.1 for people who compile PHP themselves. They are not releases, and a shared hosting panel cannot offer them.

Still on Joomla 3? Why patching PHP is not an option

This is the hardest case, and it is worth being precise about. Joomla’s official technical requirements list PHP 8.0 as the recommended version for Joomla 3.x, and no newer PHP version is listed. Joomla 3 support ended on 17 August 2023, and the extended LTS version ended on 17 February 2025, so Joomla 3 gets no more updates to make it work on newer PHP. Joomla volunteers on the official Joomla forum report that 3.10 does not work on PHP 8.2 or later and is unreliable on 8.1. Every branch that received the PHP2Shell fix is 8.2 or newer. Put those facts together and no officially supported Joomla 3 setup can run a patched PHP release.

What about the stopgaps? Each one helps a little and costs something:

Option	What it gets you	Where it falls short
Source-only backports for 7.4, 8.0, 8.1	The PHP2Shell fix for people who compile PHP themselves	No releases and no binaries. Shared, reseller and most managed hosts cannot install them, and you take on maintaining a custom PHP build.
Vendor or distribution backport (for example a Linux LTS package)	A patched PHP 8.0 or 8.1 from a vendor	Only on servers you or your host control at the OS level, often paid, and only covers PHP. Joomla 3 itself still gets no security fixes.
Interim php.ini settings and a WAF	Fewer known attack paths	php.net says they do not make an installation safe, and WAF rules can be bypassed by direct-to-origin traffic.
Forcing Joomla 3 onto PHP 8.2+	A patched PHP	Unsupported: expect white pages, 500 errors and broken extensions, which is why hosts that move clients forward often break Joomla 3 sites.

So the risk of staying is not only PHP2Shell. It is that every future PHP or Joomla vulnerability lands on a site with no supported fix. The lasting fix is to move the site to Joomla 6.2, which requires PHP 8.3 or newer, so it runs on a branch that gets security releases until at least the end of 2027. Joomla does not allow skipping straight from 3 to 6: the path is 3.10 → 4.4 → 5.x → 6.x, and our Joomla 3 to 6 upgrade guide walks through each hop. Run the free Joomla 6 compatibility check first to see which extensions have Joomla 6 versions and which need replacing; that list is what decides how long the move takes. If you would rather have the migration done for you, that is what our Joomla upgrade service covers.

Old WordPress on PHP 7.4 or 8.1? WordPress is gentler: current WordPress still runs on PHP 7.4 but recommends 8.3 or greater. Update WordPress core, plugins and themes first, then switch the branch as in Step 2b. Plugins abandoned by their authors are the usual blocker, so replace them before the switch.

How do the two flaws work?

Both flaws are about what PHP leaves behind when a web request ends badly. According to the NVD descriptions supplied by the PHP security team:

• CVE-2026-109618: when PHP runs out of memory mid-request, some internal request memory can be left uninitialised. The cleanup step then reads it as if it were valid, and several out-of-memory tricks can turn that into remote code execution.
• CVE-2026-109619: some global state can keep pointing at request memory after it has been freed. A later request on the same PHP worker can read that stale state before it is reset, which can also lead to remote code execution.

php.net says the risk covers all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and is highest for mod_php, where a demonstrated exploit runs before any application code. For a Joomla or WordPress site this means your login page, security extension and file permissions are not in the way: the attack happens one layer below the CMS.

Fact	Detail	Source
CVSS v4.0 score	9.2 for both CVEs (vector AV:N/AC:H/AT:P/PR:N/UI:N)	NVD
Advance notice	20 Oct 2026, release set for 21 Oct 14:00 UTC (7:30 PM IST)	php.net
Fixed releases	8.5.12, 8.4.27, 8.3.36, 8.2.35 on 21 Oct 2026	php.net
Changelog entry	“Fixed GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp (Avoid state corruption via bailout)” in all four branches	PHP changelog
NVD publication	21 Oct 2026, 14:17 UTC (7:47 PM IST), status “Received”	NVD
CISA assessment	On 21 Oct, CISA’s SSVC entry on NVD rated exploitation as “none” and technical impact as “total”; NVD status is still “Received” (not yet analysed)	NVD
Attack traffic	Cloudflare says it observed attack traffic after the CVE details leaked	Cloudflare

Step 1: How do I check which PHP version my site really runs?

Check the version the web server uses for your site. The command-line php -v on the same server can be a different build, so do not rely on it alone.

In Joomla 4, 5 or 6.2

Log in to the Administrator, open System → System Information, and read PHP Version on the System Information tab. The PHP Information tab shows the full phpinfo output, including the Server API line (for example FPM/FastCGI or Apache 2.0 Handler), which tells you whether you are on the higher-risk mod_php.

In WordPress

Go to Tools → Site Health → Info and expand Server. The PHP version and Server API rows are listed there (WordPress Site Health docs).

With no admin access

Upload a one-line file, open it in the browser, note the version, and delete it immediately, because phpinfo output helps attackers:

<?php echo PHP_VERSION, " ", PHP_SAPI;

Name it something random (not info.php). It prints the exact version and the server API, for example 8.3.36 fpm-fcgi. PHP manual: phpversion()

Checking many sites

Repeat the same check per site, because one hosting account can run different PHP branches per domain. Record domain, branch, patch level and Server API in a sheet, and sort by the table above.

Step 2: How do I update PHP to a fixed version?

Two different things are called “updating PHP”. A patch update (8.3.35 to 8.3.36) is a drop-in security fix that your host installs on the server. A branch change (8.1 to 8.3) is something you usually select yourself and must test, because extensions and plugins can break. PHP2Shell needs the patch update everywhere, and a branch change if you are on 8.1 or older.

cPanel (shared hosting)

1. Open Software → MultiPHP Manager (cPanel docs), or Select PHP Version on CloudLinux servers.
2. Check which branch your domain uses. The selector picks a branch; the patch level inside it is whatever the host has installed.
3. If you are on 8.1 or older, take a backup, then pick 8.3 or newer and test the site (see Step 2b).
4. Run the Step 1 check again. If the patch level is still below the fixed build, open a ticket (template in Step 5).

Server admins with WHM install the fixed EasyApache 4 packages through the normal system update and manage versions in MultiPHP Manager for WHM.

Plesk

In Plesk, open the domain, then PHP (PHP Settings), and choose the PHP version. Plesk’s own advisory (updated 21 Oct 2026, 15:13 UTC / 8:43 PM IST) lists the state of its PHP builds:

Plesk PHP	Linux	Windows
8.2	Fixed in 8.2.35	In development
8.3	Fixed in 8.3.36	In development
8.4	Fixed in 8.4.27	In development
8.5	Fixed in 8.5.12	In development
7.4, 8.0, 8.1	In development	In development

To see which builds a Plesk server has, go to Tools & Settings → PHP Settings; the version is part of each handler name. On Linux over SSH, /opt/plesk/php/8.3/bin/php -v shows it (swap 8.3 for your branch).

Plesk also lists its own panel engine (sw-engine) as affected on all versions, with hotfixes planned as 18.0.80#11 and 18.0.81#4. If you run Plesk on Windows, use the interim hardening in Step 4 until the builds ship, and keep checking Plesk’s advisory.

CloudLinux, LiteSpeed and other managed hosts

On CloudLinux, the per-site PHP selector uses CloudLinux’s own alt-php builds, so the patch arrives when CloudLinux ships it and your host installs it. LiteSpeed is named in php.net’s list of affected setups. On managed WordPress and Joomla hosts with no PHP setting, the host alone controls the patch: ask for the exact version and date (Step 5).

Your own VPS or dedicated server

• Distribution packages (Ubuntu, Debian, RHEL and clones): install the vendor security update with your normal package manager. Distributions often backport security fixes without changing the upstream version number, so confirm with the vendor’s security notice for these CVE IDs, not by version string alone.
• Third-party repositories or source builds: upgrade to the fixed upstream release from php.net downloads or your repository once it publishes the build.
• Docker images: pull an image built on the fixed release, rebuild, and redeploy every container; a running container never patches itself.
• Then restart PHP (Step 3). Without a restart the old code keeps serving requests.

Step 2b: Moving off PHP 8.1 or older without breaking the site

CMS version	PHP minimum	PHP recommended	Can it reach a fixed branch?
Joomla 6.x (incl. 6.2)	8.3.0	8.4	Yes, every supported setup is 8.3+ (Joomla docs)
Joomla 5.x	8.1.0	8.3	Yes, move to 8.3 (Joomla docs)
Joomla 4.x	7.2.5	8.2	Yes on 8.2, but upgrade Joomla too (Joomla docs)
Joomla 3.x	5.3.10	8.0 (highest listed)	No; see the Joomla 3 section below (Joomla docs)
WordPress (current)	7.4 (legacy)	8.3 or greater	Yes (WordPress requirements)

1. Back up files and database first (how to back up Joomla).
2. Update the CMS core, then every extension, plugin and theme, on the old PHP version.
3. For Joomla, scan extensions for compatibility with our free Joomla 6 compatibility check.
4. Switch the branch on a staging copy if you have one, or during a quiet hour on live.
5. Test front end, forms, checkout, login and admin. If you get a white page or 500 error, switch back and use this guide to find the failing extension.
6. Still on Joomla 3? PHP cannot move until Joomla does; see the Joomla 3 section.

Step 3: How do I confirm the patch is actually live?

1. Repeat the Step 1 check through the website (Joomla System Information, WordPress Site Health or the one-line file). The version must be 8.2.35, 8.3.36, 8.4.27, 8.5.12 or higher, or a vendor package your vendor confirms fixes both CVEs.
2. On a server, restart every PHP process: restart PHP-FPM pools, and for mod_php restart Apache fully. php.net’s advisory tells admins to restart every worker for settings to apply; the same applies to new binaries.
3. Check that no process still uses the old library. On Linux this should print nothing:

grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps 2>/dev/null

Then check every site on the account, not just the main one; add-on domains can run different branches.

Step 4: What can I do while I wait for my host?

php.net lists interim measures that reduce exposure to specific attack paths but, in its words, do not make an installation safe. They must be set in php.ini, the PHP-FPM pool or the web server config, which apply before the request is parsed. php.net says not to rely on ini_set() or FPM .user.ini.

Setting	Targets	Notes from php.net
session.upload_progress.enabled=0	CVE-2026-109619	Blocks the confirmed session paths, not other variants. Neither Joomla nor WordPress core needs it.
fatal_error_backtraces=0 (PHP 8.5 only)	CVE-2026-109619	Blocks the confirmed fatal backtrace path only.
memory_limit=-1 set with php_admin_value	CVE-2026-109618	Removes the controllable memory-limit failure; use a container or cgroup limit instead, not RLIMIT_AS or RLIMIT_DATA.
post_max_size = 8M (no uploads) or 32M (uploads), upload_max_filesize lower	CVE-2026-109618	Also cap request size, field count, multipart parts, headers and nesting at the web server or proxy.
Remove invalid or deprecated per-request settings (for example in .htaccess)	CVE-2026-109619	Hiding errors with display_errors or error_reporting does not help.

A Joomla site with large media uploads or a WordPress shop importing big CSV files may need the 32M limit. Our Joomla .htaccess guide shows where per-directory PHP settings live, so you can find and remove deprecated php_value lines.

Does Cloudflare or a WAF protect me?

Partly. Cloudflare says customers using its free or paid WAF have been protected by default against known PHP2Shell attacks since 21 Oct 2026, 03:02 UTC (8:32 AM IST), and still tells customers to patch PHP (Cloudflare blog). A WAF only helps if attackers cannot reach your server directly by IP, so restrict the origin to Cloudflare’s IP ranges. Treat any WAF rule as a stopgap.

Step 5: What if my host will not update PHP?

Send a short ticket that leaves no room for a vague answer:

Subject: PHP2Shell (CVE-2026-109618 / CVE-2026-109619) patch date

Hi, my site [domain] runs PHP [version]. PHP released 8.2.35, 8.3.36,
8.4.27 and 8.5.12 on 21 October 2026 to fix two unauthenticated remote
code execution flaws (https://www.php.net/). Please confirm:
1. the date the fixed build will be installed for my account, and
2. if you use vendor-backported packages, the package version that
   includes both fixes.
If my branch (8.1 or older) will not be patched, which supported
branch can I switch to today?
Thanks.

If the host cannot give a date, or only offers PHP 8.1 or older, that is a reason to move. Until then, put the site behind a WAF with the origin locked down, apply what Step 4 allows on your plan, and keep fresh offsite backups. CERT-FR’s advice for unsupported versions is to isolate affected systems and migrate to a maintained version (CERT-FR), and BleepingComputer reports that the UK NCSC told organisations to update or take systems offline until patched (BleepingComputer).

Step 6: How do I know if my site was already attacked?

The flaws allow code execution as the web server user, so look for what an attacker would leave behind:

• New or changed PHP files in upload, cache, images or tmp folders, especially since 20 Oct 2026.
• Unknown administrator or Super User accounts.
• Unusual POST requests, very large multipart uploads, or bursts of 500 errors in the access and error logs around 20 and 21 October.
• Unexpected cron jobs, outbound connections or spam sent from the server.

If you find any of these, patching alone is not enough. Follow our hacked Joomla incident-response guide or our WordPress malware removal service, and rotate database, FTP, admin and API passwords afterwards. For ongoing hardening see the Joomla security guide.

PHP2Shell checklist

Done?	Task
☐	Recorded PHP version and Server API for every site
☐	Every site on 8.2.35, 8.3.36, 8.4.27, 8.5.12 or a vendor-confirmed backport
☐	PHP-FPM / Apache restarted, no deleted libraries in use
☐	Sites on 8.1 or older scheduled for a branch change
☐	Interim settings applied where still unpatched
☐	Logs and files checked for signs of compromise
☐	Host ticket answered with a patch date

The short version

Find the PHP version every site really serves, get it onto 8.2.35, 8.3.36, 8.4.27 or 8.5.12, restart PHP and check again. Use the interim settings only while you wait, and chase your host for a date. If a site is on Joomla 3 or PHP 8.1 and older, the patch you need is a version upgrade, and the sooner it is planned the less any future PHP flaw matters. If you want a second pair of hands, Infyways has worked on Joomla sites since 2010 and replies to enquiries within 12 hours; you can reach us here.

Frequently asked questions

What does PHP2Shell mean for a non-technical site owner?

PHP, the engine that runs Joomla and WordPress, has a fault that lets a stranger run commands on your server without logging in. Ask your host to confirm your site runs PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer.

Can I patch PHP2Shell on a Joomla 3 site?

Not on a supported setup. Every fixed PHP release is 8.2 or newer, and Joomla 3.10 does not run on PHP 8.2+. Vendor backports and php.ini settings reduce risk only partly, so the lasting fix is upgrading to Joomla 6.2 via 4.4 and 5.x.

What is PHP2Shell?

PHP2Shell is the name for CVE-2026-109618 and CVE-2026-109619, two critical flaws in the PHP runtime rated CVSS v4.0 9.2. They can allow unauthenticated remote code execution on servers that serve web requests with PHP.

Which PHP versions fix PHP2Shell?

PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, released on 21 October 2026. PHP 8.1 and older get no official release.

Do I need to update Joomla or WordPress?

No CMS update fixes PHP2Shell, because the flaw is in PHP. Keep the CMS updated anyway, especially if you need to move to a newer PHP branch.

Will a security plugin or extension protect my site?

No. php.net describes a demonstrated exploit that triggers before any application code runs, so CMS security plugins and extensions never see it.

Is PHP 8.1 safe if my host says it is patched?

Only if the host uses a vendor package that backports both fixes, and can name it. The PHP project itself published no fixed 8.1 release.

Which PHP version should a Joomla 6.2 site use?

Joomla 6 requires PHP 8.3 and recommends 8.4. Use 8.4.27 or 8.3.36 or newer.

Which PHP version should WordPress use?

WordPress recommends PHP 8.3 or greater. On 8.3, use 8.3.36 or newer.

Can I set the PHP2Shell mitigations in .user.ini?

No. php.net says not to rely on ini_set() or FPM .user.ini; use php.ini, the FPM pool or server configuration, then restart every worker.

Is Cloudflare enough to protect my site?

No. Cloudflare deployed WAF rules on all plans but still tells customers to patch, and a WAF does nothing for traffic sent straight to your server IP.

A Joomla 500 error means PHP or the web server aborted the request. The extension name is in the log, not in the generic “Whoops” page. Read error_log (and Joomla’s log folder), turn Debug on from Global Configuration or configuration.php, then isolate the last update. On a staging copy only, you can temporarily rename a plugin folder to prove the group. Never delete production files without a backup, and never “clean up” live plugins to find a 500.

The browser message is empty on purpose. Production hides fatals. Your job is to make the fatal visible in a log, then disable one extension, not the whole site.

The HTML is a dead end. The PHP error log is the map. The path under plugins, modules, or components is the extension.

What you will learn

• Where hosts put error_log and where Joomla writes administrator/logs
• How to enable Debug and Maximum error reporting when the admin still opens
• How to set $debug and $error_reporting in configuration.php when admin does not
• Why the last update is the first extension to disable
• How to rename a plugins folder on staging only as a group test
• How to disable one row in #__extensions without deleting files
• What not to do on production

Official: Fatal error (Joomla User Manual). If the site runs but two add-ons fight, use Joomla extension conflict instead of this 500 path.

500 vs white screen vs “Whoops”

Joomla 4 and 5 often show a page titled like Whoops, looks like something went wrong with an HTTP 500 status. That is still a server 500. A white screen is the same class of failure with display_errors off.

Source	What it is good for
PHP error_log (host panel, or a file in the account)	Fatals that happen before Joomla’s pretty error page
Web server error log (Apache/nginx)	.htaccess, PHP-FPM socket, permissions
administrator/logs/ (or the path in Global Configuration)	Joomla Log::add and some extension logs, not every fatal
Debug System + Error Reporting Maximum	Stack trace after Joomla has bootstrapped
Browser Network tab	Confirms 500 vs 403 vs timeout. Does not name the PHP file

If the log line is .htaccess or mod_security, you may not have an extension problem. Fix the server rule, then come back if PHP still fatals.

Step 1: Copy the site, then backup production anyway

Before any rename, disable, or configuration.php edit on a live site:

1. Snapshot or copy files and the database (host backup, or your own). If you cannot restore, do not experiment on production.
2. Prefer a staging URL with the same Joomla and PHP versions. Do the hunt there. Deploy the known-good disable back to production.
3. Tell the team the site may be briefly noisy if you enable Maximum error reporting on production.

Do not delete the plugins directory on production “to see what happens.” You will take down authentication, two-factor, and SEF. You may not get admin back without a restore.

If you need someone else to hold the copy and the log hunt: Joomla support and maintenance.

Step 2: Read error_log before you click around

Ask the host where PHP logs. Common places:

• cPanel Errors or Metrics → Errors
• Plesk PHP log
• A file named error_log in public_html or in the account home
• ~/logs/error.log on some VPS stacks

Open the log at the timestamp of your test request. One line of PHP Fatal error is worth an hour of plugin guessing.

Copy:

• The exception class (Error, TypeError, ParseError)
• The file path and line
• The first few frames of the stack if present

Map the path:

• plugins/system/example/ → System plugin “example”
• plugins/content/example/ → Content plugin
• modules/mod_example/ → that module (unpublish it in Site Modules once admin works)
• components/com_example/ → that component
• templates/cassiopeia/ or a child → template PHP, often an override. See customize without editing core after the site is up.
• libraries/ → core or a library package. Do not delete libraries. Restore a backup or revert the last Joomla update.

Joomla also logs under Global Configuration → System → Path to Log Folder (default administrator/logs). Check everything.php or dated files if the host PHP log is empty. Many fatals never reach Joomla’s logger because PHP died first. That is why error_log is step 2, not step 5.

Step 3: Debug from Global Configuration, or from configuration.php

If administrator still loads:

1. System → Global Configuration.
2. System tab: Debug System = Yes.
3. Server tab: Error Reporting = Maximum.
4. Save. Reload the failing site URL once (and the admin URL if that is what 500s).
5. Read the on-screen file and line. Then set Debug = No and Error Reporting = System Default. Save.

The Debug console is configured by System – Debug. Allowed Groups can hide the console from guests. You still want Maximum reporting for the fatal text.

If administrator is a 500 too, do not keep hitting login. Use FTP or the host file manager:

1. Download configuration.php. Keep a copy.
2. If the file is 444, set it to 644 long enough to edit (the manual describes this).
3. Set public $debug = true;
4. Set public $error_reporting = 'maximum';
5. Save. Reload once.
6. Put $debug back to false and $error_reporting back to 'default' or 'none' (match what you had) as soon as you have the path. Leaving Maximum on production leaks paths to visitors.

Official steps: Fatal error.

Optional: rename the template’s error.php on staging if that file is itself fataling and hiding the real message. Do that only on the copy.

Step 4: Disable the last update first

System → Update → Extensions (if admin works) or your change log:

• Last extension update
• Last Joomla update
• Last PHP version change on the host (this 500s old extensions without a zip install)

Disable in this order once you have a path, or if the log is empty but the clock matches an update:

1. The extension named in the log.
2. If the log names a plugin, disable that plugin in System → Plugins (or #__extensions below).
3. If admin is down, you cannot click Plugins. Use the database: table #__extensions (your prefix), find element matching the plugin name, set enabled to 0. The user manual describes this for a faulty extension. Do not set core rows to 0 unless you know the row.
4. If the last change was a component update, disable its plugins first (packages register several rows). Then take the component off the default menu item so it is not the Home view.

Clear cache files on disk if page cache is on (cache/ folder) after a disable. A cached 500 is rare. A cached blank HTML is less rare. Still worth deleting cache/ on staging.

Step 5: Staging only, rename a plugins folder to test a group

This is a group proof, not a production technique.

On staging:

1. Confirm you can restore (snapshot, or a zip of plugins/ you just made).
2. Rename one third-party plugin directory, for example plugins/system/suspect → plugins/system/suspect.off. Joomla will skip that folder. Core plugins stay.
3. Reload. If the 500 is gone, that folder was in the path (or something it triggered was).
4. Rename it back. Disable the plugin properly in the database or UI so the site does not fatal on the next page that autoloads it in a different way.

You can rename a group folder on staging in an emergency, for example plugins/system → plugins/system.off, to see whether any system plugin is involved. That will break a lot of features. It is a binary test on a copy, then you put the folder name back immediately and disable one plugin at a time.

Do not do this on production. Do not delete the folder. Do not rename plugins as a whole on a live shop. You will remove authentication plugins and lock everyone out. If you already did that on production, restore the backup from Step 1. Do not invent a “fix” by uploading empty directories.

If you need a batch disable with the UI still up, that is the conflict article’s plugin batches, not a filesystem delete.

Step 6: Database disable when the UI is dead

phpMyAdmin or an SQL client, on a backup first:

• Table: {prefix}_extensions
• Find the row: type = plugin, element = the plugin name, folder = system/content/…
• Set enabled = 0

For a module, you can also unpublish in {prefix}_modules (published = 0) if the log named mod_….

For a component Home page that 500s, change the default menu item in {prefix}_menu to a core featured or article view, or disable the component’s plugins, rather than DROP TABLE. Deleting tables is how you turn a 500 into a restore.

When admin returns, uninstall or roll back the extension with System → Manage → Extensions if you are done with it. Uninstall is not the same as deleting folders by hand. The installer cleans #__extensions rows.

Memory, timeouts, and logs that name PHP, not an extension

Some 500s never mention plugins/. They still belong to an extension.

• Allowed memory size exhausted at a line in plugins/system/example/ is that plugin (or a loop it triggered). Raise memory_limit only on staging to confirm. On production, fix the plugin or the data set it loads (a module that queries every article is a typical case).
• Maximum execution time exceeded in a component view is that component, or a plugin that runs on that view. Do not raise max_execution_time as the only fix.
• PHP Parse error in an override under templates/…/html/ is your copy, not the vendor zip. Restore the core layout on staging, then repair the override in a child.

.htaccess 500s often follow a security plugin that wrote rewrite rules, or a hand edit after an extension installer. On staging, temporarily rename .htaccess to .htaccess.bak and use Joomla’s default htaccess.txt copied to .htaccess. If the 500 vanishes, the rules were the problem. Put your custom rules back one block at a time. Do that on production only after a backup, and only if you can restore via the host panel when you lock yourself out.

Gzip in Global Configuration plus Maximum error reporting can produce odd output on some hosts. If Debug shows a fatal and the browser still shows a generic 500, disable Gzip for the test. Turn it back on later.

After the site loads, close the hole

1. Set $debug false and error reporting off/default.
2. Set Preview and Debug plugins back to normal groups.
3. Update or replace the extension. If it needs old class names on Joomla 5, that is a compatibility check on the installed but not working article, not a reason to leave Debug on.
4. If a plugin tmpl was the fatal (parse error in an override), fix the override in a child. Plugin override.
5. Write the extension name and version in your runbook so the next 500 is shorter.

Log first. Last update second. Rename plugin folders only on staging. Never delete live files to “test.”

Key takeaways

1. A Joomla 500 is a server abort. The extension is named in error_log (or a Debug stack), not in the Whoops HTML.
2. Copy the site or take a full backup before you change configuration.php or plugin folders on anything you care about.
3. Enable Debug and Maximum error reporting only for the reproduce, then turn them off.
4. Disable the last updated extension first when the clock matches and the log agrees.
5. Rename plugin folders only on staging, as a temporary proof. Put the names back. Disable via Plugins or #__extensions.
6. Never delete production plugins/, components/, or libraries/ to debug. Restore from backup if you already did.
7. Database enabled = 0 on one extension row is the safe UI-down move. Dropping tables is not.
8. When two extensions work alone and 500 together, finish recovery then use the conflict process.

Frequently asked questions

How do I find which Joomla extension is causing a 500 error?

Read the PHP error_log at the request time. The file path under plugins/, modules/, or components/ is the extension. Enable Debug if Joomla still bootstraps. Then disable that extension, starting with the last update if the log is empty.

Can I rename the plugins folder on the live site?

No. Use staging. On production, take a backup and disable one #__extensions row, or restore. Renaming plugins on live removes authentication and can lock out admin.

Admin is a 500. How do I turn on debug?

Edit configuration.php: $debug = true and $error_reporting = 'maximum'. Reload once, copy the error, then turn both back off. The user manual documents the permission change if the file is read-only.

The error_log is empty. What next?

Check the web server log, Joomla’s log path, and whether you are looking at the right vhost. Enable Maximum reporting on staging. If PHP dies before logging, ask the host for the FPM log.

Should I delete the extension files to stop the 500?

No. Disable it. Deleting files on production without a backup is how you lose the only copy of a paid extension and still leave broken #__extensions rows. Restore, then uninstall from the administrator when it loads.

Could PHP be the “extension”?

A host PHP upgrade can fatal old extensions. The log still names the extension file. The fix is an update of that extension, or rolling PHP back on staging to prove it.

When is a 500 not an extension?

Disk full, bad database credentials in configuration.php, a broken .htaccess, or a core update that failed mid-way. The log still decides. If it names libraries/ after a Joomla update, restore the update backup, do not delete libraries.