JoomlaForever.com! - How to Safely Upgrade from Joomla 3.10 to Joomla 4 When Extensions Block the Way

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

This guide helps Joomla site owners move from Joomla 3.10 to Joomla 4 when third-party extensions or PHP requirements appear to block the way. Follow a staged, test-first workflow: audit extensions, make reliable backups, create a staging copy, run the upgrade there, and only deploy to production when the staging site is verified. The aim is predictable, recoverable change rather than trial-and-error on a live site.

Who this is for: site owners, administrators, web designers and beginner developers who need a clear, cautious plan to upgrade.

Quick answer: Will the site 'blow up' if you try the upgrade?

Short answer: not necessarily, but there is risk—especially from incompatible third-party extensions, custom code, or a mismatch in PHP/database versions. A controlled approach with backups and a staging run reduces the risk of breaking your live site.

Short reassurance and risk summary

Core upgrades are commonly safe when prerequisites are met and extensions are compatible.
The main risk is third-party extensions or template overrides that are incompatible with Joomla 4 or with the PHP version required.
Perform the upgrade on a staging copy first; use backups and a rollback plan for production.

What Joomla's pre-upgrade checks will do (high level)

Joomla provides tools to help spot potential issues before upgrading, such as highlighting PHP version mismatches and listing installed extensions. Treat these as advisory: they flag possible problems but do not guarantee a successful upgrade.

Practical example:

On staging you might see five flagged extensions. Actions include checking each vendor for an update, disabling non-critical extensions during the upgrade, or planning a replacement/migration for critical but unsupported extensions.

Warning: Do not run the core upgrade on production without a tested recovery plan. Changing PHP on production can itself cause outages independent of the Joomla upgrade.

Pre-upgrade checklist: 8 things to do first

Before you touch the core upgrade, run this checklist. Each step reduces variables and makes troubleshooting easier.

Confirm the current site state: Joomla exact version, PHP version, database version, template name, and any customizations or overrides.
Create a full backup (files + database) and verify it restores in a test environment.
Inventory installed extensions: components, modules, plugins, templates and their versions/vendors.
Set up a staging copy (local dev, host-provided staging, or a subdomain clone).
Check server requirements for Joomla 4 and plan PHP/database updates on staging before production.
Disable non-essential plugins/modules to reduce interference during the upgrade.
Gather admin credentials, FTP/SFTP or SSH and hosting control panel access.
Document any custom code or template overrides that may need porting to Joomla 4.

Understand core vs third-party extensions

Core extensions are maintained by the Joomla project and are usually updated through core upgrades. Third-party extensions (components, modules, plugins, and templates) are the common source of upgrade problems — treat them as separate projects that may require vendor updates, replacements, or custom porting.

Verify system requirements (PHP, database, web server) — and why to confirm

Joomla 4 generally requires newer PHP and database versions than Joomla 3.10. Changing PHP on live hosting can break extensions; therefore change PHP only on staging first. Verify the exact minimum and recommended versions from official Joomla documentation before proceeding.

How to make a full file + database backup (conceptual steps and tools)

Beginner-friendly: Use Akeeba Backup (GUI-based) to create an archive and test restore with Kickstart on staging.
Manual method: export your database (phpMyAdmin or mysqldump), copy all site files via SFTP, and download configuration.php. Test by restoring these on a local or staging host.
Always verify a backup by performing a complete restore to a separate environment before relying on it for rollback.

Warning: Backups can silently fail if permissions or storage quotas block files. Always confirm the backup integrity by restoring it to a test environment.

How to audit your extensions and find incompatibilities

An extension audit turns an unknown list into a prioritized action plan.

Export or manually copy the list of installed extensions: component/module/plugin/template name, type, version, and vendor.
Check each item for Joomla 4 compatibility on vendor sites, changelogs, the Joomla Extensions Directory (JED), or the extension's repository.
Mark the action for each: update, replace, disable, remove, or plan a custom port.
Prioritize business-critical extensions (e-commerce, user/authentication, forms) for testing and remediation.

Using Joomla's Extension Manager and Update component to gather info

Use Extensions → Manage and Extensions → Update to see installed items and available updates. If your administration interface does not offer an export option, copy the list into a spreadsheet for tracking.

Check vendor sites and documentation for Joomla 4-ready releases

Vendor changelogs and support pages are the most reliable source for compatibility statements. If a vendor is inactive, plan for replacement or developer assistance.

Decide how to act: update, replace, disable, remove, or patch

Use this decision flow:

If a Joomla 4 version exists: test it on staging and follow vendor upgrade steps.
If no update and the extension is critical: seek replacements or hire a developer to port/patch.
If non-critical: consider disabling or removing the extension, remembering to archive or export data it owns if necessary.

Practical example:

Warning: Removing an extension that holds data without migrating that data may cause permanent loss. Back up DB before removal and test migrations on staging.

Create a safe test environment: backups and staging

Staging is the foundation of a safe upgrade. Treat staging as your rehearsal stage and verify every step there.

Setting up a staging copy (local or hosting staging) and syncing data

Host-provided staging: use one-click staging if your host offers it — usually the fastest and most reliable option.
Manual staging: restore your backup to a subdomain or local environment. Update configuration.php with new DB credentials and the staging URL.
For sites that receive frequent updates, plan a data sync strategy for the final cutover to avoid losing new transactions or registrations.

Disabling outbound actions on staging

Change mail settings or disable email plugins so staging does not send live emails.
Disable payment gateways and scheduled jobs (cron).
Protect staging from search engines (robots.txt, noindex) and add HTTP authentication if needed.

Practical example:

Export DB via phpMyAdmin, copy files to /staging, update configuration.php (DB user, DB name, $live_site if set), and add .htaccess rules to block robots and require basic auth.

Warning: Forgetting to disable payment gateways can cause accidental charges. Always verify outbound protections before testing.

Step-by-step: upgrading Joomla core from 3.10 to 4 on staging

Use this runbook to perform the core upgrade on your staging site. Do not skip steps or test only selectively.

Upgrading on staging: step-by-step runbook

Confirm a fresh staging backup is available and documented.
Switch staging PHP to the version required or recommended for Joomla 4. Test the site immediately for errors.
Disable non-essential and previously flagged extensions.
Take a staging snapshot (so you can quickly revert the staging site if needed).
Use Extensions → Update or the Joomla Update component to apply the Joomla 4 upgrade, or follow vendor instructions for package install if a manual update is required.
After files are updated, run any database migration steps prompted by Joomla and clear all caches.
Re-enable extensions one at a time and test key workflows after each re-enable.

Common post-upgrade maintenance tasks

Rebuild menus and check module positions and template overrides.
Review logs for deprecated function warnings and address them or document for a developer.
Update third-party extensions to their Joomla 4 versions after the core upgrade, and again test them individually.

Warning: A partial or interrupted core upgrade can leave the site in an inconsistent state. If the upgrade fails on staging, diagnose and repeat the staging run until stable before considering production.

What to do about incompatible third-party extensions

When extensions block the upgrade, you have a set of options. Choose based on business impact and data importance.

Replacing vs migrating vs keeping: decision flow

Vendor provides Joomla 4 update: test and apply on staging.
Vendor inactive but extension holds business data: export data and migrate to a supported extension.
Extension is cosmetic or low-impact: disable or remove and find alternatives.

How to migrate data when replacing components

Identify the database tables the extension uses. If a replacement has import utilities, use them. Otherwise export relevant tables to CSV, map fields to the new component and import on staging. Verify data integrity and relationships before performing any production migration.

When to consider a custom patch or hiring a developer

For business-critical extensions without vendor support, porting or patching by an experienced Joomla developer may be the most practical option. Gather extension code, DB schema information, and a staging environment before engaging help.

Warning: Direct SQL manipulation is risky—always back up the database and test migration scripts on staging first. Verify extension licensing before modifying third-party code.

Post-upgrade checks and common issues

After a successful upgrade on staging, run this checklist to validate the site.

Functional checklist

Admin login and ACL behave correctly.
Front-end navigation and representative pages render correctly.
Forms, contact forms, and user registration/login work end-to-end.
E-commerce checkout and payment flows (if applicable).
Module positions and template layout are intact; overrides do not break pages.

Technical checklist

Check PHP and Joomla error logs for runtime warnings or deprecated notices.
Clear all caches and verify permissions.
Run any available database fixes in Extensions → Manage → Database (test first on staging).

Common issues:

Template overrides not compatible with Joomla 4 leading to layout problems.
Missing module positions or modules appearing blank due to incompatible module versions.
Deprecated PHP functions showing up in logs — these may need developer fixes.

Warning: Enabling verbose debug on production can expose sensitive information; restrict debugging to staging or brief maintenance windows on production if necessary.

Rollbacks and recovery: how to restore if the upgrade fails

Have a documented restore procedure and practice it before upgrading production. Know when to revert: critical workflows broken, data loss, or unrecoverable errors.

How to perform a rollback from a backup

Put the production site into maintenance mode to prevent new data from being created during restore.
Restore files from the backup archive (or overwrite with a snapshot) and then import the matching database backup.
Verify site operation thoroughly before removing maintenance mode.

If you must reattempt the upgrade

Collect logs and a clear description of what broke, fix or remove offending extensions on staging, and re-run the upgrade on staging until stable. Only then repeat the process on production with a final backup taken immediately before the production upgrade.

Warning: Restoring an older database when transactions occurred after that backup will lose those newer records. Plan to export and re-import new data where feasible, and communicate downtime windows to stakeholders.

When and how to get professional help

Consider hiring help if the site relies on unsupported extensions, custom code, or if you lack time/technical confidence. Skilled Joomla professionals can port extensions, migrate data, and perform the production cutover with minimized risk.

Checklist for hiring external help (what info to provide)

Staging URL and temporary credentials.
List of installed extensions and versions, and any error logs.
Recent backups and a description of the desired outcome and constraints (budget, downtime window).
Licensing information if code modification is required.

Red flags and what to ask potential helpers

Ask for Joomla-specific experience and references for similar upgrades.
Request a clear staging-first plan and a rollback strategy.
Avoid vendors who promise instant fixes without diagnostics or a tested rollback plan.

Warning: Do not share permanent live admin credentials; provide temporary staging accounts and change passwords after the work is complete.

FAQ

Will my site break if I attempt the automatic upgrade?

If you upgrade directly on production without testing, there is a risk—especially from incompatible extensions. Use backups and a staging run to avoid breaking the live site.

How do I find which extensions are incompatible with Joomla 4?

Use Extensions → Manage and Extensions → Update to list installed extensions. Then check vendor pages, changelogs, and the Joomla Extensions Directory (JED) for Joomla 4 compatibility statements. Document each extension's status and plan action.

What are the minimum system requirements (PHP, database) before and after the upgrade?

System requirements differ between Joomla 3.10 and Joomla 4. Confirm exact PHP and database versions from the official Joomla documentation before upgrading.

Should I change PHP versions before upgrading and why?

Often yes—Joomla 4 typically requires a newer PHP version than older Joomla 3 sites. Change PHP on staging first and test all extensions because PHP changes can themselves cause incompatibilities.

How do I create a safe staging copy and full backup?

Create a full file + DB backup, restore to a staging environment using your host's staging feature or manual methods (Akeeba, manual file copy + DB import), update configuration.php, and disable outbound actions like email and payment gateways.

What are my options for incompatible extensions?

Options include updating to a Joomla 4-compatible version (if available), replacing with another extension, disabling if non-essential, removing with data migration, or hiring a developer to port/patch the extension.

How do I test the site after upgrading and roll back if needed?

Perform comprehensive functional and technical tests on staging. If production fails, restore files and DB from your tested backup and document the errors so you can fix them on staging before retrying.

When should I hire a developer or extension author?

Hire help when the extension is business-critical and unsupported, when custom code must be ported, or if you lack time/technical confidence. Provide staging access, error logs, and an extension inventory when requesting quotes.

Conclusion

Upgrading from Joomla 3.10 to Joomla 4 is achievable with a methodical, staging-first approach. Key steps: audit and prioritize extensions, create and verify backups, set up and secure staging, run the upgrade and test comprehensively, and have a clear rollback plan. If you hit an unsupported or business-critical extension, plan for replacement or engage a Joomla developer. Always verify version requirements and specific admin UI behaviors 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