Crudlex Laravel Package

Getting Started

CRUDlex is a config-driven admin CRUD generator: you describe database tables in a YAML file, point it at a Doctrine DBAL connection, and it gives you list/create/edit/show/delete screens with filtering, sorting, pagination, validation and file uploads — rendered through Twig templates. If you're coming from Laravel, think "backpack/laravel-admin, but for Symfony 4 / Silex 2 and Doctrine DBAL instead of Eloquent."

Since 0.14.0 the core is framework-agnostic: philiplb/crudlex no longer depends on Silex. You install the core plus a thin adapter — philiplb/crudlex-symfony4-bundle for Symfony 4, philiplb/crudlex-silex2 for Silex 2. Everything below assumes you pick one adapter and stay inside it.

Minimal steps:

1. Install core + adapter, and pin. composer require philiplb/crudlex:^0.14 philiplb/crudlex-symfony4-bundle (or the Silex 2 package). The release is old, so expect to constrain PHP and Doctrine DBAL in composer.json before anything else resolves.

2. Read the config reference first. The whole package is driven by one YAML file (crud.yml by convention). The README's config table plus one sample entity is enough to start — the Twig templates and the AbstractData/MySQLData classes are your second stop.

3. Register the adapter. In Silex 2 you register CRUDlex\Silex\ServiceProvider with crud.file and a 'crud.data' => ['<entity>' => new CRUDlex\MySQLData(...)] map. In Symfony 4 you register the bundle and let it read the YAML config. Either way, the wiring is "one data provider per entity, one config key per entity."

4. Model one table. Start with a single entity and only list + edit. Something like:

   entities:
     book:
       label: Books
       fields:
         title:
           type: string
           label: Title
           required: true
         author:
           type: reference
           reference:
             entity: author
             field: name
         published:
           type: date
           label: Published
   

5. Mount the routes under a prefix (/admin), and hit the generated list route. That's the first end-to-end smoke test: list → create → edit → delete → pagination → filter.

First useful use case: an internal back-office on top of existing tables. Do not start with file uploads, reference fields and custom validation simultaneously — add those after the list/edit loop is passing.

Implementation Patterns

• Config-first resource modeling. Every table is an entity block in YAML; every column is a field with a type (string, text, integer, float, date, datetime, time, boolean, reference, many/set, enum, file). The field type is what selects the form widget and the list rendering, so choosing it correctly is the main design decision.
• One data provider per entity. MySQLData is the default; wire a distinct instance per entity so you can override per-table behavior later (see extension points). Keep the DBAL connection shared.
• Configure through the service, not Pimple keys. As of 0.14.0 the old $app['crud.layout'] = 'myLayout.twig' and $app['crud.manageI18n'] keys are gone. Use the accessor methods on the crud instance: $app['crud']->setTemplate('layout', 'myLayout.twig'), $app['crud']->setManageI18n(true). This is the single biggest source of "it worked on 0.13" breakage.
• Template overrides are the intended customization layer. Don't fork the package — override the shipped Twig templates (Symfony 4: templates/bundles/<BundleName>/...) to change layout, columns, and button sets. Everything visual is template-level. When you copy a shipped template, rewrite its internals: templates no longer reference app. and all Twig functions/filters are now prefixed crudlex_.
• Validation belongs in config, cross-field logic belongs in hooks. Use required/constraints in YAML for per-field rules; for anything involving two fields, do it in a service/controller wrapping the CRUDlex call rather than fighting the config.
• Mount behind your existing firewall. CRUDlex does not ship meaningful authorization. In Symfony put it behind security.yaml + ROLE_ADMIN; in Silex put it behind a before middleware. Treat it as "the UI only appears for admins," not "it enforces anything."
• References are lookup fields, not ORM relations. A reference field resolves an entity + display field — there's no lazy loading or cascading. For joins you care about, either model them as references or override the list query in a MySQLData subclass.
• Files and uploads need three things aligned: an upload directory, a public path config, and a writable filesystem. Get those consistent before demoing, or images silently 404.
• Embed in an existing admin shell. The most maintainable pattern is to use CRUDlex for the repetitive index/edit loops and keep bespoke pages for entity-specific dashboards — don't try to bend the generator into complex workflows.
• Schema is not managed. Run Doctrine migrations yourself; CRUDlex reads whatever the DBAL connection exposes. This is the biggest difference from Laravel's migration-and-model coupling.

Gotchas and Tips

• It is effectively unmaintained. 0.14.0 is the last line; Symfony 4 is EOL and Silex 2 is abandoned — and 0.14.0's headline change was moving Silex out of the core entirely, which was the project's final architectural move. Score ~3.5 with low "opportunity" is the honest signal: great niche generator, no forward path. Budget for either pinning the stack or a rewrite if the admin surface is critical.
• 0.14.0 is a breaking release; read the Attention: lines before upgrading. The concrete breaks: ServiceProvider moved from CRUDlex\ to CRUDlex\Silex\; ControllerProvider split into Controller + Silex\ControllerProvider with Controller now implementing ControllerInterface; PHP ≤ 7.1 dropped; Pimple key configuration replaced by setTemplate() / setManageI18n() / isManageI18n(); Twig functions and filters prefixed crudlex_; framework dependencies moved to CRUDlexSilex2 and CRUDlexSymfony4Bundle.
• Doctrine DBAL version drift is the first failure. The 2018-era DBAL API differs from DBAL 3+. Expect composer update conflicts and type-mapping errors before you see a single page.
• PHP compatibility. 0.14.0 adds PHP 7.2 as a test target; that is the version the maintainers actually built and tested against. PHP 7.3/7.4 mostly works but is untested, and anything newer will produce deprecations or fatal errors in the older dependency chain.
• Bootstrap 3 is assumed by the default templates. If your admin theme is Bootstrap 4/5 or Tailwind, override templates or accept visual breakage — don't try to patch the CSS.
• Custom templates must be rewritten, not just copied. Any template you overrode on 0.13 that calls app. or an unprefixed Twig helper will break on 0.14 — the internals now talk to the crud instance and the crudlex_* helpers. Diff your overrides against the shipped templates after upgrading.
• Silent YAML mistakes. Unknown type values or misspelled field names degrade the widget or throw at render time. Clear the container/cache after every config change and inspect the parsed definition via the data provider's getDefinition() when a field "disappears."
• Column names must match exactly. The generator maps config field keys to DB column names; a mismatch yields empty columns rather than an error.
• No auth, no audit trail, no soft deletes. If you need those, wrap the service or extend MySQLData — they are not config options.
• Debugging approach: enable Twig debug to see which template is rendering the block; if a save fails with a generic message, log the DBAL exception in the data provider rather than relying on the UI.
• Extension points worth knowing:
  • Subclass MySQLData and override create, update, delete, listEntries to inject auditing, extra constraints, or custom queries.
  • Implement AbstractData to back an entity with a non-Doctrine source (API, view, CSV).
  • Subclass the new Controller (or implement ControllerInterface) to override actions in a framework-portable way, instead of extending the Silex-specific ControllerProvider.
  • Use before/after hooks where exposed for cross-cutting behavior, and setTemplate() / template overrides for presentation.
• Treat the generated admin as disposable. Because the package is frozen, keep the CRUDlex integration in its own namespace/module so replacing it later doesn't leak into domain code.