Admin Bundle Laravel Package

Getting Started

Before anything else: this is a Symfony/Sylius-family bundle, not a Laravel package. There is no service provider, no Eloquent integration, no Blade views. If you are on Laravel, stop here and look at Filament/Nova/Backpack. The content below assumes a Monofony (or Sylius) application where the bundle is meant to run.

The bundle is the admin UI layer of Monofony — it assumes monofony/core-bundle and the Sylius resource/grid packages Monofony forks are already present. It ships no entities; it assumes a user entity implementing the admin user interface with ROLE_ADMIN.

composer require monofony/admin-bundle

1. Register the bundle in config/bundles.php, after the core/UI bundles.
2. Import its routing (Sylius convention):

# config/routes/monofony_admin.yaml
monofony_admin:
    resource: "@MonofonyAdminBundle/Resources/config/routing.yml"
    prefix: /admin

3. Configure a security firewall matching ^/admin, plus a login form.
4. Build assets (Encore config normally comes from the Monofony skeleton).
5. Verify wiring:

bin/console debug:router | grep admin
bin/console config:dump-reference monofony_admin

Where to look first: the bundle's tests/Application fixture (if present) and the Monofony/Skeleton repo — both are far more instructive than the README. Then config:dump-reference for the real config tree once registered.

First real use case: log in at /admin, then take one entity — say Customer — and give it a resource config, a grid, and a form. You should get index/create/update/delete for free. That resource→grid→form loop is the day-to-day core of working with this bundle.

Implementation Patterns

Resource configuration is the primary pattern. Declare an entity once and the bundle wires routes, controllers, grids, and forms:

# config/packages/monofony_admin.yaml
monofony_admin:
    resources:
        app.customer:
            classes:
                model: App\Entity\Customer
                form:  App\Form\Admin\CustomerType
                controller: App\Controller\Admin\CustomerController

Grids drive index pages. Define them in YAML with the ORM driver, fields, filters, and per-row/bulk actions. Most "add a column / add a filter / change sort" tickets land here rather than in PHP. Keep grids under config/packages/monofony_admin/grids/ and import them — or, if the bundle reuses the sylius_grid tree, put them there. Confirm which by running debug:config monofony_admin and debug:config sylius_grid and seeing where your grid actually resolves.

Extend resource controllers, don't hand-roll CRUD. Subclass the resource controller and override a single action when you need a custom redirect, flash, or side effect. Use the resource route type and pass _sylius: section: admin so the correct templates, layout, and permission checks apply.

Example — overriding create to attach the current admin as creator:

protected function createAction(Request $request): Response
{
    $response = parent::createAction($request);
    // hook here for post-create side effects
    return $response;
}

Templates. Override via the standard Symfony mechanism:

templates/bundles/MonofonyAdminBundle/<path>.html.twig

Never edit files under vendor/. Override whole templates sparingly; prefer overriding individual blocks (content, header, breadcrumb) by extending the bundle layout and redefining one block.

Menu and dashboard. The dashboard is a composition of template partials; add widgets by extending the dashboard template and rendering your own partials rather than editing the bundle's. Menu entries are wired through the admin menu service/config — inspect debug:container | grep menu to find the service id you need to decorate or replace.

Permissions. ROLE_ADMIN gates the panel; finer-grained checks are usually done by decorating the resource controller's authorization method or by adding voters. There is no RBAC/audit layer in this bundle — plan to build that yourself.

Forms. Standard Symfony forms. Reuse types where possible; the resource config points at a form type class, so form customization is entirely in your app.

Gotchas and Tips

• Composer resolution will be the first wall. Monofony/Sylius pin Symfony 4/5-era components and Doctrine versions. On a modern Symfony project (let alone a Laravel one) composer require will fail on constraint conflicts before anything runs. Check Monofony's supported Symfony/PHP matrix first.
• No entities ship here. If you see a missing user class or "abstract method" error, that's the bundle expecting a core-bundle user entity. Implement the admin user interface and map it before touching the admin config.
• config:dump-reference is your documentation. The README is thin. Once the bundle is registered, the reference tree is the accurate source for available options. Combine with debug:config.
• Grids and resource config live in two different keys. Confusing sylius_grid and monofony_admin.resources is the most common wiring error — a resource with no grid produces an empty index, not an error.
• Templates are silently wrong when overridden at the wrong path. The bundle name in the override path must match exactly (case-sensitive); a mismatch falls back to the vendor template with no warning. Verify with debug:twig | grep MonofonyAdmin.
• Routing ordering matters. The /admin login route must come before the catch-all resource routes; otherwise /admin/login matches a resource route and 404s.
• Assets are not a Laravel Mix concern. You need Webpack Encore and the Monofony skeleton's config, or the admin CSS/JS won't load and the UI will look broken while routes still work.
• No upstream maintenance signal. One star, zero dependents. Assume you will fork this. Debugging means reading source — there is no community to ask. Budget for owning security patches to transitive Sylius/Symfony dependencies.
• The correct extension point is the app, not the bundle. Resource configs, grid configs, controllers, forms, and templates all live in your application. If you find yourself patching vendor/monofony/admin-bundle, you've taken on the fork — do it deliberately.
• For Laravel developers: treat this as UX reference material only. Doctrine entities ≠ Eloquent models, Symfony Forms ≠ FormRequests, Twig ≠ Blade. Reimplement the admin concepts (resource CRUD, grid, form per entity) with Filament if the business requirement is a Sylius-style admin on Laravel.