- Is CRUDlex a Laravel package I can install with Composer?
- No. CRUDlex is a framework-agnostic PHP CRUD engine built on Doctrine DBAL and Twig, with official integrations for Silex 2 and Symfony 4 rather than Laravel. It ships no Laravel service provider, facade, Eloquent layer, Blade views, or Laravel-native routing, middleware, auth, or CSRF handling. Using it in a Laravel app requires a purpose-built adapter, which is a project rather than a simple dependency install.
- Does CRUDlex support Laravel 10 or Laravel 11 on PHP 8.1+?
- There is no verified support. The 0.14.0 release was tested against PHP 7.2, which is below the PHP 8.1+ floor required by Laravel 9, 10, and 11. Before any Laravel adapter work, the core would need to be proven on PHP 8.x and checked against the target Laravel version's dependency graph. Plan a time-boxed spike to confirm compatibility before committing.
- How do I install and configure CRUDlex with Composer?
- Install the philiplb/crudlex package via Composer and provide Doctrine DBAL for database access plus Twig for rendering. You then define entities and field configurations, typically as arrays or configuration files, describing table columns, types, validation, filters, and relations. Routing and controllers must be wired by your host application, since the core has no opinion about the framework it runs in.
- Can CRUDlex use my existing Eloquent models?
- No. CRUDlex is built on Doctrine DBAL and works against database tables rather than Eloquent models. There is no Eloquent integration, model mapping, or relationship handling through Laravel's ORM. If you need Eloquent-backed admin screens, a Laravel-native admin package is a better fit.
- What features does CRUDlex provide for admin interfaces?
- CRUDlex gives you configurable entities and fields per database table, so you can expose tables as searchable, editable list, form, and detail screens with little custom code. It supports relations, file uploads, validation, and filtering out of the box. Lists, forms, and detail views are rendered through customizable Twig templates, so the UI can be adjusted without touching the core.
- Can I use Blade templates instead of Twig with CRUDlex?
- Not without custom work. CRUDlex is Twig-centric: its templates and prefixed Twig functions assume a Twig environment, and version 0.14.0 replaced direct Pimple access in templates with calls against the CRUD instance. A Laravel integration would need a template bridge or a parallel set of Blade views, which is part of the adapter effort rather than a configuration toggle.
- How would I integrate CRUDlex into a Laravel application?
- The realistic path is a purpose-built adapter: wrap the framework-agnostic Controller and Service in Laravel service providers and routes, bridge Twig rendering, and add Laravel authentication, authorization, and CSRF handling. Version 0.14.0 split the core from Silex, so the engine is theoretically embeddable, but no such Laravel adapter exists in the package. Budget for it as a small project and prove PHP 8.x compatibility first.
- Is CRUDlex safe to run in production?
- Treat it cautiously. It remains pre-1.0, is maintained by a single maintainer with a small star count, and its tested runtime (PHP 7.2) has been unsupported since January 2020; Silex 2 and Symfony 4 are also end-of-life. There is no verified PHP 8+ compatibility and no clear security patching owner for an embedded Laravel adapter. If you must use it, isolate it and review its dependency set for advisories.
- What changed in CRUDlex 0.14.0 and will it break my existing integration?
- 0.14.0 is a breaking pre-1.0 release. It decouples the core from Silex by splitting ControllerProvider into a framework-agnostic Controller and a Silex controller provider, splitting ServiceProvider into a Service and a Silex service provider, and replacing direct Pimple access in templates with prefixed Twig functions. It also renames classes and namespaces and changes template and i18n mechanisms. Any spike, fork, or adapter written against 0.13.x will need rework.
- Can I run CRUDlex as a separate admin service instead of embedding it in Laravel?
- Yes, and that is the lower-risk option. You can run the maintained CRUDlexSymfony4Bundle or CRUDlexSilex2 as an isolated admin application behind a reverse proxy or an API boundary, keeping it out of the Laravel monolith. That avoids building and owning a Laravel adapter and limits exposure to its unsupported runtime. The trade-off is a second application to deploy, secure, and maintain.