Skip to content

Upgrade to Laravel 11 - #368

Open
dan-tang-ssd wants to merge 42 commits into
devfrom
upgrade-to-laravel-11
Open

Upgrade to Laravel 11#368
dan-tang-ssd wants to merge 42 commits into
devfrom
upgrade-to-laravel-11

Conversation

@dan-tang-ssd

@dan-tang-ssd dan-tang-ssd commented Jul 22, 2026

Copy link
Copy Markdown
Member

This PR is submitted to upgrade Laravel from 10 to 11.

After checking with Claude, it is recommended to upgrade Laravel from 10 to 11, 11 to 12, 12 to 13 instead of upgrading from 10 to 13 directly.

It is not yet ready for review. It is submitted for progress update.


Claude's response:

Go incremental (10→11→12→13) — and it looks like you've already started down that path: your working composer.json diff shows laravel/framework bumped to ^11.0 and backpack/crud to ^6.0, with laravel/telescope also nudged for compatibility.

Why incremental is the right call here:

  • Laravel's official upgrade guides are only ever written version-to-version (10→11, 11→12, 12→13). Skipping straight to 13 means you're manually merging three guides' worth of breaking changes with no official "10→13" doc to check against.
  • This app leans heavily on Backpack CRUD/PRO plus your own forks pinned to dev-branches (dev-backpack-5, dev-laravel-9-support). Backpack's major versions are gated to specific Laravel versions, so you'll likely need a Backpack major bump at each Laravel step anyway — doing one dependency jump at a time makes it obvious which upgrade broke what.
  • Each hop leaves you with a testable, deployable checkpoint, so regressions are cheap to bisect (git bisect across 3 small PRs vs. one giant one).

Main con of incremental: more total PRs/composer-update cycles and more time spent re-running the test suite at each stage — but given the Backpack dependency chain, that overhead buys real safety.

Con of direct 10→13: composer will likely just refuse to resolve in one shot (packages like Backpack won't have a single version spanning Laravel 10 through 13), and even if you forced it, you'd be debugging three majors' worth of breaking changes simultaneously with no incremental green checkpoint.

Given you're already on the incremental branch (upgrade-to-laravel-11), I'd just continue that pattern: land 11 cleanly, merge to dev, then branch for 12, then 13.

@dave-mills

Copy link
Copy Markdown
Member

Seems like a decent plan.

I disagree with Claude on a few points, particularly:

  • Each hop leaves you with a testable, deployable checkpoint;

It might be technically deployable, but we'll have regressed in features by removing Backpack Pro; we won't have a publishable version until we get to the end of the process.

Also, make sure you've considered how much time it's worth putting into doing upgrades to Backpack - 5 to 6 and 6 to 7 are non-trivial, we'd lose features that are Pro-only so we won't have feature parity anyway, and spending time fixing / fully testing the app on those newer versions is time lost because we're moving to Filament.

If you're definitely going incrementally, then it might be worth not getting all the way to Laravel 13 before bringing in Filament; Filament 5 runs on a version of Laravel 11, so that's an option to consider, that skips the later Backpack requirements.

@dave-mills

Copy link
Copy Markdown
Member

Also - I just tried running the test suite locally, and got lots of fails. It looks like there's a significant bug in the tests since we moved to "teams" mode in the Spatie Permissions package - All class-based tests don't get the context of the 'current organisation', so when trying to do the setup functions like "setupSiteAdminUser()" etc, it tries to add "organisation_id=null" into the database, which fails due to the db-level constraints.

So the test suite needs fixing before it's useful again. I would recommend also adding a github workflow to auto-run the tests on every PR or push to dev; like we do on other apps.

@dan-tang-ssd

Copy link
Copy Markdown
Member Author

Seems like a decent plan.

I disagree with Claude on a few points, particularly:

* Each hop leaves you with a testable, deployable checkpoint;

It might be technically deployable, but we'll have regressed in features by removing Backpack Pro; we won't have a publishable version until we get to the end of the process.

Yes. There are many broken pages after removing Backpack Pro.
With backpack 6, we will need to install backpack's theme from a separate package. Some pages are recovered after that. (I will submit another PR for that)
At this point, I think we may start working on migrating pages from backpack to filament.

Also, make sure you've considered how much time it's worth putting into doing upgrades to Backpack - 5 to 6 and 6 to 7 are non-trivial, we'd lose features that are Pro-only so we won't have feature parity anyway, and spending time fixing / fully testing the app on those newer versions is time lost because we're moving to Filament.

Yes. I think we do not need to upgrade Backpack from 6 to 7. It is good enough to upgrade Backpack from 5 to 6. Then start migrating pages from backpack to filament.

If you're definitely going incrementally, then it might be worth not getting all the way to Laravel 13 before bringing in Filament; Filament 5 runs on a version of Laravel 11, so that's an option to consider, that skips the later Backpack requirements.

We have upgraded to Laravel 11 in this branch. Both backpack 6 and filament 5 can run on it.
The main thing is to get rid of backpack and move to filament completely.
We can start migrating pages on Laravel 11 first. Update to Laravel 13 can be the next step.

@dan-tang-ssd

Copy link
Copy Markdown
Member Author

Also - I just tried running the test suite locally, and got lots of fails. It looks like there's a significant bug in the tests since we moved to "teams" mode in the Spatie Permissions package - All class-based tests don't get the context of the 'current organisation', so when trying to do the setup functions like "setupSiteAdminUser()" etc, it tries to add "organisation_id=null" into the database, which fails due to the db-level constraints.

So the test suite needs fixing before it's useful again. I would recommend also adding a github workflow to auto-run the tests on every PR or push to dev; like we do on other apps.

Yes, the test suite needs refinement. It takes a very long duration to run in my local env...

@dan-tang-ssd dan-tang-ssd mentioned this pull request Aug 19, 2026
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants