Easyadmin Plus Bundle Laravel Package

Getting Started

Reality check first: protung/easyadmin-plus-bundle is a Symfony bundle for EasyAdmin, not a Laravel package. It has no service provider, no facade, no config/easyadmin-plus.php, and Composer will not auto-discover it. You get day-to-day leverage from it only when you're in a Symfony codebase (legacy app you maintain, a client project, or a Symfony admin service alongside your Laravel APIs). In a pure Laravel app, the equivalent value lives in Filament/Nova — read this package's action/modal patterns as design reference, not as a dependency.

Minimal steps in a Symfony host app:

1. composer require protung/easyadmin-plus-bundle — for this release's features you also need EasyAdmin 5.7+ (composer require easyadmin/core:^5.7). On 5.6 the constraint resolution in v0.4.1 will simply not let you in.
2. Register the bundle in config/bundles.php:

   return [
       // ...
       Protung\EasyAdminPlusBundle\EasyAdminPlusBundle::class => ['all' => true],
   ];
   

3. If the bundle ships assets/Twig overrides, run php bin/console assets:install and clear cache (bin/console cache:clear).
4. First use case (the v0.4.1 headline): give a custom action a confirmation dialog with a real title and body instead of the bare default prompt. Look at src/ for the ConfirmationModal class and any Action/Field/Filter directories — that's the map of everything the bundle adds on top of EasyAdmin.

Implementation Patterns

Confirmation modal on a custom action (new in v0.4.1). The pattern is to build the action, attach a confirmation modal carrying title + body, then register it in the CRUD controller:

// in your CrudController
public function configureActions(Actions $actions): Actions
{
    $refund = Action::new('refund', 'Refund order', 'fa fa-undo')
        ->linkToCrudAction('refund')
        ->setConfirmationModal(/* ConfirmationModal with title + body */);

    return $actions->add(Detail::class, $refund);
}

The v0.4.1 value is that the confirmation is no longer a naked browser confirm() string — you can state what will happen and why it can't be undone. Treat the title as a short imperative ("Refund €149.00?") and the body as consequences ("The customer is notified immediately. This cannot be undone."). Pull amounts/IDs into the body dynamically from the entity where the API allows a callable/closure.

Custom action controller flow. Keep the handler thin and idempotent — the modal is UI only, so the server side must still validate state (already refunded? permission?) and redirect back with a flash:

public function refund(AdminContext $context): Response
{
    $order = $context->getEntity()->getInstance();
    // guard clauses, dispatch a command/message, no business logic here
    $this->addFlash('success', 'Refund queued.');
    return $this->redirect($context->getReferrer());
}

Compose with EasyAdmin primitives. Everything in this bundle layers on Action, Field, Filter, CrudController. So the integration tip is: don't fork the bundle to tweak behaviour — extend the CRUD controller, override configureActions()/configureFields(), and use EasyAdmin's own Action::setHtmlAttributes(), displayIf(), permission checks (->setPermission()) around the plus-bundle pieces.

Version pinning per project. Because v0.4.1 widens the EasyAdmin constraint to 5.7, keep the pair pinned together in composer.json ("protung/easyadmin-plus-bundle": "^0.4.1" with easyadmin/core:^5.7) so a future EasyAdmin 6 bump doesn't silently break the modal API.

Laravel-side pattern reuse. If you're porting the idea: the direct analogues are Filament Action::make()->requiresConfirmation()->modalHeading()->modalDescription() and Nova ConfirmAction. Same contract — presentation-only confirmation plus a re-validated server handler. Worth copying the title/body split into your Laravel admin actions.

Gotchas and Tips

• Pre-1.0 churn. This is 0.4.x. Minor bumps have already moved framework constraints (5.7 support landed in a patch release). Pin exact-ish versions and read the diff before composer update on a shared admin.
• Constraint conflict is the #1 install failure. If Composer says the bundle can't be installed, check easyadmin/core first — v0.4.1's whole point was allowing 5.7, and older pins will fight it. composer why-not easyadmin/core 5.7 is the fastest diagnosis.
• Bundle not registered = silent nothing. Unlike Laravel package discovery, forgetting config/bundles.php gives you "class not found" on the bundle's services rather than a friendly error. Register it, then bin/console debug:container | grep -i easyadmin to confirm services loaded.
• Modal is UI, not a guard. The confirmation title/body do not protect the endpoint. Anyone can hit the action URL directly — always re-check permission and entity state in the action method (and ideally use EasyAdmin's setPermission()/voters).
• Asset/cache staleness. A new modal can appear unstyled or not at all until assets:install + cache:clear run, and Symfony's Twig cache can mask bundle template overrides. If the modal renders without the title/body, suspect stale assets before suspecting the bundle.
• Translation and escaping. Titles/bodies are rendered as HTML in most EasyAdmin modals — never interpolate raw user input (customer names, order notes) without htmlspecialchars/Twig escaping, or you've built an admin-panel XSS.
• Debugging config. bin/console debug:config easyadmin and dumping the built Action config in a test are faster than reading Twig. A quick functional test asserting the modal config exists ($action->getAsDto()->getConfirmationModal()) will catch regressions on future EasyAdmin upgrades.
• Extension point over fork. The bundle is small; if you need a different modal shape, decorate the action or build your own Action subclass in your app rather than patching vendor/.