- Does kunicmarko/sonata-auto-configure-bundle work with Laravel?
- No. This is a Symfony bundle that hooks into Symfony's dependency injection container at compile time to register Sonata Admin classes and apply sonata.admin tags, and Sonata Admin itself is built on Symfony components. Laravel has no equivalent compiler-pass model and no Sonata Admin port, so adopting this package would mean porting Sonata Admin first. For a Laravel application, build the admin CRUD layer natively with Nova, Filament, or a custom panel instead.
- How do I install kunicmarko/sonata-auto-configure-bundle?
- Install it with Composer using composer require kunicmarko/sonata-auto-configure-bundle, then register the bundle in config/bundles.php on Symfony 4 and later, or in AppKernel on Symfony 3.4. It assumes Sonata Admin is already installed and configured, since it only removes the repetitive per-admin service wiring. Pin to an exact version because the package is pre-1.0 and offers no semantic versioning guarantee.
- Which Symfony and Sonata Admin versions does this bundle support?
- The constraint set is 2019-era, targeting roughly Symfony 3.4 and 4.x with Sonata Admin 3.x. The 0.7.1 patch is a single-scope bugfix and does not signal modernized CI or added support for Symfony 5+, Symfony 6+, or PHP 8.x. Run composer why-not against your target Symfony version and confirm your Sonata Admin major before committing to it.
- How does the bundle automatically register Sonata Admin classes?
- It uses convention over configuration during the container compile phase, discovering classes that look like Sonata admins and applying the required sonata.admin tags without you writing service definitions. That removes the repetitive XML or YAML boilerplate you would otherwise maintain for every admin screen. Because it works through a compiler pass, all of the work happens when the container is built rather than at runtime.
- Do I still need to configure Sonata Admin manually after installing it?
- Yes. The bundle only automates the registration and tagging of admin classes, so Sonata Admin itself still needs its own installation, routing, assets, security roles, and global configuration. Global extensions and dashboard blocks are still configured by hand in your Sonata config. Think of this package as a boilerplate reducer for service definitions, not a full Sonata Admin setup tool.
- Is kunicmarko/sonata-auto-configure-bundle still maintained?
- The repository was previously archived with no release since March 2019, but a 0.7.1 patch was published, so calling it abandoned outright is no longer accurate. There is still no evidence of new maintainership, a roadmap, modern CI, or a security response process, and it remains at 0.x with zero dependents. The practical framing is dormant but not dead, which means you should vendor or fork it rather than treat it as a supported dependency.
- What does the 0.7.1 release of this bundle fix?
- Version 0.7.1 fixes multiple global extensions not working, meaning the configuration aggregation logic produced incorrect results when more than one extension of the same type was registered. If your admin inventory never registers multiple extensions of the same type, you probably never hit the bug and the release changes nothing for you. If you applied a workaround for that defect, verify it still behaves correctly after upgrading, since the behavior it patched around has changed.
- Does this bundle affect runtime performance or require database migrations?
- No. Everything the bundle does happens at container compile time, so there is no runtime dependency, no schema change, and no data migration. Deployment impact is limited to cache warmup when the container is rebuilt. The only real integration cost is verifying that the bundle's constraints resolve alongside your existing Sonata Admin and Symfony versions.
- How do I test that admin classes are being auto-configured correctly?
- Write a container compile test or a small functional test that boots a kernel and asserts the expected admin services exist and carry the sonata.admin tag. That catches discovery problems, namespace exclusions, and the multi-extension aggregation issue in one place. Do this in a spike before adopting the bundle so you know exactly which classes get registered in your application.
- What are the alternatives to kunicmarko/sonata-auto-configure-bundle?
- The safest alternative is to write the sonata.admin service tags and resource registration explicitly in services.yaml, optionally leaning on Symfony's autoconfigure and _instanceof configuration. That keeps the behavior visible and removes a pre-1.0 dependency from your stack. If your application is Laravel rather than Symfony, the alternatives are Nova or Filament, since Sonata Admin does not run there at all.