Upgrade von 1.x auf 2.x

Befolgen Sie diese Schritte beim Umstieg einer bestehenden Anwendung von Laravel Feeds 1.x auf 2.x. Wenn Ihre installierte Version von 1.x bereits Feed-Slugs oder die aktualisierten erzeugten Titel enthält, behalten Sie diese Änderungen bei und überspringen Sie die abgeschlossenen Schritte.

Laufzeitanforderungen

Komponente	1.x	2.x
PHP	^8.2	^8.4
Laravel-Komponenten	^11.0 || ^12.0 || ^13.0	^13.0

Aktualisieren Sie vor der Installation von 2.x die Laravel-Abhängigkeiten der Anwendung und die PHP-Laufzeitumgebungen für Webanwendung, CLI, Scheduler und Queue-Worker. Anwendungen mit PHP 8.2 oder 8.3 oder Laravel 11.x oder 12.x müssen bei 1.x bleiben. Die unterstützte Umgebung ist unter Kompatibilität beschrieben.

Vor dem Upgrade

1. Sichern Sie den aktuellen Anwendungscode, composer.json, composer.lock und die veröffentlichte config/feeds.php. Erstellen Sie Sicherungen der Feed-Registrierungstabelle und der erzeugten Dateien, die für ein Zurücksetzen benötigt werden.
2. Erfassen Sie Registrierungs-IDs, Titel, bestehende Slugs, Zeitpläne und Ausgabeziele.
3. Suchen Sie Aufrufe von feed:generate in Deployment-Skripten, Cron-Jobs, manuellen Zeitplänen, Tests und im Anwendungscode.
4. Erzeugen Sie repräsentative Feeds und bewahren Sie ihre Ausgabe zum Vergleich auf.
5. Pausieren Sie beim Deployment die Feed-Zeitpläne und lassen Sie laufende oder eingereihte Feed-Jobs abschließen, bevor Sie das Paket ersetzen und das Schema ändern.

Update anwenden

composer require dragon-code/laravel-feeds:^2.0 --with-all-dependencies
composer check-platform-reqs

Vergleichen Sie config/feeds.php des installierten Pakets mit der veröffentlichten Kopie der Anwendung und behalten Sie anwendungsspezifische Einstellungen bei. Veröffentlichen Sie nicht erneut mit --force: Dies überschreibt diese Kopie.

Feed-Slugs hinzufügen

PR #287 ändert die Auswahl einzelner Feeds von einer Datenbank-ID zu einem mit Str::slug(title) erzeugten Slug.

Wenn die Slug-Migration des Pakets noch nicht ausgeführt wurde, veröffentlichen Sie die Migrationen:

php artisan vendor:publish --tag=feeds-migrations

Der Befehl veröffentlicht alle Migrationsdateien. Prüfen Sie die veröffentlichten Dateien und löschen Sie nicht benötigte Dateien.

Setzen Sie den Zeitstempel im Dateinamen der neuen Migration add_slug_to_feeds_table nach der tatsächlichen Migration create_feeds_table der Anwendung und vor allen Migrationen zur Feed-Registrierung. Diese Reihenfolge stellt sicher, dass migrate:fresh die Slug-Spalte hinzufügt, bevor Registrierungen in sie schreiben. Führen Sie anschließend die Migrationen aus:

php artisan migrate

Die Migration fügt eine Spalte slug hinzu, die NULL-Werte zulässt, und füllt sie aus bestehenden Titeln, einschließlich vorläufig gelöschter Datensätze. Bestehende Titel und IDs bleiben erhalten.

Warnung

Wenn die Anwendung bereits eine eigene Spalte slug besitzt und die Paketmigration noch nicht ausgeführt wurde, schlägt die Migration fehl, bevor Daten nachgetragen werden. Lösen Sie diesen Schemakonflikt vor dem Deployment; löschen Sie keine anwendungseigene Spalte, ohne ihre Daten zu sichern und ihre Aufrufer zu aktualisieren.

Prüfen Sie gespeicherte Werte in php artisan tinker:

app(\DragonCode\LaravelFeed\Queries\FeedQuery::class)
    ->all()
    ->get(['id', 'title', 'slug']);

Für die Auswahl verwendete Slugs müssen unter allen nicht gelöschten Registrierungen, einschließlich inaktiver Registrierungen, unterschiedlich und nicht leer sein. Unterschiedliche Titel können denselben normalisierten Slug ergeben. Mehrdeutige Suchen lösen MultipleRecordsFoundException aus; unbekannte Slugs lösen FeedNotFoundException aus. Beheben Sie Kollisionen oder leere Slugs, indem Sie Titel über das Feed-Modell aktualisieren.

In 2.3.0 ersetzt PR #334 die Überschreibung von fireModelEvent() durch FeedObserver::saving(). Zuvor wurde der Slug nach saving, creating und updating aus rohen Attributen abgeleitet, auch bei stillem Speichern. Jetzt zählt der Titel einschließlich Accessor zum Zeitpunkt des Saving-Observers; stilles Speichern überspringt ihn, spätere Listener lösen keine Neuberechnung aus.

PR #335 ergänzt eine Prüfung mit $feed->isDirty('slug'): Ein explizit geänderter Slug wird mit Str::slug() normalisiert und bleibt für den aktuellen Speichervorgang erhalten, auch wenn sich title ebenfalls ändert. FeedQuery::create() akzeptiert ihn über extra: ['slug' => 'Custom Catalog']. Ein unveränderter Slug wird weiterhin aus title abgeleitet; ein späterer normaler Speichervorgang kann daher einen zuvor gesetzten eigenen Slug ersetzen. Die Zuweisung eines Werts, der zum aktuellen Slug normalisiert wird, verhindert die Neuberechnung nicht.

Prüfen Sie beim Upgrade von einer früheren Version von 1.x oder 2.x explizite Slug-Zuweisungen, stille Speichervorgänge, Titel-Accessors, Ereignis-Listener, Teilabfragen, eigene Casts und Massenschreibvorgänge. Testen Sie gespeicherte Titel und Slugs, einen späteren normalen Speichervorgang, Slug-Suche und geplante Generierung. Die Installation des Updates allein ändert keine Datensätze; der nächste normale Speichervorgang kann jedoch einen eigenen oder per Accessor abgeleiteten Slug ohne Titeländerung ändern. Passen Sie bei Bedarf fest eingetragene Slugs in Befehlen und Zeitplänen an. Beispiele für explizite Slugs, stilles Speichern und Listener stehen unter Eloquent.

IDs in Generierungsaufrufen ersetzen

Für die Registrierungs-ID 42 mit dem gespeicherten Titel Products lautet der migrierte Slug products.

Vorher:

php artisan feed:generate 42

Nachher:

php artisan feed:generate products

In 2.x ist das Argument immer ein Slug; eine numerische Zeichenfolge wählt keine Datenbank-ID mehr aus. Der Aufruf von php artisan feed:generate ohne Argument verarbeitet weiterhin alle aktiven Registrierungen. Ersetzen Sie bei --target nur das Registrierungsargument; die Zielschlüssel bleiben gleich:

php artisan feed:generate products --target=42

Aktualisieren Sie manuelle Zeitpläne und programmatische Befehlsaufrufe auf dieselbe Weise. Vorher:

use DragonCode\LaravelFeed\Commands\FeedGenerateCommand;
use Illuminate\Support\Facades\Schedule;

Schedule::command(FeedGenerateCommand::class, [42])->daily();

Nachher:

use DragonCode\LaravelFeed\Commands\FeedGenerateCommand;
use Illuminate\Support\Facades\Schedule;

Schedule::command(FeedGenerateCommand::class, ['products'])->daily();

Behalten Sie bei manuellen Zeitplänen die bestehenden Einstellungen für Überschneidungen, Hintergrundausführung und Häufigkeit bei. Aktualisieren Sie fest eingetragene Slugs, wenn Sie Registrierungen umbenennen. ScheduleFeedHelper::register() verwendet gespeicherte Slugs automatisch und hält Überschneidungssperren an die Registrierung gebunden, wenn sich ihr Titel oder Cron-Ausdruck ändert.

FeedQuery::find(int $id), delete(int $id) und restore(int $id) verwenden weiterhin IDs. Verwenden Sie für die Auswahl per Slug FeedQuery::findBySlug(string $slug). Siehe Generierung und Zeitplanung.

Erzeugte Titel prüfen

PR #293 entfernt das Suffix Feed aus Titeln, die make:feed in neue Registrierungsmigrationen oder Deployment-Operationen schreibt.

Für php artisan make:feed ProductsFeed:

Wert	Vorher	Nachher
Erzeugter Registrierungstitel	Products Feed	Products
Aus diesem Titel abgeleiteter Slug	products-feed	products

Bestehende Datenbanktitel und zuvor erzeugte Registrierungsdateien werden nicht umgeschrieben. Verwenden Sie weiterhin den tatsächlich gespeicherten Slug jeder Registrierung. Der Name der Feed-Klasse und der Ausgabedateiname ändern sich durch diese Titelanpassung nicht.

Dokumentation und Paketentwicklung

PR #294 benennt die Dokumentationsseite von Maschinelles Lernen in KI-Agenten um. Die Seite ist jetzt unter /ai-agents/ verfügbar; Weiterleitungen erhalten Links zur bisherigen URL.

PR #297 legt die neuen Laufzeitanforderungen fest und bewahrt die Dokumentation für 1.x. Wählen Sie die Dokumentationsversion passend zum installierten Paket; Suchergebnisse und LLM-Kontext sind auf diese Version begrenzt.

Die eigene Entwicklungsumgebung des Pakets wechselt zu Pest ^5.0 und Testbench ^11.0. Seine Pest-Befehle verwenden --tia, zusammen mit --fresh für vollständige Wiederholungen in CI, Benchmarks und Snapshot-Aktualisierungen. Dies sind Entwicklungsabhängigkeiten des Pakets und keine Anforderungen an die Testsuite einer Anwendung.

Prüfen

• Erstellen Sie bei Bedarf den Konfigurationscache der Anwendung neu und starten Sie Queue-Worker und dauerhaft laufende Scheduler-Prozesse mit dem neuen Code neu.
• Prüfen Sie, ob jede ausgewählte Registrierung einen nicht leeren, eindeutigen Slug hat und ob Befehle und manuelle Zeitpläne ihn verwenden.
• Erzeugen Sie je einen Feed für jedes verwendete Format; prüfen Sie Anzahl und Namen aufgeteilter Dateien sowie repräsentative Ausgaben im Vergleich zur gespeicherten Ausgabe von 1.x.
• Prüfen Sie die Zielauswahl, automatische und manuelle Zeitpläne sowie die Generierung über Queues, soweit verwendet.
• Führen Sie Anwendungstests für benutzerdefinierte Feed-Modelle, Transformer, Makros und Unterklassen von Voreinstellungen aus.
• Setzen Sie Feed-Zeitpläne und die Queue-Verarbeitung fort, nachdem Schema- und Generierungsprüfungen erfolgreich abgeschlossen sind.

Zurücksetzen

Pausieren Sie die Feed-Generierung erneut und lassen Sie laufende Jobs abschließen. Stellen Sie den vorherigen Anwendungscode, composer.json, composer.lock, die Konfiguration und die Generierungsbefehle wieder her und führen Sie dann composer install mit einer kompatiblen Laufzeitumgebung aus.

Wenden Sie die Migrations-Rollback-Richtlinie der Anwendung erst an, nachdem Sie geprüft haben, ob das wiederhergestellte Paket der Reihe 1.x bereits Slugs verwendet. Die Methode down() der Slug-Migration entfernt nur diese Spalte; sie stellt weder umbenannte Titel noch erzeugte Dateien wieder her. Stellen Sie geänderte Registrierungsdaten und Ausgabedateien bei Bedarf aus den Sicherungen wieder her. Erstellen Sie Konfigurationscaches neu und starten Sie Worker und Scheduler-Prozesse neu, bevor Sie die Generierung fortsetzen.

Siehe auch

• Kompatibilität
• Generierung und Zeitplanung
• Konfigurationsreferenz