Laravel Admin Laravel Package

Getting Started

• Confirm your application is on Laravel 12.61.1+ or 13.12.0+. This release explicitly drops Laravel 11 support, so an L11 app cannot install 1.0.1 without also upgrading the framework.
• Update the package with composer require vendor/package:^1.0.1 (or composer update vendor/package --with-dependencies if it is already required). Review the lock-file diff before committing.
• Clear Laravel’s caches after upgrading: php artisan optimize:clear, then re-run php artisan config:cache in environments that use config caching.
• Look first at the package’s README, CHANGELOG, and composer.json. In composer.json, verify the framework constraint and whether the package uses Laravel auto-discovery or requires manual service-provider registration.
• If the package ships publishable assets, run php artisan vendor:publish --provider="Vendor\\Package\\PackageServiceProvider" and inspect the published config before changing values.
• First use case: upgrade in a branch, run your existing test suite, then smoke-test the package’s primary integration point (facade call, injected service, event listener, or artisan command) against the lowest supported framework version, 12.61.1.

Implementation Patterns

• Treat this as a security/compatibility release first. The important workflow is not new feature adoption but getting the framework and package onto patched versions together.
• In composer.json, align the framework constraint with the patched floor: use ^12.61.1 for Laravel 12 applications, or ^13.12.0 for Laravel 13 applications. Avoid broad constraints like ^12.0 that can resolve below the patched minimum in lock files.
• Run composer audit in CI and fail builds on known advisories. This release exists because of GHSA-5vg9-5847-vvmq and GHSA-crmm-hgp2-wgrp, so dependency auditing should be part of the deployment gate.
• Update CI matrices to test only Laravel 12.61.1+ and 13.12.0+. Remove Laravel 11 jobs; keeping them will produce false failures or misleading green builds if they skip installation.
• For multi-package applications, upgrade in this order: framework constraint → composer update laravel/framework --with-dependencies → package update → application tests. This isolates framework resolution failures from package integration failures.
• If the package exposes services, bind its interfaces in a service provider rather than resolving concretes directly. That keeps your application insulated if the package’s internals change in a later security release.
• Use config caching in production only after publishing and reviewing the package config. Keep environment-specific values in .env and avoid editing cached config files directly.
• For deployments, include php artisan migrate --force only if the package ships migrations; otherwise keep the deploy step limited to composer install, cache clearing, and config/route caching.
• When integrating the package into queues or scheduled jobs, verify that its service provider and config are loaded in those contexts. Long-running workers should be restarted after the upgrade.

Gotchas and Tips

• 1.0.1 is a patch version, but dropping Laravel 11 is a breaking platform change. Composer will block installation on L11; do not use --ignore-platform-reqs to force it.
• Upgrading this package alone does not patch the framework advisories. The application’s laravel/framework constraint must also resolve to 12.61.1+ or 13.12.0+.
• Use composer why-not laravel/framework 12.61.1 (or 13.12.0) to find packages pinning the framework below the patched floor. Resolve those before updating this package.
• Check composer show vendor/package after installation to confirm the installed version and its framework requirement. Do not rely only on composer.json.
• If auto-discovery is enabled, a stale bootstrap/cache/packages.php or services.php can hide provider changes. Run php artisan package:discover and clear caches during debugging.
• Config caching can mask newly published config keys. If the package behaves differently in production, compare php artisan config:show vendor-package with the local config file.
• Test against the minimum supported framework version, not just the latest. A package can pass locally on 12.70 while failing on 12.61.1 if it implicitly relies on a later framework patch.
• Watch for indirect Laravel 11 dependencies in dev tooling, CI images, and Docker base images. Dropping L11 in the application does not automatically update those environments.
• Extension points to inspect first: published config, service-provider bindings, facade accessors, events, and any package-specific artisan commands. Prefer overriding config and bindings over modifying vendor files.
• For debugging resolution failures, use composer update vendor/package -vvv, inspect composer.lock, and check whether laravel/framework is being held back by symfony/* or PHP version constraints.
• If the package ships a migration or config change in this release, stage the upgrade against a production-like database snapshot before rolling forward.