Admin Crud Extensions Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — it plugs into lin3s/admin-bundle (LIN3S Admin) and assumes Symfony's HTTP kernel, DI container, Doctrine ORM, and Twig. There is no service provider, facade, or Artisan integration, so a Laravel developer's first step is deciding whether the project is actually Symfony. If it is:

1. composer require lin3s/admin-crud-extensions-bundle alongside lin3s/admin-bundle and Doctrine.
2. Register the bundle in app/AppKernel.php (or config/bundles.php on Symfony 4+, though this bundle predates that) after the base Admin bundle.
3. Read the bundle's own composer.json first — it pins PHP 5.6/7.0-era and Symfony 2.8/3.x constraints, which tells you immediately whether your project can host it.
4. Look at vendor/lin3s/admin-crud-extensions-bundle/src/ in this order: DependencyInjection/ (config tree and service ids), Resources/config/ (routing and service YAML), Controller/, then Resources/views/.

First use case: declare an admin resource for an entity and get list/create/edit/delete screens plus the extension behaviours (extra actions, template blocks, controller helpers) without hand-writing a CRUD controller. Start by copying the config block from the README into your config.yml and importing the bundle's routing, then hit the generated route with bin/console debug:router.

Implementation Patterns

• Config-driven resources. Day-to-day work is YAML: one block per managed entity pointing at a class, form type, and grid/list definition. Treat this file as your admin "schema" and keep it under version control with the entity.
• Extend, don't fork, the controller. Subclass the bundle's CRUD controller when you need behaviour the config can't express (custom redirects, authorization checks, derived fields). Overriding a single action method is cheaper than replacing the service.
• Service decoration over replacement. To alter an extension's behaviour, decorate its service id or alias the interface in your app's services.yml. This survives bundle upgrades better than swapping the class outright.
• Template overrides via bundle path. Override blocks by placing Twig files under app/Resources/<BundleName>/views/... (or templates/bundles/... on newer Symfony). Copy the original file first so you keep the block names intact.
• Doctrine listeners for side effects. For audit logging, slug generation, or cache invalidation on save/delete, use Doctrine lifecycle events rather than stuffing logic into admin controllers.
• If you're a Laravel shop, don't attempt to install this. The equivalent pattern is a resource controller + FormRequest + policy, or an admin package (Filament, Nova, Backpack). The ideas — declarative resource config, overridable actions, Twig/Blade block overrides — map cleanly; the code does not.

Gotchas and Tips

• Abandoned and unmaintained. Last release October 2017, zero stars, zero dependents. It will not install on PHP 8 or Symfony 4+/5+/6+ without a fork. Vendor it ("repositories": [{"type": "vcs", ...}]), patch the composer.json constraints, and expect to fix deprecations yourself.
• No security support. Any admin surface is an attack surface; an unmaintained CRUD layer is a liability. Budget for a fork or replacement, not just an install.
• Bundle registration order matters. The extensions bundle assumes the base Admin bundle's services and Twig namespaces exist. Wrong order produces "service not found" errors that look like config problems.
• Config tree is strict. Unknown keys throw at container compile time. After every YAML change: bin/console cache:clear then debug:container <service> to confirm the definition picked up your values.
• Docs are thin. The README is the whole manual. Verify class and service ids in vendor/ rather than trusting blog posts — several naming conventions changed across the 2016–2017 tags.
• Debugging entry points: debug:router for missing routes, debug:container --tag=... for unregistered services, lint:yaml for config typos, and the Symfony profiler's Doctrine panel for unexpected queries from list views.
• Extension points are not a BC contract. Because there are no releases since 2017, "override the Twig block" and "decorate the service" are stable only relative to the exact commit you vendor. Pin a commit hash, not a branch.