JoomlaForever.com! - How to Safely Upgrade Joomla 3.10 to Joomla 4 When Extensions Warn or Won't Auto‑Update

Details: Written by: Bjørn Ove Bremnes; Parent Category: Community Questions; Category: Community Questions - News; Published: 27 May 2026

If your site still runs Joomla 3.10 and the pre‑update checker shows warnings for extensions, you are not alone. Upgrading the core is usually straightforward, but incompatible extensions, templates or page builders can break a site. This guide gives a practical, low‑risk workflow you can follow: inventory extensions, create a tested staging clone and backups, address incompatible items, run the core upgrade on staging, test thoroughly, and then upgrade production with a rollback plan.

Throughout this article, be cautious with technical steps that affect live data. Verify server requirements and specific behaviors against the official Joomla documentation before making production changes.

Quick overview: What changes from Joomla 3.10 to Joomla 4

Joomla 4 modernizes the core: it raises PHP requirements, changes internal APIs and improves the administration UI. Because of those changes, some third‑party extensions and templates must be updated to remain compatible. The core upgrade updates only Joomla's core; third‑party extensions remain independent and must be individually addressed.

Overview: Why some extensions show warnings

Developers declare compatibility in extension manifests or via update metadata; a mismatch shows warnings in pre‑update tools.
Warnings may come from Joomla's pre‑update checker or from the extensions themselves when their code uses deprecated APIs.
A warning does not always mean immediate failure, but it signals the need to test the extension on a staging environment before upgrading production.

High‑level technical changes affecting extensions

Joomla 4 enforces stricter namespacing and has removed or refactored some legacy APIs; older extensions that directly reference removed classes can produce errors.
Minimum PHP version requirements for Joomla 4 are higher than for 3.10; your server must meet those before you upgrade.

Example: an older gallery extension may rely on deprecated Joomla classes. If left active during a core upgrade it can cause fatal PHP errors until updated or disabled.

Warning: Do not upgrade a live site without a verified rollback plan and working backups. Always test on staging first.

Pre‑upgrade safety checklist (backups, staging, PHP)

Before you touch the core update, complete the following essential preparation steps to minimise risk.

Create a complete site backup (files + database)

Use a tested backup tool or hosting snapshot. Tools like Akeeba Backup are commonly used in the Joomla community; verify any tool's behavior on your hosting platform before relying on it.
Verify backup integrity by restoring to a temporary location or extracting the archive locally.
Keep at least one offsite copy in addition to local/host backups.

Create a staging copy: cloning options (host tools, Akeeba, manual)

Options: host‑managed staging, Akeeba Kickstart/Restore, or a manual clone (copy files + export/import DB).
Adjust configuration.php and database credentials on the staging copy and prevent search engines from indexing it (robots.txt or HTTP auth).

Check server requirements: PHP, database and extensions (how to verify)

Check PHP version using your host control panel, phpinfo(), or Joomla System Information.
Confirm required PHP extensions (for example: mbstring, json, pdo_mysql). Verify the precise list and minimum versions against official Joomla documentation.
Change the PHP version on staging first, test, then plan to update production during the maintenance window.

Quick copy/paste mini checklist:

Create full backup (files + DB) and verify restore.
Restore backup to staging and secure staging URL.
Set staging PHP to the version you plan to use on production.
Run pre‑update checks on staging and prepare a remediation list for incompatible items.

Warning: When restoring to staging, do not accidentally point the staging site at production services (mail, payment gateways) without switching to test credentials.

How to audit installed extensions, templates and plugins

Build an inventory and prioritize what must be fixed before the core upgrade.

How to generate an extensions inventory and prioritize fixes

Open Extension Manager and list all components, modules, plugins and templates with their versions.
Create a spreadsheet with columns: Name, Type, Version, Vendor, Last updated, Stated Joomla compatibility, Priority (High/Medium/Low).
Prioritize high‑impact items first (authentication, ecommerce, forms, page builders, SEO plugins).

How to check extension compatibility (developer pages, Joomla update components, compatibility tools)

Check vendor product pages and changelogs for Joomla 4 support.
Use Joomla's update metadata where available to see declared compatibility.
When vendor guidance is unclear, restore the extension to staging and test it under Joomla 4 there.

Example spreadsheet row:

Warning: Do not rely on version numbers alone — verify changelogs or vendor statements about Joomla 4 compatibility.

Handling incompatible or unmaintained extensions (options and decisions)

When an extension is unmaintained or incompatible you have four broad options: update, replace, disable, or hire a developer to port/patch it. Choose based on functionality importance, security risk, and migration cost.

Options for unsupported extensions: update, replace, disable, or rewrite

Update — use the vendor's Joomla 4 release if available (easiest path).
Replace — identify maintained alternatives and plan how to migrate content and settings.
Disable/hide — acceptable for non‑essential features with little user impact.
Rewrite/patch — hire a developer if the extension is mission‑critical and no replacement exists.

Decision matrix for an unsupported extension

Use a simple matrix considering: security exposure, user impact, data complexity to migrate, and cost. Mark each extension High/Medium/Low on those criteria to make a decision.

Example scenario: A low‑traffic gallery extension lacking updates → replace with a maintained gallery extension that can import existing images; minimal user disruption expected.

Warning: Disabling an extension without cleaning up related database rows or content can leave orphaned data. Document and plan cleanups after disabling.

Step‑by‑step upgrade workflow for a safe migration

Follow this chronological checklist on staging first. Only when staging is fully tested repeat the steps on production during a maintenance window.

Preparing the site: disable caches, switch to default template if necessary

Disable system caches, CDN caching, and performance plugins on staging to get accurate test results.
If your template has heavy overrides and you suspect compatibility problems, temporarily switch staging to a default Joomla template to isolate template vs core issues.

Using Joomla's pre‑update checker and update path

Run the pre‑update checker available in Joomla or via a recommended extension and address reported issues where feasible.
Follow the Joomla Update component to apply the core upgrade once staging is prepared and incompatible extensions are dealt with.

Performing the core upgrade on staging and then on production

Upgrade staging and perform the test plan below.
Capture logs and screenshots of any warnings or errors; iterate fixes and retest.
When staging is stable, schedule a production upgrade during low traffic: take a fresh backup, put the site in maintenance mode, and repeat the same sequence used on staging.

Example workflow summary:

Clone to staging with a verified backup tool.
Set staging PHP to the planned production PHP version and test extensions.
Fix top incompatible extensions (update/replace/disable).
Run Joomla pre‑update checker and upgrade core on staging.
Execute test plan and capture results.
Upgrade production, monitor logs and rollback if necessary.

Warning: Do not change PHP on production without validating on staging first — PHP incompatibilities can immediately break the site.

Testing the upgraded site: what to check first

Use a focused test plan to validate critical functionality and to detect subtle regressions.

Functional testing checklist: front-end, admin, forms, logins, search, module positions

Front‑end: open home, major landing pages, test responsive layout and module placement.
Authentication: test login/logout for admin and typical user roles.
Forms and integrations: submit contact forms, verify email delivery and any CRM/webhook integrations.
Admin: create/edit an article, check Media Manager and extension UIs.

Performance and SEO checks after upgrade

Run Lighthouse or a similar audit to identify performance regressions.
Verify sitemap, meta titles, breadcrumbs and robots/meta tags; ensure staging is blocked from search engines.

Example small test script:

Visit home page and two inner pages.
Login as an editor and update an article.
Submit contact form and verify email.
Check sitemap.xml and robots.txt.

Warning: Ensure staging is blocked from search engines to avoid duplicate content records.

Common problem areas (page builders, frontend editing, template overrides) and remedies

Some areas commonly cause trouble during Joomla major upgrades. Identify them early and plan mitigations.

Page builders and frontend editors

Page builders and frontend editors frequently need vendor updates to support Joomla 4. Identify pages built with these tools and test a sample page on staging.
Check whether the builder vendor provides migration or export tools; otherwise plan manual rebuild or substitution.

Template overrides and customizations

Inspect /templates/yourtemplate/html for overrides and document them before upgrading.
Test by temporarily switching to a default template; if errors disappear, the template override is the likely cause and must be updated.

Custom code and patched core files

If your site contains patched core files, identify and document these customizations. Prefer moving custom code into plugins or template overrides rather than touching core files.

Warning: Do not force unsupported page builders to run on production under Joomla 4—this can break the frontend and user experience. Plan a controlled migration on staging instead.

If something goes wrong: rollback and recovery options

If the upgrade causes failures, follow a clear rollback procedure and preserve diagnostic information for debugging.

Rollback plan: restoring backups and undoing changes

Immediately put the live site into maintenance mode to prevent further user disruption.
Restore files and database from the verified backup taken before the upgrade.
If available, use hosting snapshots for a faster rollback; verify your host's snapshot behavior before relying on it.

When to seek professional help after a failed upgrade

If error logs show fatal PHP errors, or the site has complex template and extension failures, hire a Joomla developer with upgrade experience.
Keep a copy of the broken state (files + DB) for the developer to inspect before restoring the backup—this aids diagnosis.

Example recovery sequence: if production shows a blank page after upgrade — 1) enable maintenance mode, 2) restore last backup snapshot, 3) collect logs and error messages, 4) reproduce the issue on staging for debugging.

Warning: Do not delete the broken site immediately. Preserve logs and copies to assist debugging by a developer.

When to hire professional help or consider rebuilding parts of the site

Decide whether a DIY migration is realistic based on site complexity and available expertise. For mission‑critical sites, or when many essential extensions are unmaintained, professional help is often the safer and quicker option.

Cost vs benefit: when rebuilding templates or migrating content is better

Estimate developer hours to port an extension vs. rebuild the feature with a supported solution. Include data migration, testing and SEO work in estimates.
Consider long‑term maintenance: choosing maintained extensions reduces future upgrade risks.

How to prepare an effective brief for a Joomla developer

Provide extension inventory, staging access, recent error logs, and a clear list of required behaviors to reproduce the issue.
Include non‑functional requirements such as acceptable downtime windows, rollback expectations and acceptance tests.

Warning: Avoid vendors that recommend risky shortcuts like editing core files without a documented plan for future upgrades.

Resources and next steps

Use authoritative sources and a short action list to get started immediately.

Action list: what to do today

Create a full site backup and verify a restore to a local or staging environment.
Restore to staging and secure it from search engines.
Build an extension inventory and mark the top 3 critical extensions for action (update/replace/disable).

Where to find official compatibility info

Primary sources for compatibility and upgrade procedures are the official Joomla documentation, vendor product pages/changelogs for extensions, and the Joomla Extensions Directory. Verify any technical claim against those primary sources before applying changes to production.

Next steps summary: Back up → Clone to staging → Audit extensions → Address top issues → Upgrade staging → Test → Upgrade production with rollback plan.

FAQ

Will the site break if I try the Joomla 4 upgrade on my live site?

There is risk, especially when incompatible extensions or templates are active. Always test on a staging clone first, create a full backup, and have a rollback plan. Schedule the upgrade during low traffic and consider professional help if the site is mission‑critical.

How can I find out which extensions are incompatible with Joomla 4?

Generate an inventory from the Extension Manager, check vendor pages and changelogs for Joomla 4 support, and run Joomla's pre‑update checker on staging. Prioritize based on how critical each extension is to your site's functionality.

What if the original developer disappeared and some extensions have no updates?

Options include replacing the extension with a maintained alternative, disabling the feature and hiding related UI, or hiring a developer to port or patch the extension. Assess the migration effort versus the business value of the feature before deciding.

Do I need to change my PHP version before upgrading?

Possibly. Joomla 4 requires newer PHP versions than Joomla 3.10. Verify the exact minimum and recommended PHP versions (and required PHP extensions) against the official Joomla documentation and test the PHP version on staging before applying changes to production.

Will upgrading Joomla core automatically update third‑party extensions?

No. Core upgrades do not automatically convert or update third‑party extensions to Joomla 4 compatibility. Extension updates are released by their vendors and must be applied separately. Confirm this behavior with the official Joomla upgrade documentation.

Conclusion

Upgrading from Joomla 3.10 to Joomla 4 is entirely achievable with planning and caution. The essential ingredients are a verified backup, a secure staging clone, a careful inventory of extensions and templates, and a staged workflow that upgrades and tests on staging before production. Where extensions are unmaintained, weigh the cost of replacement or developer work against the feature's value. When in doubt, seek an experienced Joomla professional to reduce risk.

Verify all technical details and requirements against official Joomla documentation before making production changes.

Add comment

Three ways optimize the use of CSS in content with Joomla

CSS has from the age of the Internet been a part of doing websites. It is an easy but useful way to design an article. There are several ways to write CSS in Joomla, you can use an external file to store all CSS codes in, you can use an extension to include the code, or you can write CSS directly in the content. In this article, I will give some look into how I do it.

In this article, I will show you three different ways to use CSS in an article. The easiest thing is to use an extension to add CSS to the article. There are several extensions in the JED (Joomla Extensions Directory) that gives this opportunity. One of the popular is Sourcerer from Regular Labs. But its also possible to do in-line CSS coding in every article, but this can be very ineffective in large articles, the third and maybe most used is to put the CSS codes into the template as eighter an external file or in the CSS capabilities of the template itself. In modern template-Framework is this common, the disadvantage of this is that you always need access to the backend to add extra CSS in your site.

W3C CSS verified: W3c.org is setting the standards for CSS

1 Code directly as you go (Hard coding the articles)

If you prefer to do the CSS coding inline as you write an article, you must bear in mind that you will NOT be able to reuse the CSS on any other articles and you must repeat the same thing for every content with the same code. This could look like this:

<a href="/home" style="background-color:#ff0000;color:#ffffff;">Home</a>

This will output: Home

2. Use an external file

If you use an external file as a CSS source, it is normally located under the css folder in your template directory. And its usually called custom.css or user.css, the downside with this is that you need access to either FTP or bee logged in to the backend as a Super Administrator.

3 Use an extension to add CSS code in the article

If you want to use an extension to insert CSS in an article, you can not reuse the CSS codes without having it in every article that contains the same style.

What do I recommend?

A combination of the option 2 and 3, will give the easiest result and you can standardize some of the CSS styles in a file and add styles in that applies to certain articles at one addon at the end of the written article.

Comments wanted