Repository navigation
docs: simplify v2 upgrade instructions - #307
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 03cbf820f1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| 2. Set its filename timestamp immediately after the application's actual `create_feeds_table` migration and before any feed-registration migrations. Keep the `add_slug_to_feeds_table` suffix. This order also lets a fresh database create registrations after the slug column exists. | ||
| 3. Confirm that `feeds.table.connection` and `feeds.table.table` point to the existing registration table, then run migrations: | ||
| ```bash | ||
| php artisan vendor:publish --tag=feeds-migrations |
There was a problem hiding this comment.
Publish only the ordered slug migration
For applications upgrading from 1.x with the original table migration and generated feed-registration migrations, this command publishes both package migrations because LaravelFeedServiceProvider::migrations() maps the entire directory. Laravel 13 then replaces their timestamps with the publication time: unless the user identifies and removes the new create-table copy, migrate tries to create the existing table, and even after removing it the slug migration sorts after older registration migrations, so migrate:fresh runs registrations that write slug before that column exists. Restore the selective slug-file copy and explicitly place its timestamp after create_feeds_table but before feed-registration migrations.
Useful? React with 👍 / 👎.
What:
Description:
Replace manual migration copying in the v2 upgrade guide with
php artisan vendor:publish --tag=feeds-migrations. Explain that the command publishes all migration files and that developers must validate them and delete unnecessary files before running migrations. Require the new slug migration's filename timestamp to follow the application's actual create-table migration and precede every feed-registration migration, somigrate:freshadds the slug column before registrations write to it.Use
productsconsistently in generation and scheduling examples, with the matchingProductsregistration title. Update all eight translations, search indexes, andllms.txt.Validation: localization, metadata, snippets, TypeScript, and
git diff --checkpassed. The registration failure before the slug migration and success after it were reproduced with SQLite in memory. Full documentation build was blocked locally by SWC native binding cache permissions.