[Ibochkarev]

Описание

До #698 InitialSchema не создавал fk_product_fields_section (проверка таблиц шла не по тому соединению). После #698 ключ появляется только на чистых установках. Старые сайты остаются без FK.

Добавлена идемпотентная repair-миграция 20260912120000_repair_product_fields_section_fk.php:

• FK уже есть → no-op;
• section = 0 → NULL (наследие каста 'main');
• положительные orphan id → RuntimeException со списком строк;
• затем добавляет FK с теми же правилами, что InitialSchema.

Решение записано в #711: чиним, расхождение схем не оставляем.

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

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

Связанные Issues

Closes #711

Связано: #695, #698

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

cd core/components/minishop3
php -l migrations/20260912120000_repair_product_fields_section_fk.php
php -l tests/Modx/PhinxSchemaLiveTest.php
php tests/MigrationSelfContainedTest.php

Exit codes: 0.

Live assert testProductFieldsSectionForeignKeyExists ожидает зелёный job modx-testbench в CI. Ручной апгрейд старой БД без FK в этом окружении не прогонялся.

• Ручное тестирование
• Автоматические тесты (composer ci:php / composer test, npm run lint:ci, composer stan / GitHub Actions CI)
• Тестирование на разных версиях PHP/MODX

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

• MiniShop3: ветка fix/issue-711-product-fields-section-fk
• MODX: CI testbench
• PHP: локальный CLI 8.x

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

До	После
n/a	n/a

Чеклист

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

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

• AC «проверено на тестовом сайте» — нужен maintainer-прогон апгрейда старой установки.
• Сайт с битыми положительными section увидит fail миграции со списком строк; это ожидаемо.

[biz87]

Влито. Проверил миграцию руками на dev-базе — это как раз «старый сайт» без fk_product_fields_section, с чистыми данными: 13 строк со ссылкой на раздел, 3 с NULL.

Шаг	Ключ	Миграция отмечена	Проверочная строка
исходно	нет	нет	NULL
section = 999999 → phinx migrate	нет, выход 1	нет	999999, не тронута
вернул NULL, поставил section = 0 → phinx migrate	создан, выход 0	да	NULL

Исключение называет строку: id=14 name=shops section=999999. Префиксы соблюдены: Phinx API без префикса, в сыром SQL — из table_prefix. Правила ключа совпадают с InitialSchema, повторный запуск безопасен.

На будущее, не блокеры

• Текст исключения перечисляет строки, но не говорит, что делать. При обновлении пакета оно попадёт только в лог, миграция не отметится и будет падать при каждом следующем обновлении. Стоит добавить подсказку: исправить section у этих строк — на существующий раздел или NULL — и повторить обновление.
• schema.xml: у section стоит null="false", и у колонки индекса тоже, а в src/Model/mysql/msProductField.php и на реальных базах колонка допускает NULL. Если модель когда-нибудь перегенерируют из XML, колонка тихо станет NOT NULL, и перевод 0 → NULL в этой миграции упадёт.
• Путь ремонта не покрыт live-тестом. testProductFieldsSectionForeignKeyExists смотрит чистую установку, где ключ после test(modx): схема live-сьюта из Phinx-миграций #698 есть и без этой миграции. Сценарий «удалить ключ → строка с section = 0 → up() → ключ есть, строка NULL» стоит добавить в live-сьют — сейчас он проверен только руками.

Попутно при проверке выяснилось, что phinx migrate на dev-сайте выполнил миграцию на Phinx из vendor mSearch, а не MiniShop3 — завёл #719.