Conversation
This was referenced Jul 18, 2026
Merged
Raise the enforced minimum supported database version from 5.5 to MySQL 8.0 and MariaDB 10.6. checkServerVersion() previously compared the raw server version string directly, which breaks for MariaDB: it reports its version with a leading "5.5.5-" compatibility prefix (e.g. "5.5.5-10.6.19-MariaDB") that version_compare reads as 5.5.5. The comparison now normalises the string and, when the server identifies itself as MariaDB, applies the MariaDB minimum even if the MySQL schema is configured (a supported setup). The thrown error also reports the actual database type. The version-string normalisation is shared via Schema so the admin next-major check no longer duplicates it.
The database version row was hardcoded to "MySQL Version" even when running MariaDB. Derive the label from the reported server version so MariaDB installs are labelled correctly. Also fix a method name typo.
Follow-up to the minimum-version bump, addressing review feedback: - Add Schema::getServerTypeFromVersion() and route the adapters and the DatabaseInformational diagnostic through it instead of duplicating the "mariadb" string check, so server-type detection lives in one place (alongside getComparableVersion()/getMinimumSupportedVersionForServer()). - Derive the required minimum purely from the reported server type rather than the configured schema, so the check is symmetric: a MySQL server is never held to the MariaDB minimum and vice versa, whichever schema is set. - Guard against a null server version (cast to string) so a missing version yields the friendly exception instead of a TypeError. - Show the normalised (comparable) version in the exception message so the MariaDB compatibility prefix no longer leaks into the error. - Refresh the now-inaccurate MySQL-only docblocks and drop two stale "5.7 or newer" notes in global.ini.php. - Make the adapter tests discriminating (a version between the MySQL and MariaDB minimums) and add a direct SchemaTest for the new helpers.
The test matrix ran against MySQL 5.7, which is below the new minimum, so the installer correctly rejected it and the Installation UI suite failed. Point the matrix and the UI jobs at the minimum supported versions (MySQL 8.0, MariaDB 10.6) so CI validates the actual floor.
- admin_diagnostics_configfile: the Config file diagnostic renders each setting's description from global.ini.php; reflects the updated DB-version wording in those comments. - email_reports: the scheduled-reports list now renders under MySQL 8.0, whose result ordering differs from 5.7 for equally-keyed rows (page content is unchanged).
Advances the CustomVariables pointer to the segmentMatchNONE test fix so the plugin's system tests pass on MySQL 8.0 (see plugin-CustomVariables branch dev-20334).
…rsion Plugin test workflows generated by generate:test-action call github-action-tests without a mysql-version, so they inherit the action's MySQL 5.7 default - below the new minimum, which makes the installer-backed jobs (PluginTests, UI, JS) fail. Emit mysql-engine/mysql-version pinned to the MySQL 8.0 floor for the database-backed jobs. Note: rolling this out requires regenerating each plugin's workflow; the template also lags the generated files in other respects (e.g. runner image), which should be reconciled in that rollout.
- PluginTests now runs a database matrix (MySQL 8.0 and MariaDB 10.6) so plugins are exercised against both supported engines at their minimum. - UI, JS and the core PHP jobs stay pinned to MySQL 8.0 only. - Bump the workflow runner image from ubuntu-20.04 to ubuntu-24.04, matching the runner the generated plugin workflows already use.
The Client job used Node 16, which the JS test runner no longer supports (crypto.getRandomValues is unavailable, so the runner fails to start). Match the Node 24 version core uses for its own Client tests.
TiDB support was an experiment that is not being pursued (it was never exposed in the installer and only reachable via a manual schema setting). Remove the dedicated Tidb schema class and its test, the TiDB UI-test environment, the DatabaseConfig::isTiDb() helper and its call sites in BatchInsert and the SqlDump fixture, the TiDB branch in Schema::getServerTypeFromVersion(), and the TiDB cases from the test data providers (unknown-type coverage now uses PostgreSQL as the example).
…-dev 6.x-dev also changed config/global.ini.php, which feeds the Config file diagnostic page, so the screenshot had to be regenerated to reflect both 6.x-dev's and this branch's global.ini.php changes.
PluginTests now runs a MySQL + MariaDB database matrix, so the existing upload-artifacts condition (php + maximum_supported_matomo) matched both legs and uploaded artifacts twice. Restrict the upload to the MySQL leg.
Removing TidbTest.php (TiDB removal) shifts the IntegrationTestsCore bucket split so that PivotByDimensionTest now runs immediately before DocumentationGeneratorTest in the same process. PivotByDimensionTest leaves a mock Proxy in the shared DI container via provideContainerConfig(), and DocumentationGeneratorTest (a plain TestCase that reads Proxy::getInstance() without rebuilding the container) then picks it up and fails. Restore a real Proxy in tearDown so the override can't leak - required for this branch to stay green given the reshuffle.
tzi
reviewed
Jul 20, 2026
tzi
reviewed
Jul 20, 2026
tzi
previously approved these changes
Jul 20, 2026
Match the new minimum supported version (was 5.7, which the installer now rejects). Applying it locally needs a 'ddev restart' (recreates the DB container).
sgiehl
enabled auto-merge (squash)
July 20, 2026 15:14
mneudert
approved these changes
Jul 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Raises the enforced minimum supported database version to MySQL 8.0 / MariaDB 10.6 for Matomo 6, and removes the experimental TiDB schema.
Until now the hard minimum enforced at install/connect was still
5.5(core/Db/Schema/Mysql.php/Mariadb.php), while the "next major" admin warning already pointed at 8.0 / 10.6. Since we're on6.0.0-b1, those become the actual minimums.Changes
Mysqlschema5.5→8.0,Mariadbschema5.5→10.6.checkServerVersion()(PDO + MySQLi adapters): the raw server string is normalised viaSchema::getComparableVersion()(stripping MariaDB's legacy5.5.5-compatibility prefix), the server type is detected viaSchema::getServerTypeFromVersion(), and the required minimum is chosen from the actual server type (Schema::getMinimumSupportedVersionForServer()) rather than the configured schema — so a MySQL server is never held to the MariaDB minimum and vice versa. The exception now names the real type and shows the normalised version. A missing server version yields the friendly exception instead of aTypeError.Schema;ControllerAdmindelegates its comparable-version helper there. The next-major soft-warning constants/behaviour are unchanged.Tidbschema class, its integration test and the TiDB UI-test environment; removedDatabaseConfig::isTiDb()and its call sites (BatchInsert, theSqlDumpfixture) and the TiDB branch ingetServerTypeFromVersion(); TiDB test-data cases dropped (unknown-type coverage now uses PostgreSQL). TiDB was never exposed in the installer and only reachable via a manual schema setting.README.mdand removed stale "5.7 or newer" notes inconfig/global.ini.php.ubuntu-24.04.PivotByDimensionTest(see below for why it's here).Why this PR touches
PivotByDimensionTestThis is not a DB change — it's a required side effect of removing TiDB. Removing TiDB deletes an
IntegrationTestsCoretest file (TidbTest.php), and CI splits that suite into 10 buckets by file list, so deleting a file re-partitions every bucket. The reshuffle movesDocumentationGeneratorTestinto bucket 3 immediately afterPivotByDimensionTest(it was in a different bucket before), and they then run in the same PHPUnit process.That exposes a pre-existing test-isolation leak:
PivotByDimensionTestswaps theProxysingleton in the shared DI container for a mock viaprovideContainerConfig()and never restores it;DocumentationGeneratorTestis a plainTestCasethat readsProxy::getInstance()without rebuilding the container, so it inherits the leaked mock and errors (Call to undefined method Mock_stdClass::shouldHideAPIMethod()).Fix:
PivotByDimensionTest::tearDown()restores a realProxy(the same cleanupReportTestalready does for its own override). Any PR that adds or removes anIntegrationTestsCoretest file could trip this same latent bug; fixing it here keeps the branch green.Tests
Added a direct
SchemaTestfor the new helpers (comparable version, server-type detection, minimum selection) and made the adaptercheckServerVersiontests discriminating (a MariaDB version that clears the MySQL floor but not the MariaDB floor). PHPStan / PHPCS clean.Submodule companion PRs (
dev-20334→prepare6x)Plugin test workflows are updated to run against the new DB versions; CustomVariables additionally carries a MySQL-8.0 test fix (date/time segments were compared to a placeholder string that 8.0 rejects).
Notes
NEXT_REQUIRED_MINIMUM_*constants inControllerAdminstay as-is; a future requirement raise is just bumping those constants plus the schemaminimumSupportedVersionvalues.Checklist