Переход с 1.x на 2.x
Выполните эти шаги при переходе существующего приложения с Laravel Feeds 1.x на 2.x. Если установленная версия 1.x уже содержит slug фидов или обновлённые названия новых регистраций, сохраните эти изменения и пропустите выполненные шаги.
Требования к окружению
| Компонент | 1.x | 2.x |
|---|---|---|
| PHP | ^8.2 | ^8.4 |
| Компоненты Laravel | ^11.0 || ^12.0 || ^13.0 | ^13.0 |
Перед установкой 2.x обновите зависимости Laravel приложения и версии PHP для веб-приложения, CLI, планировщика и обработчиков очереди. Приложения на PHP 8.2 или 8.3, либо Laravel 11.x или 12.x, должны оставаться на 1.x. Требования к окружению приведены на странице совместимости.
Перед обновлением
- Сохраните текущий код приложения,
composer.json,composer.lockи опубликованныйconfig/feeds.php. Создайте резервную копию таблицы регистраций фидов и выходных файлов, необходимых для отката. - Запишите идентификаторы регистраций, названия, существующие slug, расписания и места выходных файлов.
- Найдите вызовы
feed:generateв скриптах развёртывания, заданиях cron, ручных расписаниях, тестах и коде приложения. - Сгенерируйте типовые фиды и сохраните их для сравнения.
- При развёртывании приостановите расписания фидов и завершите выполняемые задания и задания в очереди до замены пакета и изменения схемы.
Применение обновления
composer require dragon-code/laravel-feeds:^2.0 --with-all-dependencies
composer check-platform-reqs
Сравните config/feeds.php установленного пакета с опубликованной копией приложения и сохраните настройки приложения. Не публикуйте повторно с --force: это перезаписывает копию.
Добавление slug фидов
PR #287 меняет выбор одного фида: вместо идентификатора базы данных используется slug, полученный через Str::slug(title).
Если миграция slug пакета ещё не выполнена, опубликуйте миграции:
php artisan vendor:publish --tag=feeds-migrations
Команда публикует все файлы миграций. Проверьте опубликованные файлы и удалите лишние.
Задайте дату и время в имени файла новой миграции add_slug_to_feeds_table так, чтобы она шла после фактической миграции create_feeds_table приложения и перед всеми миграциями регистрации фидов. Тогда migrate:fresh добавит колонку slug до записи регистраций. Затем выполните миграции:
php artisan migrate
Миграция добавляет nullable-колонку slug и заполняет её из существующих названий, включая мягко удалённые записи. Существующие названия и идентификаторы сохраняются.
Если приложение уже использует собственную колонку slug, а миграция пакета ещё не выполнена, миграция завершится ошибкой до заполнения данных. Разрешите конфликт схемы до развёртывания; не удаляйте колонку приложения без сохранения её данных и обновления кода, который её использует.
Посмотрите сохранённые значения в php artisan tinker:
app(\DragonCode\LaravelFeed\Queries\FeedQuery::class)
->all()
->get(['id', 'title', 'slug']);
Slug для выбора фидов должны быть непустыми и различаться среди всех неудалённых регистраций, включая неактивные. Разные названия могут преобразоваться в одинаковый slug. Неоднозначный поиск вызывает MultipleRecordsFoundException; неизвестный slug — FeedNotFoundException. Исправьте коллизии или пустые slug, обновив названия через модель фида.
В 2.3.0 PR #334 заменяет переопределение fireModelEvent() на FeedObserver::saving(). Раньше slug вычислялся из сырых атрибутов после saving, creating и updating, включая тихое сохранение. Теперь используется название с учётом accessor в момент выполнения saving-observer; тихое сохранение пропускает его, а поздние обработчики не вызывают повторный пересчёт.
PR #335 добавляет проверку $feed->isDirty('slug'): явно изменённый slug нормализуется через Str::slug() и сохраняется при текущем сохранении, даже если одновременно меняется title. FeedQuery::create() принимает его через extra: ['slug' => 'Custom Catalog']. Неизменённый slug по-прежнему вычисляется из title, поэтому следующее обычное сохранение может заменить ранее заданный пользовательский slug. Присваивание значения, которое нормализуется в текущий slug, не предотвращает пересчёт.
При обновлении с более ранней версии 1.x или 2.x проверьте явные присваивания slug, тихие сохранения, accessors названия, обработчики событий, частичные выборки, пользовательские casts и массовые записи. Протестируйте сохранённые title и slug, следующее обычное сохранение, поиск по slug и генерацию по расписанию. Установка обновления сама не меняет строки, но следующее обычное сохранение может изменить пользовательский slug или slug из accessor даже без изменения названия. При необходимости обновите slug в командах и расписаниях. Примеры явного задания slug, тихого сохранения и работы с обработчиками приведены в Eloquent.
Замена ID в вызовах генерации
Для регистрации с ID 42 и сохранённым названием Products slug после миграции будет products.
До:
php artisan feed:generate 42
После:
php artisan feed:generate products
В 2.x аргумент всегда означает slug; числовая строка больше не выбирает запись по ID базы данных. Вызов php artisan feed:generate без аргумента по-прежнему обрабатывает все активные регистрации. При использовании --target замените только аргумент регистрации; ключи целей остаются прежними:
php artisan feed:generate products --target=42
Так же обновите ручные расписания и программные вызовы команды. До:
use DragonCode\LaravelFeed\Commands\FeedGenerateCommand;
use Illuminate\Support\Facades\Schedule;
Schedule::command(FeedGenerateCommand::class, [42])->daily();
После:
use DragonCode\LaravelFeed\Commands\FeedGenerateCommand;
use Illuminate\Support\Facades\Schedule;
Schedule::command(FeedGenerateCommand::class, ['products'])->daily();
Сохраните настройки защиты от одновременного запуска, фонового выполнения и частоты ручного расписания. При переименовании регистраций обновляйте slug, указанные в коде. ScheduleFeedHelper::register() автоматически использует сохранённые slug и сохраняет привязку блокировок к регистрации при изменении её названия или выражения cron.
FeedQuery::find(int $id), delete(int $id) и restore(int $id) по-прежнему используют ID. Для выбора по slug используйте FeedQuery::findBySlug(string $slug). См. генерацию и расписания.
Проверка создаваемых названий
PR #293 удаляет суффикс Feed из названий в новых миграциях регистрации или операциях развёртывания, создаваемых командой make:feed.
Для php artisan make:feed ProductsFeed:
| Значение | До | После |
|---|---|---|
| Создаваемое название регистрации | Products Feed | Products |
| Slug из этого названия | products-feed | products |
Существующие названия в базе данных и ранее созданные файлы регистрации не перезаписываются. Используйте фактический сохранённый slug каждой регистрации. Это изменение названий не меняет имя класса фида и имя выходного файла.
Документация и разработка пакета
PR #294 переименовывает страницу документации Machine Learning в ИИ-агенты. Страница теперь доступна по адресу /ai-agents/; перенаправления сохраняют работу ссылок на прежний URL.
PR #297 задаёт новые требования к окружению и сохраняет документацию 1.x. Выберите версию документации, которая соответствует установленному пакету; результаты поиска и контекст LLM ограничены этой версией.
Среда разработки самого пакета переходит на Pest ^5.0 и Testbench ^11.0. Команды Pest пакета используют --tia, а для полного повторного запуска в CI, бенчмарках и обновлении снимков — --fresh. Это зависимости разработки пакета, а не требования к тестам приложения.
Проверка
- Пересоберите кеш конфигурации приложения, если он используется, и перезапустите обработчики очереди и долгоживущие процессы планировщика с новым кодом.
- Убедитесь, что у каждой выбираемой регистрации непустой уникальный slug и что команды и ручные расписания используют его.
- Сгенерируйте фид каждого используемого формата; сравните количество разделённых файлов, имена и типовое содержимое с сохранённым результатом
1.x. - Проверьте выбор целей, автоматические и ручные расписания, а также генерацию через очередь, если они используются.
- Запустите тесты приложения для пользовательских моделей фидов, преобразователей, макросов и классов предустановок.
- Возобновите расписания фидов и обработку очереди после успешной проверки схемы и генерации.
Откат
Снова приостановите генерацию фидов и завершите выполняемые задания. Восстановите предыдущие код приложения, composer.json, composer.lock, конфигурацию и команды генерации, затем выполните composer install в совместимом окружении.
Применяйте политику отката миграций приложения только после проверки, использует ли восстанавливаемый пакет 1.x slug. Метод down() миграции slug удаляет только эту колонку; он не восстанавливает переименованные записи или выходные файлы. При необходимости восстановите изменённые данные регистраций и выходные файлы из резервных копий. Перед возобновлением генерации пересоберите кеш конфигурации и перезапустите обработчики очереди и процессы планировщика.