Easyadmin Plus Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package. There is no service provider, no config/easyadmin_plus.php, and no Laravel integration of any kind. If you are working in a Laravel app, the answer is simply: you can't use it — you'd be adopting Symfony's EasyAdminBundle first. If you're in a Symfony app (typically a back-office/admin), proceed.

Minimal steps:

1. composer require wingu/easyadmin-plus-bundle — confirm the constraint it pulls for easycorp/easyadmin-bundle. Any mismatch here is the most common first failure.
2. If Flex doesn't auto-register it (it very likely won't, given the low adoption), add it manually to config/bundles.php:

   Speicher210\EasyAdminPlusBundle\EasyAdminPlusBundle::class => ['all' => true],
   

3. Clear cache (bin/console cache:clear) and verify what it actually registered before assuming anything:

   bin/console debug:container --tag=form.type
   bin/console debug:container --tag=twig.extension
   bin/console debug:config easyadmin_plus   # if a config tree exists
   

4. Read the repo's src/ and src/Resources/config/services.* before the README — for a package this small, the source is the documentation. That tells you exactly which field types, form types, and services exist.

First use case: don't adopt the bundle wholesale. Add one of its field types (or form types) to an existing AbstractCrudController::configureFields() next to a plain TextField, load the form, and confirm it renders. That validates registration, assets, and EasyAdmin version compatibility in one shot, before you touch any CRUD controllers.

Implementation Patterns

• Field-type-first adoption. The lowest-risk pattern is cherry-picking individual field/form types rather than restructuring controllers. Add one, use it on one entity, then expand if it earns its place.
• Inherit once, benefit everywhere. If the bundle ships a CRUD trait or base class, wrap it in your own AbstractAdminCrudController and have all admin controllers extend that. You keep a single seam for later removal.
• Compose, don't inherit, when possible. Prefer injecting the bundle's services into your controller over extending its classes — Symfony's DI makes this cheap, and it makes the dependency swappable.
• Configure in YAML, keep it tiny. Put bundle config in config/packages/easyadmin_plus.yaml, but only for keys you've verified exist in DependencyInjection/Configuration.php. Undocumented config keys fail loudly at container build, which is at least a fast failure.
• Template overrides. Copy the template you want to change into templates/bundles/<BundleAlias>/... (take the alias from the bundle class's getName()/getPath()), rather than editing vendor/.
• Feature-flag the integration. Since adoption is near zero, gate the bundle's behavior behind a config flag so you can flip back to stock EasyAdmin if it stops being maintained.
• Test with a functional test. A single request to the admin route asserting the custom field renders is worth more than any unit test here — most breakage shows up as "field silently rendered as default."

Gotchas and Tips

• Version alignment with EasyAdmin. EasyAdmin 4 changed field configuration, actions, and templates significantly. Pin both packages and re-read the field/config APIs after any major bump. This is the #1 source of breakage with plus-bundles.
• Zero dependents / near-zero stars. No community support, no Stack Overflow answers, no guarantees. Budget for reading the source and potentially forking it. Treat it as vendored code you own.
• Symfony-only. Reiterating because it matters: no Laravel adapter exists, and none is coming. Don't plan around one appearing.
• Silent field-type failures. EasyAdmin field types are referenced by short string names. A typo or a missing registration doesn't throw — the field just renders as the default. Confirm the name with debug:container --tag=form.type and assert rendering in a test.
• Assets. If the bundle ships public assets, run bin/console assets:install --symlink (or your webpack/asset pipeline equivalent) or you'll get unstyled/broken widgets that look like field bugs.
• Cache after registration. Adding the bundle or changing its config without cache:clear produces confusing "class not found" or missing-field behavior that has nothing to do with your code.
• Inspect Configuration.php for the real config surface. README files in low-adoption bundles go stale; the DependencyInjection/Configuration.php tree is definitive.
• Extension point to lean on: Symfony's FieldConfigurator/FieldFactory (EasyAdmin) is where you'd extend field behavior yourself. If the bundle's field type does almost what you want, override it there rather than patching vendor code — that survives composer update.
• Exit criterion. Before adopting, write down which specific feature is missing from stock EasyAdmin that this package provides. EasyAdmin 4 covers a lot of what plus-bundles did for EasyAdmin 2/3 — if the answer is "not much," skip the dependency.