Laravel Cms Laravel Package

Getting Started

This is a patch release (1.4.7) with no new public API and no documented breaking changes. If you are already on 1.4.x, upgrading is a low-risk composer update.

1. Upgrade within the existing constraint — composer require <vendor>/<package>:^1.4 (or just composer update <vendor>/<package> if it is already required). Do not loosen the constraint to * just to pick this up.
2. Clear the caches the package depends on. Plugin-style packages almost always touch container bindings or the provider manifest, so after upgrading run:

   composer dump-autoload
   php artisan clear-compiled
   php artisan config:clear
   php artisan cache:clear
   php artisan package:discover   # Laravel 8 manifest rebuild
   

   If the app runs with cached config/routes in production, re-run php artisan config:cache / route:cache as part of your deploy after the update.
3. Where to look first. Read the package's composer.json (require block confirms the Laravel 8.x / PHP constraint) and its service provider. The provider is the best map of what this release actually changed, since the notes only say "fix bugs to make plugins work better in Laravel 8.x".
4. Verify the fix, don't assume it. The release note is a compatibility fix, not a feature. Before shipping, reproduce the plugin behaviour you care about on 1.4.7 — a previously broken plugin should now boot/register, and one that already worked should be unchanged.

First use case: take the plugin that was misbehaving under Laravel 8.x (the one that motivated you to look at this release), boot it on 1.4.7 in a non-production environment, and confirm registration, discovery, and teardown all behave. Keep that scenario as a smoke test.

Implementation Patterns

• Treat this as a pure maintenance bump. The typical day-to-day workflow is: bump the lockfile, run your test suite, deploy. There is no migration guide to follow and no new surface to adopt.
• Pin to the patch if you have multiple plugin-bearing apps. Because it is a bugfix, ^1.4.7 is safer than ^1.4 only if you want the fix everywhere immediately; otherwise let the constraint resolve normally and update lockfiles per app.
• Exercise the plugin lifecycle in tests, not just unit tests. Plugin packages commonly break at the seam between container resolution and provider boot order. An integration test that boots the app and asserts the plugin's bindings resolve is the highest-value test to add alongside this upgrade.
• Add a CI matrix row for the versions you support. If you still run Laravel 8.x anywhere, keep an 8.x job explicitly — this release targets 8.x behaviour, and the fastest way to catch a regression is a job that actually boots 8.x rather than relying on a single newest-version job.
• Isolate plugin configuration. Keep any package-level config published into config/ minimal and environment-driven (config('...') reads, not hardcoded values), so a compatibility fix that subtly changes defaults can't silently alter behaviour across environments.
• Batch it with other patch-level updates. There is little to gain from deploying this alone; fold it into a routine dependency pass so the blast radius is one deploy, not two.

Gotchas and Tips

• The release notes are thin — verify scope yourself. "Fix bugs to make plugins work better in Laravel 8.x" does not enumerate what changed. Diff the 1.4.6 → 1.4.7 tag, or at minimum read the commit list, before assuming the update is cosmetic.
• Laravel 8.x has two plugin-resolution mechanisms in play — classic config/app.php provider registration and Composer-driven package discovery. A bugfix "for plugins" may behave differently depending on which one you use. Confirm which path your app takes and test that specific path.
• Stale caches are the most common false-negative. If a plugin still fails after upgrading, clear config, route, and the compiled services manifest before filing a bug — a cached bootstrap/cache/services.php will happily keep loading the old provider.
• Watch provider boot order. Compatibility fixes around plugins frequently touch registration timing. If you rely on another package's bindings during your plugin's boot(), assert that ordering explicitly rather than relying on it implicitly.
• Check your own plugin shims. If you wrote workarounds for the 1.4.6 behaviour (manual provider registration, conditional container bindings), remove or gate them. Workarounds left in place on top of a fix are a common source of "it worked, then it didn't" reports.
• Debugging entry points: php artisan about for environment sanity, php artisan tinker to confirm the plugin's bindings resolve from the container, and composer show <vendor>/<package> to confirm the installed version is genuinely 1.4.7 and not a cached older build.
• Extension points: none are advertised in this release. Continue using whatever hooks the 1.4.x line already exposes (service provider overrides, published config, container bindings) — but treat them as unchanged until you've checked the diff.
• Upgrade boundary: staying on 1.x, no deprecations are signalled here. The thing to flag for later is any future move off Laravel 8.x — a compatibility-focused patch is a hint that the package's support policy tracks the framework's, so plan a compatibility review before moving the app to Laravel 9+.