fix(migrations): apply table prefix to Phinx metadata

[Ibochkarev]

Описание

Исправляет создание служебной таблицы Phinx для миграций MiniShop3: теперь default_migration_table учитывает MODX table_prefix, как и остальные таблицы компонента.

Без этого на установках с префиксом таблиц Phinx создавал ms3_migrations без префикса, что описано в issue #313.

Тип изменений

• Исправление бага (non-breaking change)
• Новая функциональность (non-breaking change)
• Breaking change (изменение, ломающее обратную совместимость)
• Рефакторинг (без изменения функциональности)
• Документация
• Другое (опишите):

Связанные Issues

Closes #313

Как это было протестировано?

Добавлен статический регрессионный тест PhinxMigrationTablePrefixTest.php, который загружает phinx.php с фейковым MODX-объектом и проверяет оба сценария: с table_prefix и без него.

• Ручное тестирование
• Автоматические тесты (PHPStan, ESLint)
• Тестирование на разных версиях PHP/MODX

Конфигурация тестирования:

• MiniShop3: текущая ветка beta
• MODX: не требуется для статического теста
• PHP: 8.4.17

Проверки:

php tests/PhinxMigrationTablePrefixTest.php
php -l phinx.php
php -l tests/PhinxMigrationTablePrefixTest.php

Скриншоты (если применимо)

Не применимо.

Чеклист

• Код соответствует стилю проекта
• Добавлены/обновлены комментарии в сложных местах
• Изменения не ломают существующую функциональность
• Лексиконы добавлены на двух языках (ru/en)
• PHPStan проходит без новых ошибок
• ESLint проходит без ошибок (для JS/Vue изменений)
• Обновлён CHANGELOG.md (для значимых изменений)

Дополнительные заметки

Лексиконы, ESLint и скриншоты не применимы: изменение затрагивает только PHP-конфиг Phinx и статический PHP-тест. CHANGELOG не обновлялся, так как записи в проекте добавляются при подготовке релиза.

PHPStan и PHPCS не запускались. IDE показывает существующие диагностики в phinx.php, не связанные с этой правкой: Intelephense не распознаёт modX, PHPCS ругается на формат заголовка файла.

[biz87]

Сразу скажу — в текущем виде PR вливать нельзя. Сам фикс правильный, но без переименования существующей таблицы он создаёт критический риск для всех установок с непустым table_prefix (а это большинство — у MODX дефолт modx_). У нас уже 500+ установок, ломать их апгрейдом неприемлемо.

Что произойдёт без RENAME

Сценарий апгрейда на одной из существующих установок с table_prefix='modx_':

1. В БД лежит таблица ms3_migrations (без префикса, ровно баг из [Bug] При создании таблицы ms3_migrations - не учитывается префикс #313).
2. Внутри — реестр всех применённых ранее миграций.
3. После апгрейда новый phinx.php конфигурирует default_migration_table = 'modx_ms3_migrations'.
4. Phinx ищет эту таблицу — нет.
5. Phinx считает «свежая установка, миграции не применялись» → пытается прогнать все миграции с нуля.
6. Создаёт пустую modx_ms3_migrations для трекинга.

Что произойдёт по миграциям:

• initial_schema — SHOW TABLES LIKE чек спасает, ок.
• alter_* — hasColumn чеки спасают, ок.
• Seed-миграции — идемпотентность у нас частичная:
  • seed_order_statuses — guard через COUNT(*) > 0, ок.
  • seed_*_grid_config после fix(migrations): defensive checks for ms3_grid_fields table #271/[Bug] Double table_prefix in PR #271 defensive checks — seed migrations become silent no-op everywhere #276 — guard'ы есть, но не идеальные.
  • update_orders_grid_status_fields (DELETE + INSERT) и подобные — могут продублировать данные.

В худшем случае: дубли seed-данных, ошибки на UNIQUE constraints, частичное применение, и Phinx запишет «всё применено», хотя реально часть прошла с ошибкой. Восстановление руками.

Плюс старая таблица ms3_migrations остаётся сиротой.

Что должен сделать PR

RENAME TABLE перед стартом Phinx-флоу. Логика:

if (table_prefix != '' && existsUnprefixed('ms3_migrations') && !existsPrefixed('<prefix>ms3_migrations')):
    RENAME TABLE ms3_migrations TO <prefix>ms3_migrations

Самое простое место — прямо в phinx.php, после построения $dbConfig:

if ($dbConfig['table_prefix'] !== '') {
    $prefix = $dbConfig['table_prefix'];
    $hasOld = (bool) $modx->pdo->query("SHOW TABLES LIKE 'ms3_migrations'")?->fetch();
    $hasNew = (bool) $modx->pdo->query("SHOW TABLES LIKE '{$prefix}ms3_migrations'")?->fetch();
    if ($hasOld && !$hasNew) {
        $modx->pdo->exec("RENAME TABLE `ms3_migrations` TO `{$prefix}ms3_migrations`");
        $modx->log(
            \MODX\Revolution\modX::LOG_LEVEL_INFO,
            '[MiniShop3] Renamed legacy Phinx metadata table ms3_migrations -> ' . $prefix . 'ms3_migrations'
        );
    }
}

Fix self-contained, всё в одном файле, рядом с источником конфига.

Альтернатива — то же самое в _build/resolvers/resolver_02_migrations.php перед вызовом Phinx. Тоже валидно, но добавляет +1 файл к ревью.

Тест нужно расширить

Текущий тест проверяет только новое имя таблицы. Нужны ещё кейсы (через мок PDO в том же anonymous-class паттерне):

• legacy ms3_migrations существует + prefixed не существует → ожидаем переименование
• оба существуют (повторный запуск или ручной фикс) → noop
• legacy не существует → noop (свежая установка)

Что нужно для мержа

1. RENAME-логика в phinx.php (или resolver_02_migrations.php).
2. Тесты на три сценария апгрейда.
3. Желательно — запись в CHANGELOG / release note: «при обновлении Phinx metadata table переименуется автоматически, действий от пользователя не требуется».

После этого — мержим без оговорок. Сам фикс точечный и правильный, проблема только в migration-path для существующих установок.

[biz87]

Закрыто всё:

• ✅ RENAME-логика в phinx.php с правильными guard'ами (table_prefix !== '', $modx->pdo !== null, $hasOld && !$hasNew).
• ✅ Тесты на все 4 сценария через mock PDO: legacy+!new → rename, both → noop, neither → noop, empty prefix → noop.
• ✅ php tests/PhinxMigrationTablePrefixTest.php — OK.
• ✅ php -l phinx.php — чисто.

Мелкий побочный момент — PhinxCharsetConfigTest от #308 теперь даёт PHP-warnings про undefined $pdo, потому что его fake modX не определял это свойство. Тест всё равно проходит, но шум. Можно поправить отдельным микропатчем или follow-up'ом. Не блокер.

Мержим.