fix(sql): purge stranded legacy remote-storage columns (MySQL 8 safe) #210
Reference in New Issue
Block a user
Delete Branch "fix/purge-legacy-remote-columns"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
02.52.25.sqlusedDROP COLUMN IF EXISTS— a MariaDB-only extension that errors on Oracle MySQL 8.x. On MySQL 8 installs that migration failed, but Joomla still recorded the schema as applied, so the 26 legacyremote_storage/ftp_*/sftp_*/gdrive_*/s3_*columns were left stranded on the profiles table and will never be retried.Confirmed on suite.dev: MySQL 8.0.41, all 26 columns still present, 0 profiles with legacy remote data.
Fix
New
02.56.01.sqlmigration removes them portably and idempotently:INFORMATION_SCHEMA.COLUMNS(presence ofremote_storage, which tracks the whole set).ALTER … DROP COLUMN …(plain drop — valid on both MySQL 8 and MariaDB) via a prepared statement, executed only when the columns exist; otherwise aDO 0no-op.Assimilation into
#__mokosuitebackup_remoteswas intentionally omitted — no install has legacy remote data (the single-remote UI was removed back in 02.55.00), so there's nothing to migrate; the rows would be empty.Validation
Ran non-destructively against suite.dev (build +
PREPAREthe ALTER, thenDEALLOCATEwithout executing): gate returned1, the ALTER prepared cleanly on MySQL 8.0.41 — nothing was dropped.Note
suite.dev's schema is recorded at
02.52.29; this file (> 02.52.29) will run on the next extension update. If the schema-update chain is itself stuck there, the columns can also be dropped by running this ALTER directly — say the word and I'll apply it to suite.dev.