Closed SlyDave closed 5 years ago
some of this is resolved by publishing the migrations
php artisan vendor:publish --tag="cashier-migrations"
and I guess .1 above is solved by emptying the migration and having them as stubs...
There is one unfortunate side effect of this that isn't as easily overcome.
The original migration that was used before the migration was bundled has the same class name...
If I change the published migration, the package will use it's own version again. If I change my migration, it'll be seen as a new migration.
In my case, because I'm changing the CASHIER_MODEL I'm going to disable migrations from Cashier, and I can simply not use the published migrations. But for people not changing the model, this will present a difficult to overcome problem.
They will have to update their migration class name and filename to be different, then manually changed the migrations table setting the 'migration' to the new name.
That ignores all migrations, current and future. So isn't an ideal solution. Best I've found for people upgrading is to stub the initial migration with empty content.
This isn't an issue for fresh installs, just for people upgrading that already have a migration file to set up cashier.
Description:
Upgrading from Cashier 9 to 10 when migrations have already been applied causes funky behaviour.
php artisan migrate
without it failing due to the subscription table already existingPHP Fatal error: Cannot declare class CreateSubscriptionsTable, because the name is already in use in path\to\project\vendor\laravel\cashier\database\migrations\2019_05_03_000002_create_subscriptions_table.php on line 41