- What is glifery/crud-abstract-data-bundle?
- It is a Symfony bundle that provides an abstract CRUD layer decoupled from a concrete data source. The abstraction separates create, read, update, and delete operations from the underlying provider. It is not a Laravel package and has no Laravel service provider or package discovery support.
- Can I install glifery/crud-abstract-data-bundle in a Laravel app?
- You should not expect a clean Composer install in a modern Laravel app. The package is built around Symfony bundle registration and Symfony 2.x-era dependencies, while Laravel uses service providers and its own container conventions. Forcing constraints would create an unsupported dependency graph. Treat it as reference code rather than a dependency.
- Does this package support Laravel 10 or Laravel 11?
- No. There is no published Laravel compatibility matrix, no service provider, and the last release was December 2015. Modern Laravel versions run on PHP 8.x and Symfony 6/7 components, which are far beyond the package's likely target. You would need a fork or compatibility shim, which removes most of the benefit.
- Is glifery/crud-abstract-data-bundle maintained?
- No active maintenance is evident. The repository has zero stars, zero dependents, and a last release from December 2015. That means no security patching, no PHP 8 support, and no community validation. Do not rely on it for production.
- What PHP and Symfony versions does it require?
- The 2015 release date strongly suggests PHP 5.5/5.6-era syntax and Symfony 2.x dependencies. The exact constraints should be confirmed in the repository's composer.json. Either way, those versions are long past end of life and conflict with current Laravel.
- Can I reuse the abstract data provider pattern in Laravel?
- Yes, the pattern is the useful part. Extract the idea of separating CRUD operations from the data source and reimplement it with Laravel-native contracts, repository interfaces, service provider bindings, form requests, and policies. This keeps the architectural insight without carrying abandoned Symfony code. Prototype one CRUD flow before standardizing it.
- What are maintained Laravel alternatives for CRUD admin panels?
- Evaluate Laravel-first tools such as Filament, Backpack, or Orchid, or a lightweight repository/service pattern if you need less scaffolding. These are designed for Laravel's container, authorization, and HTTP lifecycle. Compare maintenance status, PHP/Laravel version support, and license before choosing. Do not pick a package solely because its abstraction sounds similar.
- How should I evaluate this package safely?
- Timebox a one-to-two day spike to inspect composer.json, provider interfaces, and tests. Confirm dependency constraints and whether the provider contract can be extracted without Symfony framework coupling. Use the result as a decision gate: port the interfaces into Laravel-native code or close the evaluation. Do not install it into a production application.
- Is it safe to use in production?
- No. The primary risks are abandoned code with no security patching, unknown test coverage, Symfony-specific coupling, and PHP-version incompatibility. Forcing Composer resolution would produce a fragile, unsupported dependency graph. A TPM should treat it as a design reference, not a library to install.
- How do I migrate away from or fork this bundle?
- Do not migrate the package itself; migrate the idea. Extract the abstract provider contract and reimplement CRUD operations as Laravel-native repositories, service providers, validation, and authorization. If you fork, first verify the license permits internal maintenance and confirm which Symfony components are actually required. Then validate one CRUD flow before broader adoption.