roelofjan-elsinga/aloia-cms-publish
Publishing extension for Aloia CMS that adds controls to publish or unpublish pages and manage when content is visible on your Laravel site. It integrates with Aloia CMS so editors can handle visibility from the CMS, enabling simple editorial workflows without custom code.
Release 4.1.0 is a compatibility release: the headline change is Laravel 11 support. There are no new features or deprecations called out, so if you are already on 4.x with Laravel 10 the upgrade is a version-constraint bump plus a sanity check of your bootstrap wiring.
Minimum steps:
composer require <vendor>/<package>:"^4.1" # pin the 4.1 line explicitly
php artisan vendor:publish --provider="<Vendor>\<Package>\<Package>ServiceProvider"
php artisan about # confirms package + Laravel 11 runtime
Look here first, in order:
CHANGELOG.md / UPGRADING notes for the 4.0 → 4.1 jump — confirm whether any config keys were renamed or defaults changed.config/<package>.php — this is the contract you actually live with day to day.register()/boot() — tells you what is bound in the container, what is deferred, what is publishable (views, migrations, lang) and what tags exist.First use case worth wiring end to end: resolve the package's main entry point from the container inside a single action or job, assert it works under php artisan config:cache, then expand. Doing this on day one surfaces 90% of Laravel 11 integration problems (missing config, undiscovered provider, middleware that never runs) before they are buried in feature code.
Because Laravel 11 ships a slim skeleton — no app/Http/Kernel.php, no app/Console/Kernel.php, no config/*.php by default — most of your "getting started" work is deciding where the package's middleware, scheduled tasks and provider registration now live. That is bootstrap/app.php and bootstrap/providers.php.
Provider registration. Package discovery still handles the common case. If the docs tell you to add the provider to config/app.php, that is Laravel 10 advice — in Laravel 11 it goes in bootstrap/providers.php (or ->withProviders() in bootstrap/app.php). Aliases still live in config/app.php under aliases, but prefer injecting the class or interface and skip the alias entirely.
Middleware. Anything the docs describe as "add to $middleware / $middlewareGroups / $routeMiddleware" becomes:
// bootstrap/app.php
->withMiddleware(function (Middleware $middleware) {
$middleware->append(\Vendor\Package\Middleware\Track::class);
$middleware->alias(['package' => \Vendor\Package\Middleware\Guard::class]);
})
This is the single most common place a 4.0-era snippet silently does nothing after upgrading.
Scheduling. If the package auto-registers schedule entries via callAfterResolving(Schedule::class, ...), it still works, but your own entries move to routes/console.php or ->withSchedule() in bootstrap/app.php. Keep package-driven and app-driven schedules in separate files so schedule:list stays readable.
Config over facades in domain code. Read config once in a service provider or a small config object and inject it. Facade calls inside actions, jobs and listeners are the main reason test suites get slow and brittle. Bind the package's interface to your own decorator in a dedicated PackageServiceProvider so swapping behaviour in tests is a one-line $this->app->bind().
Jobs and queues. Wrap package calls that hit the network or disk in your own job with ShouldQueue, explicit $tries, $backoff and a failed() handler. Package exceptions rarely map cleanly onto your retry policy, so translate them at the boundary.
Testing. Use RefreshDatabase for anything touching published migrations, and the package's own fakes/Http::fake() where offered. Assert your behaviour (an event dispatched, a record written), not the package's internals — those assertions break on every minor release.
Environments. Treat the published config as code: commit it, keep env() calls confined to it, and run php artisan config:cache in CI. Config that only works uncached is a deploy-day surprise.
"^4.1" and add "php": "^8.2" to your root composer.json so the resolution error happens where you can see it.vendor:publish does not overwrite existing files. If a default key was added or renamed in 4.1, your old config/<package>.php will be missing it and you will get null rather than an error. Diff the package's config/ against yours after every minor bump, and always php artisan config:clear locally — a cached config from before the upgrade is the classic "it works in tinker but not in the app" cause.dd() in the middleware's handle() or php artisan route:list -v rather than assuming.composer require, if bindings are missing, run php artisan package:discover and check bootstrap/cache/packages.php. A stale packages.php in a deploy artifact will drop the provider entirely.Octane::tick() or bind the offending class as scoped.php artisan about for versions and driver config, php artisan tinker + app()->bound(...) to confirm container bindings, php artisan vendor:publish --tag=<pkg>-config --force in a throwaway branch to see the current defaults, and -vvv on any failing artisan command.Macroable classes (convenient, least discoverable — document them in the same file that registers them).$dates/string-cast behaviours older package code sometimes relied on. If you were on 3.x, check for any ->dates or custom Kernel interactions before assuming this is a pure constraint bump.Overall: 4.1.0 is a low-risk, adopt-now release if you are on Laravel 11 or planning the move. The work is almost entirely in your bootstrap/app.php wiring and re-publishing config, not in the package API.
How can I help you explore Laravel packages today?