Sonata Admin Extended Bundle Laravel Package

Getting Started

This bundle is a thin convenience layer over Sonata Admin: an abstract admin base class plus helpers that cut the boilerplate (container, translator, doctrine, security) out of every Admin subclass. It is archived (last release Feb 2014), so treat it as a legacy-app dependency, not something to adopt today.

Check viability before installing anything:

# See what Symfony/Sonata versions the bundle actually constrains
cat vendor/presta/sonata-admin-extended-bundle/composer.json

If you are not on Symfony 2.x with Sonata Admin 2.x, stop here — the API it extends no longer exists. If you are on that stack:

composer require "presta/sonata-admin-extended-bundle:~1.0"

Register it in app/AppKernel.php after the Sonata bundles (SonataCoreBundle, SonataAdminBundle, SonataDoctrineORMAdminBundle), then clear the cache.

Look at these files first, in order:

1. Admin/ — the abstract admin class(es) and any traits. This is the whole value proposition; read it before anything else.
2. DependencyInjection/Configuration.php — the available config keys under presta_sonata_admin_extended: (many Presta bundles of this era expose almost nothing here, but confirm).
3. Resources/config/ — service definitions and any compiler pass wiring.
4. Resources/views/ — template overrides if the bundle ships any.

First use case: take one existing admin service and change its parent from Sonata\AdminBundle\Admin\Admin to the bundle's base class. Delete the hand-rolled getContainer(), getTranslator(), trans() and getEntityManager() helpers, then verify with:

app/console sonata:admin:list
app/console sonata:admin:explain app.admin.foo

If both still work, you have a safe incremental migration path for the rest.

Implementation Patterns

Abstract-admin inheritance. The primary day-to-day pattern is one base class shared by every admin in your app:

// Acme\AdminBundle\Admin\AbstractAdmin
use Presta\SonataAdminExtendedBundle\Admin\AbstractAdmin as BaseAdmin;

abstract class AbstractAdmin extends BaseAdmin
{
    // your own project-wide defaults: translation domain,
    // default templates, datagrid filter shortcuts, etc.
}

Then each concrete admin extends your abstract, not the bundle's, and not Sonata's. That gives you one place to react if the bundle is ever vendored or replaced.

Service registration stays standard Sonata. The bundle does not replace the tag-based registration; keep each admin as a tagged service:

app.admin.article:
    class: Acme\AdminBundle\Admin\ArticleAdmin
    tags:
        - { name: sonata.admin, manager_type: orm, group: content, label: Articles }
    arguments: [null, Acme\ContentBundle\Entity\Article, 'SonataAdminBundle:CRUD']

The win is inside the class body: configureListFields, configureFormFields and configureDatagridFilters get shorter because you call local helpers instead of injecting @service_container everywhere.

Helper methods in configuration callbacks. Typical usage inside the configure* methods:

protected function configureFormFields(FormMapper $form)
{
    $form
        ->add('title', null, ['label' => $this->trans('form.label.title')])
        ->add('body', null, ['attr' => ['class' => 'ckeditor']]);
}

Any helper the base class provides that reaches for the container or translator is fair game here — that is the entire point of the bundle.

Template override strategy. Point getTemplate() at your app's templates rather than editing vendor files. Note the bundle-era templates likely use the colon notation (PrestaSonataAdminExtendedBundle:Admin:edit.html.twig); mirror that notation in your app until you are ready to modernise.

Integration with a Presta/legacy stack. If the app already depends on other Presta bundles of the same vintage (PrestaCMS, PrestaSitemap), keep the bundle load order consistent with them and reuse a single shared abstract admin across the whole family. Mixing two different "extended admin" bases is the fastest way to get confusing method-resolution behaviour.

Adoption as a copy, not a dependency. Because the bundle is small, the more durable pattern is to vendor the handful of classes from Admin/ into your own AdminBundle and delete the composer requirement. You get the helpers without inheriting the 2014 constraint set.

Gotchas and Tips

• Archived means frozen, not stable. No security patches, no Symfony/Sonata compatibility work. Do not install it into a new project; audit composer.lock before adding it to an old one.

• Transitive version pinning. The bundle's Sonata constraint will dictate your whole Sonata version. Run composer why sonata-project/admin-bundle after install to see whether the bundle is the thing holding you back from an upgrade — it usually is.

• PSR-0 era autoloading. Expect old-style paths and class names; if composer dump-autoload -o fails to find a class, check composer.json autoload for psr-0 versus psr-4.

• Name collisions on AbstractAdmin. You now have Sonata\AdminBundle\Admin\AbstractAdmin, the bundle's abstract, and your own. Always alias on import; unqualified AbstractAdmin in a subclass is a classic silent-wrong-parent bug.

• Colon-notation templates break on Symfony 3+. Bundle:Section:file.html.twig was removed. If you ever bump Symfony, every getTemplate() return value and every {% extends %} needs converting to @Bundle/section/file.html.twig.

• DI changes need a cache clear, not just a refresh. The container is compiled; if you edit Configuration.php or service definitions, app/console cache:clear --env=dev before assuming your change did nothing.

• Debugging the service graph:

  app/console container:debug --tag=sonata.admin
  app/console sonata:admin:explain app.admin.article
  

  The first tells you which admins are actually registered (a missing tag is the usual cause of "admin doesn't appear in the dashboard"); the second dumps the resolved configuration for one admin, which is where you'll see the effect of the base class's defaults.

• PHP runtime ceiling. Code from 2014 triggers deprecations on PHP 7.4+ and will not parse on PHP 8 if it uses removed constructs. Pin the CI image to whatever PHP version your app already runs and do not bump it on this bundle's behalf.

• Extension points, in order of preference: (1) subclass the bundle's abstract admin in your app and override helpers there; (2) override templates via getTemplate(); (3) copy the classes into your own bundle if you need to change behaviour; (4) fork — last resort, since you then own an archived fork.

• Removal checklist. If you decide to drop the dependency: grep for the bundle's namespace, replace each parent class with Sonata's Admin (or your own abstract), inline the helper methods you actually used, remove the bundle from AppKernel, and run sonata:admin:list plus a spot check of each admin's list/edit/new screens. The bundle typically has few enough call sites that this is an afternoon, not a migration project.