Joomla 6.2 Is Out: Requirements, Changes and Which Sites Can Take It

The Joomla project released Joomla 6.2.0 on 13 October 2026, on the date it had planned. Joomla 5.4.10 came out the same day, with bug fixes only.

For anyone looking after a portfolio of client sites, 6.2 should be a straightforward update to apply. The server requirements are the same as 6.1, the official upgrade notes list no backward compatibility breaks, and the new features are mostly in the editor, content layout and mail. 6.2.0 has no security fixes, as the Joomla Security Strike Team told us before release, but the next Joomla 6 security release will be a 6.2.x, so your sites need to be on 6.2 before it arrives. The real question is which of your sites can take it, and the answer depends more on PHP versions and Joomla 5.4 stragglers than on anything in 6.2.

mySites.guru answers the server side of that question on one page. The Joomla 6 Compatibility Checker (press c then 6 anywhere in the dashboard) lists every connected Joomla 4, 5 and 6 site with its PHP version, database version, update channel and the state of the Backward Compatibility 6 plugin, each colour-coded against the Joomla 6 technical requirements. The figures below come from the same data, across all Joomla sites connected to mySites.guru that took a snapshot in the last 30 days.

When was Joomla 6.2 released?

Joomla 6.2.0 shipped on 13 October 2026, after three alphas, three betas and two release candidates. Feature freeze came with Beta 1 on 18 August and language freeze with RC1 on 29 September, and the schedule held all the way to the stable release.

13 October was also a date for Joomla 5. The Joomla 5.4.9 announcement confirms that 5.4.x gets bug fixes until 13 October 2026 and security fixes until 12 October 2027. So on the day 6.2 arrived, every Joomla 5 site moved to security-only support.

Joomla 6.1 is also affected. The Joomla software release cycle says a minor release goes out of support when the next minor is published, so 6.1 went out of support on 13 October. The next 6.x security fix will ship as a 6.2.x release, not 6.1.5, so staying on 6.1 is not an option for long. 6.2.0 itself has no security fixes, but every 6.x security fix after it will ship for 6.2 only. Joomla 5.4 is still in its security support window, and 5.4.10 is its current release.

Joomla 6.2 technical requirements are unchanged from 6.1

Joomla 6.2 needs exactly what Joomla 6.1 needs. The official requirements page covers 6.1 and 6.2 in a single table:

A site that runs Joomla 6.1 today meets the 6.2 requirements by definition. In our data, every Joomla 6 site reports PHP 8.3 or newer, and 38.5% are on 8.3 exactly, the minimum, with 8.4 recommended. A small number run Joomla 6 on MySQL 5.7 or MariaDB 10.3, below the documented minimum. They work today, but Joomla does not test against those versions, and the MariaDB and MySQL picture across our sites explains why so many databases have drifted out of support.

What’s new in Joomla 6.2

Most of the 6.2 changes affect editors and site builders rather than hosting. These come from the release announcement, the merged pull requests and the project’s own Beta 1, Beta 2, Alpha 3 and Alpha 2 posts:

• OAuth 2.0 for SMTP (#48290). Joomla can now authenticate to mail providers such as Microsoft 365 and Google with OAuth instead of a stored password. Microsoft has been retiring basic SMTP authentication, so this helps any site that sends mail through Microsoft 365.
• Language fallback chains (#47933). A missing translation string can resolve through a configured fallback language, string by string, instead of showing a raw language constant.
• Editor changes. TinyMCE moves from 8.6.0 to 8.9.1, gets a native Read More button (#48236), media manager integration (#48043) and a shared link picker for articles, contacts and menu items (#48138). By default TinyMCE now follows Joomla’s own text filter settings (#48041).
• Content and layout options. Sub-category images in category lists (#48196), image and figure classes for articles (#47744), more mod_login options (#47946) and sub-levels below more than just the main menu item (#47909).
• Web services. The content API now returns intro text and full text as separate fields (#44566), and category endpoints accept a state filter (#46887).
• Smaller fixes. Clearer SVG upload errors, better installer error handling, a new backend help page and aria-disabled on toolbar buttons that need a selection.

The release candidates added little beyond Beta 3: wording that names “MariaDB or MySQL” rather than “MySQL” throughout (#48369), a com_contact SQL fix and test tooling updates.

One feature you may have read about did not ship. Article preview without a front-end login (#48030), which shared unpublished articles through signed, time-limited links, was merged for Beta 1 and then reverted in #48325 before Beta 2. It is not in 6.2.0, so do not promise it to clients who sign off content.

The security flag on Joomla extension updates

The 6.2 change with the most value for agencies has no visible interface of its own. Pull request #48127 lets an extension developer mark a release as a security release by adding one tag to their update XML:

<security>4</security>

The number is a severity from 0 (none) to 4 (critical). Joomla’s update manager then shows the severity next to the available update. A follow-up, #48190, makes Joomla report the highest severity of any release since the installed version. Without it, a critical fix in 1.0.1 would be hidden if 1.0.3 was an ordinary bug-fix release. The change was backported in #48233, so it already works on Joomla 5.4.9 and 6.1.4, and our developer guide to the security flag covers the XML, the edge cases and what admins see.

That is the real limitation. In a month of Joomla security disclosures, the hardest part for site owners was not applying fixes but knowing which updates were fixes at all. The tag is a step forward, but it depends on the same vendors who currently write “various improvements” in their changelogs. mySites.guru does not rely on that self-reporting: it matches installed extension versions against known vulnerability rules and alerts you when a site runs an affected version, whatever the vendor’s update XML says.

Will my extensions work on Joomla 6.2?

Almost certainly, if they already work on Joomla 6.1. Joomla’s release cycle forbids backward compatibility breaks in a minor release, and the 6.1 to 6.2 upgrade notes back that up. The deprecations page lists none, although the merged pull requests do deprecate the CMS Crypt package (#47443) and the static methods of MailTemplate (#47717). Deprecated code still runs in 6.2, so only extension developers need to act on these. The only new developer feature listed is a rebuilt asset build pipeline, which affects people building Joomla core, not people running it.

Two areas deserve a test on a copy before you roll out widely:

• Editor extensions. Anything that adds TinyMCE buttons, plugins or its own link and media dialogs is running inside an editor that changed more than any other part of 6.2.
• Anything touching the update system. The update tables get a new column for the security flag. Extensions that read or write those tables directly, such as custom update managers, are the ones to watch.

Vendor statements are starting to appear. Akeeba’s compatibility matrix already has a “Joomla 6.2” row for Akeeba Backup and its other Joomla extensions. Most vendors do not publish anything for a minor release, and with no breaking changes documented, a missing announcement is normal.

To check what each site actually runs, the extensions list in mySites.guru shows every installed extension and version across all your Joomla sites, so you can see which sites use the editor add-ons and update tools mentioned above.

Which of your Joomla sites can take 6.2

Joomla 6.2 is an update for Joomla 6.1 sites. Everything else is a different project. Here is how the Joomla sites connected to mySites.guru break down today:

Joomla 6.1 sites are ready

On 3 October, 85.4% of Joomla 6 sites already ran 6.1.4, the last 6.1 release, and the rest were a patch or two behind. These sites are offered 6.2 on the Default update channel like any other update.

Joomla 5.4 sites need a major upgrade first

Many of them cannot do it yet. The 6.2 release notes repeat the rule that a site must be on 5.4 before moving to 6.x. In our data, 27.3% of Joomla 5.4 sites run PHP below 8.3, almost all of them on PHP 8.2, so Joomla 6 will not install there until the host or server moves to a newer PHP. That is the blocker worth finding first, because a PHP change on shared hosting can mean a support ticket or a client conversation.

Joomla 3 and 4 sites

These are outside the scope of a 6.2 update. Joomla 4 is fully end of life, and Joomla 3 sites need either a rebuild or the Joomla 3 patching route covered on joomla3security.com.

The Joomla 6 Compatibility Checker puts all of this on one screen. It flags PHP below 8.3 in red, 8.3 in amber and 8.4 or newer in green, applies the same three-colour logic to MySQL, MariaDB and PostgreSQL, and marks any site whose update channel is not “Default”. It does not test individual extensions against 6.2. Only an update on a copy of the site tells you that.

The compat6 plugin is a Joomla 7 problem, not a 6.2 one

One figure in our data matters more than anything in 6.2. 84% of Joomla 6 sites still have the “Behaviour - Backward Compatibility 6” plugin enabled. That plugin keeps old Joomla 4 and 5 code working on Joomla 6. Joomla 5.4 installs it enabled, and the upgrade documentation requires it to stay enabled for the move to 6.x, so almost every upgraded site still has it on. Fresh Joomla 6 installs start with it off.

It does no harm on 6.2. The compatibility plugin page for 6.2 is unchanged from 6.0. The problem comes later. Joomla releases a new major version every two years, in October of odd years, so Joomla 7 is due in October 2027. The 6.2 change in #47814 already adjusts the pre-update check so the CLI updater checks the compat6 and compat7 plugins before a major upgrade.

A site that only works because compat6 is on is running at least one extension that has not been updated for Joomla 6. We made the same argument for Joomla 5 in the compat plugin is a crutch. The 6.2 window, with no breaking changes and twelve months before the bridge release, is the cheapest time to switch the plugin off on a staging copy, see what breaks, and chase the vendor. What breaks usually shows up as Class “JPlugin” not found or a similar old class name. The Compatibility Checker shows the plugin state per site, so you can start with the sites where it is already off and work towards the ones where it is on.

How should I roll out Joomla 6.2 across many sites?

6.2.0 has no security fixes, but it is the release the next Joomla 6 security fixes will be built on. Do the preparation now, so that your sites are on 6.2 before that security release arrives:

1. Check update channels now. Any site on “Joomla Next” or “Testing” can be offered things you did not plan for. Our post on preventing accidental Joomla version jumps covers why Default is the only sensible production setting.
2. Find the 6.x sites below 6.1.4 first. They are missing the 16 security fixes in 6.1.4, covered in our 5.4.9 and 6.1.4 write-up. 6.2.0 includes those fixes, so these sites go to the front of the queue.
3. Update one representative site per stack first. Choose a site that uses your usual template, page builder and editor add-ons, update it, then check editing, the front end and mail delivery.
4. Roll out in batches with a backup first. The Mass Upgrade Sites tool (m then u) updates selected sites in one pass, and an Akeeba backup beforehand gives you a way back.
5. Plan the Joomla 5.4 sites separately. Find the ones on PHP 8.2 and fix PHP first. The Joomla 6 upgrade can follow, and there is no reason to tie it to the 6.2 release date.

Once the first 6.2.x security release is out, the fixed code is public, and anyone can compare it with 6.2.0 to work out what was vulnerable. A site still on 6.1 at that point has a major gap to close, not a patch to apply. That is why the gap between release and rollout should be short. The smoke test on one site per stack is still worth the hour: 5.4.9 shipped with a known issue that broke API edits, and a fault found on one site is far cheaper than one found on all of them. The Joomla Security Centre lists each core advisory on the day its fix is released.