Admin Bundle Laravel Package

Getting Started

1. Check compatibility before requiring it. The last release was 2016 and the bundle targets the Symfony 2.x/3.0 AppKernel era. Read composer.json on GitHub first; the constraint will likely pin an old Symfony and PHP version. Don't drop it into a Symfony 4+ project.
2. Install into a legacy app (or a Docker image with PHP 5.6/7.0):

   composer require symfonyid/admin-bundle
   

3. Register the bundle in app/AppKernel.php:

   new SymfonyId\AdminBundle\SymfonyIdAdminBundle(),
   

4. Import routing in app/config/routing.yml under something like /admin, and add a firewall/access_control entry so the admin is protected from the start.
5. Where to look first: the README, DependencyInjection/Configuration.php (this is the real API surface — it tells you every configurable key), Resources/config/services.xml, the base admin controller, and Resources/views/ for the Twig templates you'll override.
6. First use case: wire up one trivial entity (e.g. a Tag with id/name), confirm the generated list/create/edit/delete loop works end to end, then scale to real entities. If one entity works, the rest is config repetition.

Implementation Patterns

• Declarative per-entity registration. The KISS model is one config block (YAML/annotation) per entity rather than one hand-written controller per entity. Keep those blocks in one app/config/admin.yml so the admin surface is reviewable in a single diff.
• Subclass the base controller for anything custom. Most generators of this vintage expose a base CRUD controller with overridable methods for query building, form creation, and list actions. Extend it rather than duplicating routing.
• One FormType per entity. Let the bundle own routing, listing, and CRUD plumbing; do validation and field layout in a normal Symfony form type so the logic stays portable to a handwritten controller later.
• Override views by bundle inheritance. Copy only the templates you need from Resources/views/ into app/Resources/SymfonyIdAdminBundle/views/ and edit blocks — don't fork the whole template tree.
• Use it as scaffolding, not a permanent framework. This is a good fit for: "I need a back office for five entities this week." As soon as you need bulk actions, dashboards, or complex filtering, graduate individual screens to handwritten controllers.
• Custom actions: add a normal route + controller action and link it from the overridden list template; don't try to bend the generator into non-CRUD workflows.
• Security: old-style access_control + a role like ROLE_ADMIN around the admin prefix. Per-entity restrictions are usually a voter you wire yourself — verify whether the bundle supports anything finer-grained before assuming.

Gotchas and Tips

• Abandoned is the main gotcha. 13 stars, zero dependents, no release since 2016 — there is effectively no community coverage. Expect to debug by reading source, and budget for a fork you vendor in (repositories with type: vcs or a path repo) if you need fixes.
• Symfony 4+ incompatibility is structural, not cosmetic. Bundles are gone, AppKernel is gone, services are autowired by default. Don't attempt to "make it work" — run it in a legacy app or Docker container with the right PHP/Symfony pair.
• Config is compiled into the container cache. After editing admin config or services, run cache:clear for both dev and prod. A stale config cache presents as "my new entity doesn't appear," which looks like a bundle bug but isn't.
• Hardcoded service IDs predate autowiring. If you enable autowiring in a newer setup, the bundle's services often aren't picked up. Check with bin/console debug:container | grep -i admin and bin/console debug:router.
• Template overrides silently no-op if inheritance is disabled or the path is wrong. Use debug:twig to confirm the resolved template file before editing blindly.
• Form theming conflicts. Old bundles often ship a Twig form theme; combined with a modern app theme you'll get duplicated wrappers or missing classes. Test forms on day one, not week three.
• Extension points, in order of preference: override templates → subclass the base controller → override services in app/config/services.yml → event subscribers → fork the bundle. The first two cover most needs and survive upgrades best.
• Confirm feature scope early. "KISS" means deliberately limited. Verify pagination, filtering, and permissions support exist before you design an admin UI around them; otherwise you'll rebuild those pieces yourself anyway.