Server Crud Bundle Laravel Package

Getting Started

First, calibrate expectations: modera/server-crud-bundle is a Symfony 2/3 bundle, not a Laravel package. It will not composer require cleanly into a Laravel app, and its last tagged release is from June 2016 with two stars and zero dependents. For a Laravel developer, the "day-to-day" leverage here is pattern transfer, not runtime use. Anything you build with it lives in a legacy Symfony service, not your Laravel codebase.

If you are in a legacy Symfony 2.8/3.x app (its only realistic home):

composer require modera/server-crud-bundle

Register the bundle in app/AppKernel.php:

new Modera\ServerCrudBundle\ModeraServerCrudBundle(),

There is essentially no YAML to write — the bundle deliberately pushes configuration into PHP. Look first at these files, in order:

1. Controller/AbstractCrudController.php — the five default actions (list, get, create, update, delete) and the getConfig() contract every subclass must satisfy.
2. Config/CrudControllerConfig.php — entity class, allowed actions, ignored fields, per-action security callbacks.
3. DependencyInjection/Configuration.php — to confirm how little global config there actually is.
4. Resources/config/services.xml — the CrudManager and builder services you can decorate.

Your first use case: expose a JSON endpoint for a Doctrine entity grid. Extend the abstract controller, declare the entity, wire a route per action, and hit listAction:

class UsersController extends AbstractCrudController
{
    protected function getConfig()
    {
        return new CrudControllerConfig(array(
            'entity_class' => 'AppBundle:User',
            'allowed_actions' => array('list', 'get', 'create', 'update', 'delete'),
        ));
    }
}

If you are on Laravel, stop after reading the controller/config pair — then reproduce the contract natively (see below).

Implementation Patterns

The controller-as-configuration pattern. The bundle's central idea is worth stealing regardless of stack: a base controller implements the verbs once, and each concrete controller only declares what it operates on. Port this to Laravel as an abstract CrudController with a config() method returning a typed DTO (entity/model class, allowed actions, hidden fields, authorization rules), plus a set of trait/action methods. Your per-resource controllers shrink to ~20 lines.

Declarative list contract. The list action is driven by query parameters — sort, filter, page, page size — parsed into a spec and applied to the Doctrine query builder. This is the day-to-day surface you actually touch. In Laravel, map it to spatie/laravel-query-builder and keep the parameter names and response envelope identical to what your legacy frontend (ExtJS/Sencha-style grids) already expects. That is where the real migration value is: stable contracts, swapped implementation.

Per-action security via callbacks in config. Rather than Symfony voters, the config allows per-action authorization hooks. When porting, model this as FormRequest authorize() per action plus a policy per model — same granularity, more idiomatic.

Service decoration for extension. The CrudManager and result-building services are registered as services, so the intended extension path is a compiler pass or a decorator rather than subclassing deep internals. In a legacy Symfony app, prefer decorating CrudManager over overriding controller methods — it survives upgrades better and is the only sane way to inject auditing or tenant scoping.

Typical workflow for a new resource (Symfony leg):

1. Generate/map the Doctrine entity.
2. Subclass AbstractCrudController, fill CrudControllerConfig.
3. Add one route per action in routing.yml (list and get are GET; create/update/delete are POST/DELETE).
4. Add validation constraints on the entity — the bundle delegates validation to the Symfony validator, so this is normal symfony work.
5. Wire per-action authorization in the config, not in the controller body.
6. Smoke-test list first — it exercises filtering/sorting/paging, which is where integration bugs surface.

Laravel-native equivalent (recommended path):

• php artisan make:controller per resource, or a single abstract base + concrete subclasses.
• spatie/laravel-query-builder for the filter/sort/include DSL.
• FormRequests for validation, API Resources for the response envelope.
• Policies for per-action auth.
• If the real ask is admin screens rather than an API, use filament/filament and do not build a CRUD engine at all.

Gotchas and Tips

It will not install in Laravel — do not burn time on it. Composer constraints will collide on Symfony components, and the code predates PHP 7.2 typing. Expect fatal errors on PHP 8. Confirm by reading composer.json (PHP ceiling, Symfony component ranges, Doctrine ORM version, PSR-0 vs PSR-4 autoload) before any spike. Pinning PHP 7.0/7.1 to boot it is itself an instant security finding.

Config is PHP, not YAML. Debugging config means var_dump/dump inside getConfig() and stepping through AbstractCrudController. There are no config-dumper helpers, no Symfony profiler panel for this bundle's config, and almost no docs beyond a README plus the source.

Unknown query parameters silently pass through or are ignored. The list parser is not strict by default. If you are matching a frontend grid contract, assert your expected sort/filter/pagination keys explicitly in tests — otherwise a typo'd param yields an unfiltered (potentially large) result set rather than an error.

allowed_actions is your first debugging checkpoint. A surprising 404/405 is usually an action missing from allowed_actions, not a routing problem. Check order: route → allowed_actions → per-action security callback → entity/validator. Failures at each stage look similar from the client side.

Doctrine hydration is the performance ceiling, not the bundle. Large lists will tank on hydration long before the bundle does anything wrong. Add ->select()/partial hydration or native queries behind the list action if pages get slow, and cache the count query.

No maintenance means every bug is yours. There is no upstream to file against (2 stars, 0 dependents, no release since 2016). Budget accordingly: if you need a fix, you fork — and if you fork you now own a Symfony 2-era library forever. Prefer the "read the source, reimplement the contract" approach.

Test the response envelope, not just the payload. The list response shape (data + total count + paging metadata) is what your frontend grid consumes. Lock it down with a contract test so a native reimplementation can be swapped in without touching the UI layer.

Extension point: decorate, don't subclass deep internals. If you must add cross-cutting behavior (audit logging, soft-delete scoping, tenant filters) in a legacy Symfony app, decorate the CrudManager service. Subclassing the abstract controller works but ties you to private method signatures that will never be fixed.

The bundle is a reference architecture, not a dependency. Its value to a Laravel team is the shape: generic verbs on a base controller, config DTO per resource, query-param-driven list contract, per-action authorization hooks. Pull the shape into a small internal scaffold; do not pull the package into composer.json.