Easyadmin Fields Bundle Laravel Package

Getting Started

Install and register the bundle (there is no Flex recipe, so registration is manual):

composer require insitaction/easyadmin-fields-bundle

Add it to config/bundles.php if it isn't already there:

return [
    // ...
    Insitaction\EasyAdminFieldsBundle\EasyAdminFieldsBundle::class => ['all' => true],
];

Check your platform first. v5.1.0 adds Symfony 7 compatibility. If you're on Symfony 7 you also need PHP 8.2+ and EasyAdmin 4.9+ (the first EasyAdmin release that supports Symfony 7). Confirm the installed constraints before debugging anything else:

composer show insitaction/easyadmin-fields-bundle
cat vendor/insitaction/easyadmin-fields-bundle/composer.json

Where to look first: the field classes live under src/Field/ in the vendor directory. Run ls vendor/insitaction/easyadmin-fields-bundle/src/Field (or grep -r "class .*Field" vendor/insitaction/easyadmin-fields-bundle/src) to enumerate exactly what's available in the version you installed — the README is terse and the source is the source of truth. Also check src/Twig/ and templates/ for rendering helpers, and Resources/assets/ (or assets/) for JS/CSS shipped with interactive fields.

First use case: drop a custom field into an existing EasyAdmin CRUD controller's configureFields() exactly like a native field:

use Insitaction\EasyAdminFieldsBundle\Field\SomeField; // verify the FQCN from src/Field

public function configureFields(string $pageName): iterable
{
    yield IdField::new('id')->hideOnForm();
    yield SomeField::new('propertyName');
}

If any field renders interactive widgets (pickers, autocompletes), publish assets once:

php bin/console assets:install --symlink public/
php bin/console cache:clear

Implementation Patterns

Treat custom fields as drop-in FieldInterface implementations. They compose with EasyAdmin's fluent API, so you can chain ->hideOnIndex(), ->setLabel(), ->setHelp(), ->onlyOnDetail() just like built-ins. That means incremental adoption: swap one field at a time and keep the rest of the CRUD as-is.

Configure via form-type options and custom options. Most custom fields pass configuration down to an embedded FormType, so the pattern is:

yield SomeField::new('price')
    ->setFormTypeOption('currency', 'EUR')
    ->setCustomOption('decimals', 2);

Inspect the field's setFormTypeOptions/buildForm in the source to know which knobs exist — undocumented options are common in small bundles.

Reuse in both index and detail views. Fields that format values (money, phone, color swatches) usually implement formatValue(). Verify by rendering the same field on index and detail; if formatting differs, override the field's template or wrap it with ->setTemplatePath().

Centralise repeated field configuration. If you find yourself applying the same options across controllers, add a small private method or a trait in your app:

private function priceField(string $property): SomeField
{
    return SomeField::new($property)->setFormTypeOption('currency', 'EUR');
}

Don't try to subclass the bundle's fields unless you need different behaviour — EasyAdmin resolves templates by class name, so subclassing quietly points at the parent's template.

Template override extension point. Every field's rendering goes through a Twig template. Override it in your app by mirroring the path under templates/bundles/EasyAdminFieldsBundle/... — no fork required. Use bin/console debug:twig to find the exact name.

Pair with standard EasyAdmin form types for validation. Custom fields rarely replace validation; keep constraints on the entity and let the field be a presentation layer.

Gotchas and Tips

• No Flex recipe. The bundle won't auto-register. If fields silently fail to appear (blank cell, missing widget), the bundle is almost certainly not in config/bundles.php.
• Assets are the usual culprit. Interactive fields break with a console error about a missing JS/CSS file until you run assets:install and clear cache. Check public/bundles/ for the bundle's directory.
• Symfony 7 needs the newer release. v5.1.0 is the first line advertising Symfony 7 support — on a Symfony 7 app, pin ^5.1 at minimum. Older 4.x/5.0 installs will hit container/DI signature errors at boot (or resolve to an incompatible symfony/* set) even though composer require "succeeds". Check composer why-not if you're stuck on an older tag.
• Symfony 7 also bumps the floor on EasyAdmin and PHP. Symfony 7 support is only meaningful with EasyAdmin 4.9+ and PHP 8.2+. A composer.json that satisfies all three is the real compatibility gate — verify it rather than assuming.
• Version pin and audit. The bundle is small and low-traffic; pin an explicit version in composer.json and skim src/Field/ before upgrading. There's no guarantee of a SemVer-stable public API, and "Symfony 7 compatibility" alone doesn't promise backward compatibility for field option names.
• EasyAdmin major-version alignment. The bundle targets EasyAdmin 4.x. Mixing with EasyAdmin 3.x or an unreleased 5.x will produce FieldInterface signature errors at boot; check the composer.json constraint in the vendor package.
• setCustomOption vs setFormTypeOption. Custom options are read by the field's template/formatValue; form-type options are read by the embedded form. Passing the wrong one silently does nothing — confirm in the field source which it consumes.
• Name collisions. If you later add an EasyAdmin built-in field with a similar name (e.g. a native money field), imports get ambiguous. Alias imports explicitly: use Insitaction\...\MoneyField as InsitactionMoneyField;.
• Debugging rendering: use bin/console debug:twig for the template, and in a controller dump the field's resolved config with dump($field->getAsDto()) (or inspect FieldDto) to see whether your options actually landed.
• Extension points, ranked by safety: (1) chained field options, (2) Twig template overrides in your app, (3) a local wrapper service that returns configured field instances, (4) subclassing — avoid unless you also override getTemplatePath().

Overall: a small, useful toolbox for Insitaction-style EasyAdmin projects. v5.1.0 is a compatibility release rather than a feature release — the day-to-day value is unchanged, but it finally makes the bundle viable on Symfony 7 stacks. Adopt it field-by-field, verify each field's options in source, and pin the version.