The issue appeared after activating 10.11
Here is a summary of the issue and how we resolved it.
Local’s add-on loader dedupes by name only:
isAddonLoaded(name, version) {
const loadedAddon = this.loadedAddons.find((addon) => addon.name === name);
if (!loadedAddon) return false;
return compareVersionWithBuild(loadedAddon.version, version) >= 0; // skip if loaded >= candidate
}
Every MariaDB package declares "name": "mariadb", so they all collide. Folders load alphabetically, and mariadb-10.11.18+0 sorts first (10.11 < 10.4 < 10.6 as strings) and is the highest version — so it loaded and shadowed all the others. Previously the first-enumerated was 10.4.10, the lowest, so every later version compared greater and loaded fine. Adding 10.11 inverted the whole thing.
Skipped services never enter _registeredServices → getSiteServiceByRole(site,'db') returns null → .preprovision() on null. The “Missing MariaDB v10.6” banner and the download loop were both downstream symptoms.
The fix
Renamed mariadb-10.11.18+0 → zz-mariadb-10.11.18+0 so it enumerates last. Service identity comes from package.json, not the folder name, so this is safe — and all four now load cleanly. No app patching, nothing that Local’s asar integrity check would reject.
isAddonLoaded(name, version) {
const loadedAddon = this.loadedAddons.find(
(addon) => addon.name === name && addon.version === version);
return Boolean(loadedAddon);
}
Now that this is solved it will be great if you also package in a next release MariaDB 11.8 or 11.4 at a minimum for all of us who are working using embeddings and require this functionality.
Right now we are “forced” to bypass the WP Local’s db instance and connect with our own DBs.
It will also be great if we can at least have the option to connect to an external DB so that there will be no need for your VM to start a DB instance we do not use.
