Admin Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — there is no service provider, no artisan command, and no config/admin.php. Treat it as an artifact you'd only pull into a legacy Symfony 2.x codebase. If you're evaluating it from a Laravel project, the practical first step is confirming the host app: it requires Symfony 2.3–2.8-era APIs, Twig, and Assetic-style asset handling.

Minimal setup in its native environment:

1. composer require kunstmaan/admin-bundle (pin a 2.x tag; last tagged release was 2014).
2. Register Kunstmaan\AdminBundle\KunstmaanAdminBundle in AppKernel, plus the companion bundles you'll actually use (KunstmaanNodeBundle, KunstmaanMediaBundle, KunstmaanUserManagementBundle, KunstmaanTranslatorBundle).
3. Import the bundle routing under an /admin prefix and add an access_control rule requiring ROLE_ADMIN.
4. Run assets:install (the UI depends on the bundle's Bootstrap-based assets), then create an admin user and log in at /admin.

Where to look first: Controller/AbstractAdminController for the base CRUD controller, Admin/AdminListBuilder for the list abstraction, and Resources/views/ for the layout you'll extend or override. The first concrete use case is almost always "expose an existing Doctrine entity as a filterable, sortable, paginated admin list with edit/delete actions" — that path (AdminListBuilder → AdminList → a controller extending the abstract) is the highest-value piece of the bundle.

Implementation Patterns

CRUD via the AdminList abstraction. The idiomatic workflow is: extend the bundle's abstract admin controller, build an AdminListBuilder for the entity, define fields (AdminListField) with ordering/pagination, add actions (AdminListAction) and filters (AdminListFilter), then render the provided list template. This keeps list/detail/edit screens consistent without hand-rolling tables.

Menu composition. Admin navigation is assembled through a menu builder plus adaptors implementing MenuAdaptorInterface. Each bundle (Node, Media, Settings) contributes its own adaptor; your own module registers one to inject its menu entry with a priority. This is the cleanest extension point for adding a new backend section.

Template override, not fork. Customize the backend by placing templates at the standard override paths (or {% extends '@KunstmaanAdmin/...' %}) rather than editing the bundle in vendor. Layout, list rows, form themes, and the dashboard widgets are all overridable this way.

Settings and globals. Site-wide settings flow through a settings entity/service and are exposed to Twig via the bundle's Twig extensions (locales, settings, menu rendering). Use those helpers instead of querying repositories directly in templates.

Compose with sibling bundles. Admins rarely use this alone: MediaBundle for file/asset management, FormBundle for the form builder, Node/PagePart bundles for CMS structure, TranslatorBundle for i18n of the UI. Design your admin module as one more adaptor/controller in that same pattern.

Gotchas and Tips

• Hard Symfony 2.x ceiling. The API surface (Controller\Controller, Assetic, bundle inheritance) is incompatible with Symfony 5/6 and with Laravel entirely. Budget for either freezing the host app or rewriting the admin layer; do not attempt to bridge it into a Laravel app.
• Abandoned asset pipeline. Bower/Grunt/Assetic front-end builds are the most common breakage on install. If the admin renders unstyled, verify assets:install output and the Assetic config before touching templates.
• Menu ordering surprises. Menu adaptors are priority-ordered and cached in some setups; a new entry that "doesn't appear" is usually a priority or cache-clear issue, not a routing one. Clear cache after registering an adaptor.
• ACL vs. roles. The bundle ships role/ACL entities, but the actual gate is your security.yml access_control plus voters. Check firewall ordering — a permissive firewall earlier in the chain will silently bypass admin protection.
• AdminList filters and state. Filters and ordering are request/session-driven; when a filter "sticks" across pages, that's session state, not a bug. Reset it explicitly in tests.
• Security and maintenance posture. Last release 2014, zero dependents, low activity score — there are no upstream security patches. Pin exact versions, vendor the code if needed, and treat any exposed admin surface as your own responsibility.
• Debugging levers. debug:router to confirm the admin routes loaded, the Symfony profiler for the controller/service graph, and the bundle's own service IDs when overriding definitions. Template overrides fail silently if the path doesn't match the bundle's expected override directory.
• Extension points worth knowing. Custom AdminListActions, menu adaptors, Twig extension additions, and controller subclasses cover most needs — you should rarely need to modify vendor code, which matters a lot when there's no maintainer to upstream fixes to.