Joomla 6.2 Is Due on 13 October: Requirements, Changes and Which Sites Can Take It

The Joomla project released the Joomla 6.2 Release Candidate on 29 September 2026 and plans the stable release for on or about 13 October 2026. The release candidate is for testing only, so keep it off client sites.

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 preview and mail. We also fully expect 6.2.0 to be a security release, which means it needs to reach your sites within days of 13 October. 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 is Joomla 6.2 released?

Joomla 6.2 is scheduled for 13 October 2026, after three alphas, three betas and one release candidate. Feature freeze came with Beta 1 on 18 August and language freeze with RC1 on 29 September, so the code that ships should be very close to what is in the release candidate now. The project notes that dates can move with volunteer availability.

13 October is 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 13 October, every Joomla 5 site moves to security-only support on the day 6.2 arrives.

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. Once 6.2.0 is out, the next 6.x security fix will ship as 6.2.1, not 6.1.5, so staying on 6.1 is not an option for long. If 6.2.0 includes security fixes, as we expect, it will be the only release that has them for Joomla 6 sites. Joomla 5.4 is still in its security support window, and 5.4.10 is already at release candidate stage.

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.2 Upcoming and 6.1 Current” 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 project’s own Beta 1, Beta 2, Alpha 3 and Alpha 2 posts:

• Article preview without a front-end login (#48030). Unpublished articles can be shared for review through signed, time-limited preview links. The lifetime is configurable and defaults to 15 minutes. This one will matter to clients who sign off content.
• OAuth 2.0 for SMTP. 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.8.2, 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 candidate itself adds little beyond Beta 3: wording that names “MariaDB/MySQL” rather than “MySQL” throughout, a com_contact SQL fix and test tooling updates.

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.

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 says no deprecations have been introduced in 6.2, and 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

85.4% of Joomla 6 sites already run 6.1.4, the current release, and the rest are a patch or two behind. These sites will be 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, and no tool can do that reliably until 6.2 is released.

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. 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?

Treat 6.2 as a security update that also brings new features. Do the preparation now, so that applying it after 13 October takes days rather than weeks:

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. Bring each 6.x site to 6.1.4 first. It includes 16 security fixes, covered in our 5.4.9 and 6.1.4 write-up, and gives all your sites the same starting point.
3. Update one representative site per stack on release day. 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 a security release is out, the fixed code is public, and anyone can compare it with 6.1.4 to work out what was vulnerable. 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. On 13 October, the Joomla Security Centre will list exactly what 6.2.0 fixes.