Getting Started

This is a Symfony2-era bundle that extends sonata-project/doctrine-orm-admin-bundle. It is archived, has no stars, and no dependents, so treat it as legacy code you are inheriting or evaluating—not as a foundation for a new project.

Minimal steps:

Confirm the runtime constraints before installing:
- PHP version supported by the bundle
- Symfony 2.x version
- Sonata Admin / Sonata Doctrine ORM Admin versions
- Doctrine ORM version
Check composer.json in the repository first; those constraints determine whether the bundle can coexist with your application at all.
Install if the package is still resolvable:
```
composer require rz/doctrine-orm-admin-bundle
```
If Packagist no longer resolves it, vendor the repository or add a VCS repository entry and pin a commit.

new Sonata\CoreBundle\SonataCoreBundle(),
new Sonata\AdminBundle\SonataAdminBundle(),
new Sonata\DoctrineORMAdminBundle\SonataDoctrineORMAdminBundle(),
new Rz\DoctrineORMAdminBundle\RzDoctrineORMAdminBundle(),

Enable Sonata Admin routing and security as usual. This bundle is an extension, so Sonata Admin must already be working.
Look first at:
- DependencyInjection/Configuration.php for the bundle’s config tree
- Resources/config/ for service definitions and tags
- Admin/ for any base admin classes
- Form/, Filter/, or Extension/ for reusable admin building blocks
- Resources/views/ for template overrides
- tests/fixtures if present, since there is effectively no community documentation

First practical use case: create a normal Sonata admin service for one Doctrine entity, then check whether this bundle provides a base admin class, form type, filter, or admin extension that reduces boilerplate. If it does, extend or reference that service; if not, the bundle may only provide small integrations and you should keep the admin standard Sonata.

Example admin service registration:

services:
    app.admin.product:
        class: AppBundle\Admin\ProductAdmin
        arguments:
            - ~
            - AppBundle\Entity\Product
            - ~
        tags:
            - { name: sonata.admin, manager_type: orm, group: "Catalog", label: "Products" }
        public: true

Implementation Patterns

Use it as a thin Sonata extension

The most likely day-to-day value is reuse of admin classes, form types, filters, or admin extensions. Keep your own Admin classes small and delegate to the bundle’s base classes where they exist.

namespace AppBundle\Admin;

use Rz\DoctrineORMAdminBundle\Admin\AbstractAdmin; // verify exact class

class ProductAdmin extends AbstractAdmin
{
    protected function configureFormFields(FormMapper $formMapper)
    {
        $formMapper
            ->add('name')
            ->add('price')
            ->add('description');
    }
}

If the base class does not fit, extend Sonata’s AbstractAdmin directly and use only the bundle’s smaller services.

Reuse bundled form types and filters

When configuring admin forms or datagrids, prefer the bundle’s services/aliases if they exist rather than duplicating logic:

protected function configureDatagridFilters(DatagridMapper $datagridMapper)
{
    $datagridMapper
        ->add('name')
        ->add('createdAt', 'doctrine_orm_datetime_range');
}

Check Resources/config/ for the exact service IDs and aliases. In Symfony2 bundles, these are often not documented and must be read from the XML/YAML service definitions.

Register admin extensions if provided

If the bundle exposes an admin extension pattern, use the standard Sonata tag:

services:
    app.admin.extension.product:
        class: AppBundle\Admin\Extension\ProductAdminExtension
        tags:
            - { name: sonata.admin.extension, target: app.admin.product }

This is useful for cross-cutting behavior such as adding audit fields, enforcing permissions, or modifying queries without touching every admin class.

Override templates at the application level

Prefer overriding templates in your application rather than editing vendor code:

sonata_admin:
    templates:
        layout: AppBundle:Admin:layout.html.twig

Or place an override in app/Resources/SonataAdminBundle/views/... depending on the Sonata version. Because the bundle is archived, local overrides are safer than forks unless you need behavioral changes.

Keep the admin service graph explicit

Symfony2-era Sonata setups depend heavily on service tags and compiler passes. After adding or changing services:

php app/console cache:clear
php app/console debug:container --tag=sonata.admin

Verify that your admin appears in the Sonata admin pool and on the dashboard.

Gotchas and Tips

Archived and unsupported. Do not assume security fixes, compatibility updates, or documentation. Pin exact versions and budget time to read the source.
Zero dependents means zero community signal. If something breaks, there is no ecosystem to search. Use git log, tests, and service definitions as your primary documentation.
Symfony2 is EOL. This bundle will not fit a modern Symfony Flex/Symfony 5+ application without significant rewriting. Treat migration as a fork-and-modernize project, not an upgrade.
Sonata version coupling. This bundle likely depends on specific Sonata Admin and Sonata Doctrine ORM Admin versions. A minor Sonata upgrade can break form types, templates, or service definitions.
Doctrine ORM API drift. Legacy bundles often use deprecated or removed Doctrine APIs. Check for Doctrine\ORM\... calls that changed in Doctrine 2.5+ or later.
Service ID assumptions. Symfony2 bundles expose services through XML/YAML that may not match modern naming conventions. Always confirm IDs with:
```
php app/console debug:container | grep rz
```
Tag and compiler-pass issues. Admin services must be public in older Symfony versions and correctly tagged. Missing public: true or a missing sonata.admin tag results in admins not appearing.
Config quirks. Check DependencyInjection/Configuration.php for required nodes. Some bundles silently ignore unknown config or fail only at cache warmup.
Template overrides are safer than vendor edits. Since the bundle is archived, keep all customizations in your application or a maintained fork.
Extension points to prefer: service decoration, admin extensions, template overrides, and Doctrine event subscribers. Avoid patching the bundle in place unless you commit to maintaining a fork.
Debugging checklist:
- cache:clear after every service/config change
- debug:container --tag=sonata.admin
- confirm the admin’s manager_type: orm
- confirm the entity mapping is valid
- inspect the Sonata admin pool in the profiler or a small console command
If evaluating for adoption: the score and archive status make this a high-risk dependency. Use it only to understand or maintain an existing Symfony2/Sonata application. For new work, use a maintained Sonata Admin version or a modern admin generator instead.

Doctrine Orm Admin Bundle Laravel Package