Перехід з 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
Міграція додає колонку slug, що дозволяє NULL, і заповнює її з наявних назв, включно з м’яко видаленими записами. Наявні назви та ідентифікатори зберігаються.
Якщо застосунок уже використовує власну колонку 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 видаляє лише цю колонку; він не відновлює перейменовані записи або вихідні файли. За потреби відновіть змінені дані реєстрацій і вихідні файли з резервних копій. Перед відновленням генерування перебудуйте кеш конфігурації та перезапустіть обробники черги й процеси планувальника.