- How do I install tjgazel/laravel-docblock-acl in a Laravel app?
- Install it with Composer, then publish and run the package migrations to create its group and permission tables. After that, annotate your controller methods with the roles or permissions each action requires. There are no external services or message buses to configure, so it is an additive, in-process dependency.
- Which Laravel versions does laravel-docblock-acl support?
- The package targets Laravel 6 and Laravel 7 only. Both of those releases are end-of-life, so the package's useful life is capped by your application's own upgrade horizon. Plan for a fork if you later move to a newer Laravel version.
- How does DocBlock ACL enforce permissions in Laravel controllers?
- You declare the required roles or permissions in the docblock above a controller method. The package reads those annotations and enforces the rule automatically when the action is dispatched, so authorization lives next to the code it protects. This keeps access rules self-documenting and removes boilerplate gate checks from your controllers.
- Does laravel-docblock-acl support multiple roles or groups per user?
- Yes. Version 2.0.1 converged on a many-groups-per-user model rather than a single role per user. That is the right choice for anything beyond a small internal tool, but it changes the cardinality of the authorization relationship, so review your policy checks and admin screens accordingly. Confirm whether the model is a flat set or a hierarchy before designing around it.
- Can I use laravel-docblock-acl with Laravel 9, 10, or 11?
- No, not without forking and maintaining it yourself. The package is limited to Laravel 6 and 7, so on Laravel 9, 10, or 11 this is not an integration task. Treat it as a component for a legacy estate, not for greenfield builds.
- What changed in laravel-docblock-acl v2.0.0 and how do I migrate from v1?
- There is no published changelog for v2.0.0 or v2.0.1, so the breaking change implied by the major version bump is not documented. Before upgrading an existing v1 install, ask the maintainer what broke and whether a migration guide exists. Do not assume the migration is trivial, especially around the multi-group data model.
- How do I customize the Bootstrap 4 admin views shipped with the package?
- The package ships server-rendered Blade views built on Bootstrap 4 and laravel/ui, so you override them by publishing the views and editing your copies. If your app uses Tailwind, Bootstrap 5, Inertia, or Breeze, expect to replace the views wholesale. Treat the shipped UI as a reference implementation rather than a finished admin panel.
- Is laravel-docblock-acl compatible with Livewire full-page components?
- Version 2.0.1 includes a fix for Livewire full-page component routing, which suggests the views previously broke under page-level routing. The fix is welcome, but it also shows the view layer is sensitive to host-application conventions. Test your specific Livewire setup before relying on the admin screens.
- Does laravel-docblock-acl ship tests, and is it safe for production?
- Verify this before committing: check whether the repository includes a test suite and CI coverage across Laravel 6 and 7. Also confirm the release cadence and whether it is a single-maintainer project. Permission caching and multi-group resolution are classic sources of stale-permission bugs, so validate that cache invalidation on group mutation actually works in your app.
- What are the alternatives to laravel-docblock-acl for roles and permissions?
- Role and permission handling is a commodity concern in Laravel, so alternatives are plentiful. Native Gates and Policies cover simple cases, while packages such as Spatie laravel-permission and Bouncer are actively maintained and support current Laravel versions. Choose DocBlock ACL mainly if you want authorization declared in controller docblocks and you are staying on Laravel 6 or 7.