Inspirecms Core Laravel Package

Getting Started

InspireCMS v5.0.0 is a major release whose headline change is dependency alignment rather than new features: PHP >= 8.2, Laravel ^11.0 | ^12.0 | ^13.0, and Filament ^5.0 in the companion support package. Treat the upgrade as a dependency exercise first and a code exercise second.

Minimal adoption path:

1. Confirm your platform baseline. You must be on PHP 8.2+ and Laravel 11, 12, or 13. If you are still on Laravel 10, stay on the 4.x line.
2. Upgrade Filament to 5 first. The release notes explicitly require this before adopting InspireCMS v5. On a fresh install, bring Filament up first, then add the CMS.
3. Install the core package and its matching support package.

composer require solution-forest/inspirecms-core:^5.0

The core package links to the matching support package via self.version, so the two are intended to move in lockstep — do not pin one to ^5.0 and leave the other floating on ^4.x.

4. Clear all caches after the swap. This is not optional; config, route, view, and event caches routinely survive a major version change and produce phantom errors.

php artisan optimize:clear

5. Where to look first. In order: the published config file (for content model, disk, and route settings), the package service provider (for what is auto-registered and what is deferred), the Filament panel provider in the support package (for how admin resources are mounted), and the model layer (for observers and booted behavior).

6. First use case. The lowest-risk smoke test is a read-only one: boot the app, confirm the admin panel loads under Filament 5, and confirm a content listing renders. Validate that basic read path before touching writes, publishing workflows, or media handling.

Implementation Patterns

Pin the pair, not the package. Because core resolves the support package by self.version, treat inspirecms-core and its support package as a single unit in composer.json. Upgrading one without the other is the single most common way to get a class-not-found or a Filament resource that silently fails to register.

Stage the upgrade in a branch with a clean lockfile. Major version jumps in a package that touches the model layer are poor candidates for incremental composer update. Resolve from scratch, commit the lockfile, and diff the resolved versions to confirm both packages landed on 5.x.

Isolate observer and model-boot customization. Laravel 13 changes model booting behavior. Any place you have extended a CMS model with a booted()/boot() override, a custom observer, a global scope registered at boot, or a trait that hooks model events should be reviewed and tested explicitly. Move custom event wiring into a dedicated service provider or observer registration where possible, so it is not implicitly depending on boot ordering.

Keep your own code out of the package's internals. In a major release with a framework-compatibility focus, vendor internals are the least stable surface. Extend through published config, container bindings, and documented extension points (models, resources, service provider overrides) rather than subclassing deep internals.

Use the optimize:clear step in CI too. If you deploy via cached config and routes, add the cache clear to your deploy script rather than running it by hand once. A stale cache after a major upgrade behaves like a code bug and wastes debugging time.

Run Filament 5 migration work as its own change set. Filament major versions typically change resource/form/table APIs. Landing the Filament upgrade and the InspireCMS upgrade in one commit makes a failure ambiguous. Two commits, two green test runs.

Gotchas and Tips

• This is a breaking release. Read the changelog diff (4.0.10...5.0.0) rather than relying on the release summary; the summary is compatibility-focused and likely omits smaller signature and behavior changes.
• Filament 5 is a hard prerequisite. Adopting v5 while still on an older Filament will not resolve cleanly, and forcing it past the constraint will fail at runtime in the panel rather than at install time — which is harder to diagnose.
• Laravel 13 model booting is the highest-risk change for existing apps. If you have customized observers, scopes, or boot-time event registration, budget specific test coverage for create/update/delete flows and anything relying on observer ordering.
• self.version means the support package version follows the core version exactly. A composer resolution that produces a mismatched pair is worth treating as a build failure, not a warning.
• Cache clearing is a real fix, not a ritual. After upgrading, php artisan optimize:clear resolves a large class of "class not found," "route not defined," and "config value unchanged" symptoms. Always run it before debugging further.
• Debugging approach. When something breaks post-upgrade, bisect by layer in this order: (1) composer resolution and versions, (2) cleared caches, (3) Filament panel registration, (4) model/observer boot behavior, (5) application code. Reversing that order is the usual cause of long debugging sessions.
• Extension points to prefer. Published configuration, container bindings, published migrations, and Filament resource registration in the panel provider. These are the surfaces a framework-compatibility major release is most likely to preserve.
• Rollback plan. Because this is a major version bump with framework coupling, ensure you can revert the lockfile and the Filament version together. A partial rollback will leave you in a combination that was never intended to resolve.