What happened?

Joomla builds a check query for every statement in every file under an extension's sql/updates/<driver>/ folder. It has no concept of a later statement superseding an earlier one.

When a second SQL update file changes a column that an earlier SQL update file also changed the bug is triggered. The System, Maintenance, Database page then reports that column as having the wrong type, permanently, on a database that is exactly what the extension intends.

The root cause is Joomla expects both mutually exclusive changes to be present in the database at the same time. This will never be the case. Only the latest change will be present. Earlier changes will be invalid.

Clicking the repair button does not help. It re-runs the statements from the SQL files, the last one wins, and the earlier check fails again on the next page load. Running older statements is not idempotent. Reverting the schema to an older version may result in database errors or data loss.

A minimal plugin is attached: plg_system_enumrepro.zip, does nothing at runtime. It ships three update files that change one ENUM column three times.

Its install SQL creates the table in the final state. A fresh install is by definition correct. There is no upgrade path, no stale data, nothing to repair.

1. Install plg_system_enumrepro.zip (System, Install, Extensions, Upload Package File.
2. Go to System, Maintenance, Database.
3. Look at the row for System - ENUM schema check repro.

Version

6.1

Expected result

No problems reported. The database matches the schema the extension declares.

More generally: for any given column, the last statement across the update files is the one that describes the intended current schema. Earlier statements describe historical intermediate states which we can safely assume no longer hold.

Actual result

One problem is reported:

Table 'jos_enumrepro' has the wrong type or attribute for column 'state'
with type enum('alpha','bravo','charlie')

The reported "wrong" type is the one from 1.0.1, which 1.0.2 deliberately replaced.

Running Joomla's own parser over the two statements shows why — the expectations are mutually exclusive, so one of them must always fail:

### 1.0.1 (superseded)
checkQuery : SHOW COLUMNS IN `jos_enumrepro` WHERE field = 'state'
             AND UPPER(type) = 'ENUM(''ALPHA'',''BRAVO'',''CHARLIE'')' ...
RESULT     : NO MATCH -> reported as a problem

### 1.0.2 (current)
checkQuery : SHOW COLUMNS IN `jos_enumrepro` WHERE field = 'state'
             AND UPPER(type) = 'ENUM(''ALPHA'',''BRAVO'',''CHARLIE'',''DELTA'')' ...
RESULT     : MATCHES -> ok

System Information

• Joomla: 6.1-dev, also 6.2-dev, 5.4-dev
• Database: MySQL 8.4.10 (irrelevant)
• PHP: 8.5.8 (irrelevant)

Additional Comments

Fixing

We have worked on a PR against 6.1-dev. Give us a few minutes.

Core

Joomla core does not trigger it. Core resets its update folder at each major version and has so far never re-altered the same column within one branch. Third-party extensions do not have that luxury. Their sql/updates folder is cumulative across the entire life of the extension. Re-altering a column is expected. Adding one value to an ENUM — a completely ordinary thing to do — is enough. It happened to us ten times in our client projects. This is why we put time today to fix it.

Impact

The extension developer's only recourse today is to reach into the older, already-shipped update file and replace it with a single comment line. This is problematic for tracing schema changes over time.

Until then, users see a red warning on a core maintenance page telling them their database is broken when it is not, which generates support tickets and — worse — trains people to ignore that page.