fix(migrations): восстановление полей заказа/адреса при неполных seed-данных

[Ibochkarev]

Описание

Добавлена Phinx-миграция 20260420120000_repair_order_model_fields_if_missing, которая при установке/обновлении MiniShop3 восстанавливает записи в ms3_model_fields и ms3_model_field_sections для моделей msOrder и msOrderAddress, если начальные seed-миграции не отработали полностью либо в БД осталась «дырявая» схема (в менеджере пустые вкладки заказа или сообщение ms3_model_fields_empty).

Логика соответствует SeedModelFields + SeedModelFieldSections: проверяется полный набор полей из сидов (для заказа: status_id, delivery_id, payment_id, customer_id, order_comment; для адреса — все 16 полей из исходного сида), идемпотентные вставки только недостающих строк, затем выставление section_id и width только для строк, где section_id IS NULL, чтобы не затирать ручные настройки в Utilities → Fields.

Почему timestamp 20260420120000: в beta уже есть миграция 20260417120000_add_caption_description_to_category_options.php (#205); у Phinx версия в phinxlog — по префиксу timestamp, совпадение ломало бы порядок/запуск репаратора.

Записи в CHANGELOG.md в feature-PR по правилам проекта не добавляются (отдельный release-PR).

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

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

Связанные Issues

Связанного issue нет (сценарий выявлен при интеграции сторонних компонентов и неполных миграциях).

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

Проверена синтаксическая корректность PHP (php -l) для файла миграции. Прогон миграции на стенде с пустой/обрезанной таблицей ms3_model_fields рекомендуется ревьюеру при мерже.

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

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

• MiniShop3: ветка beta + данный PR
• MODX: —
• PHP: php -l для миграции

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

До	После

Чеклист

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

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

down() миграции намеренно пустой: откат не удаляет восстановленные дефолтные поля, чтобы не ломать уже исправленные инсталляции.

[biz87]

Ревью

Задача полезная — self-heal для сломанных/неполных seed-данных. Но есть один блокер и пара замечаний.

🚨 Блокер: коллизия timestamp с миграцией из beta

Файл миграции в PR: `20260417120000_repair_order_model_fields_if_missing.php`

В beta уже замерджен (из PR #205) файл с тем же timestamp:
`20260417120000_add_caption_description_to_category_options.php`

Phinx хранит `version` в `phinxlog` как timestamp — две миграции с одинаковым префиксом либо конфликтуют при записи в лог, либо одна из них молча пропускается. На проекте, где первая уже применена, репаратор не запустится вообще.

Нужно переименовать файл — например `20260420120000_...` или `20260417120100_...` (позже уже влитого файла).

---

⚠️ Важное: миграция перезаписывает пользовательские настройки

В `updateOrderFieldSections` / `updateAddressFieldSections` update безусловный:

```php
$this->execute(
"UPDATE {$this->prefix}ms3_model_fields SET section_id = {$sectionId}, width = {$update['width']} " .
"WHERE model = 'msOrder' AND name = '{$n}'"
);
```

Если админ вручную перенастроил секции/ширины через Utilities → Fields, а потом запустилась эта миграция (scenario: апгрейд компонента в окружении где миграция ещё не была выполнена) — его настройки будут затёрты.

Правильнее — условный update, только если section_id IS NULL:

```sql
UPDATE ... SET section_id = ?, width = ? WHERE model = ? AND name = ? AND section_id IS NULL
```

Либо выставлять section_id/width в insert'е (там где null не перепишет существующее), а update убрать.

---

Minor

1. SQL-сборка через интерполяцию — технически безопасно (все значения хардкод в самой миграции, нет внешнего ввода), но стоит использовать prepared statements для единообразия с остальным кодом:
   ```php
   $this->adapter->query("SELECT ... WHERE name = ?", [$name]);
   ```

2. `needsOrderRepair` проверяет только 3 поля (`status_id, delivery_id, payment_id`). Если эти есть, а `customer_id` или `order_comment` отсутствует, миграция ничего не сделает. Но insert-методы уже idempotent (check-then-insert), так что guard можно упростить или убрать совсем — это лишь optimisation fast-path.

3. Отсутствует CHANGELOG-запись в `core/components/minishop3/docs/changelog.txt` (есть только в корневом CHANGELOG.md).

---

Итого

После фикса timestamp + условного update — можно мержить. Остальное — nit.

[biz87]

Поправка к моему ревью: снимаю nit #3 про docs/changelog.txt — по правилам проекта записи в CHANGELOG делаются отдельным release-PR, а не в feature-PR.

По той же причине запись в корневом CHANGELOG.md (которая добавлена в этот PR) стоит убрать.

[biz87]

Все существенные замечания учтены:

• Блокер timestamp — ✅ переименован на 20260420120000, коллизии с уже мерджнутым нет
• Безусловный UPDATE — ✅ добавлено AND section_id IS NULL, пользовательские настройки секций/ширин не затираются
• CHANGELOG.md — ✅ убран по политике

Бонусом упрощён guard needsOrderRepair и вынесены helper-методы — код стал чище и покрывает весь список ожидаемых полей вместо 3 хардкод.

LGTM 👍