Propel Admin Bundle Laravel Package

Getting Started

Read this first: you cannot install this in a Laravel app. sonata-project/propel-admin-bundle is a Symfony bundle, not a Laravel package. It integrates three things that do not exist in a standard Laravel project:

• SonataAdminBundle — Symfony's admin CRUD generator (the thing this bundle extends).
• PropelBundle — Symfony's integration for the Propel ORM (not Eloquent, not Doctrine).
• Propel itself — a largely abandoned PDO-based ORM.

The bundle is archived and deprecated. The last supported combination is roughly Symfony 2/3 + SonataAdmin + Propel 1.x. There is no Laravel service provider, no facade, no Eloquent bridge, no Blade views (Sonata admin uses Twig).

Minimal steps if you were on Symfony (for context only):

1. composer require sonata-project/propel-admin-bundle
2. Register SonataPropelAdminBundle alongside SonataAdminBundle and PropelBundle in AppKernel.
3. Configure a Propel connection and schema.xml.
4. Register an admin service extending Sonata\PropelAdminBundle\Admin\Admin and tag it sonata.admin.

For a Laravel developer, the "first use case" is really: recognize the pattern and use a Laravel-native equivalent. If you want a Sonata-style admin panel over Eloquent, look at Filament (closest conceptual match: resource classes, list/edit/show pages, filters, actions), Laravel Nova, or Backpack for Laravel. If you want the ORM-agnostic admin abstraction this bundle tried to provide, that abstraction belongs at the repository layer in a Laravel app — not as a third-party bundle.

Implementation Patterns

Even though you won't run this bundle, the workflow it encodes maps cleanly onto patterns Laravel developers adopt every day:

• Admin class per model. In Sonata, you create one admin class per model (e.g., BookAdmin), configure list, form, filter, and show fields, and register it as a tagged service. In Filament this is BookResource; in Nova it's Book extends Resource. The mental model is identical — one class describes how a model is browsed, edited, and filtered.
• Field configuration is declarative. The bundle exposes configureListFields, configureFormFields, configureDatatableFilters (Propel-aware). Translate this directly into Filament's form(Form $form) / table(Table $table) or Nova's fields().
• Schema-first CRUD. With Propel, the model is generated from schema.xml — you don't hand-write models. This is the reverse of Laravel's migration-first workflow. If you're porting concepts, remember that in Laravel your migrations are the schema source of truth and the admin layer reads from that, not the other way around.
• Batch actions and custom actions. Sonata actions (delete, export, custom routes) map to Filament Action/BulkAction classes or Nova Action classes. This bundle's action registration is the direct ancestor of those APIs.
• Integration tip for a Laravel port. Encode the "admin class per model" pattern as a Filament Resource and register policies via Laravel's Gate/Policy. Do not try to bolt Propel onto Laravel just to use this bundle — the impedance is total (Propel objects vs. Eloquent models, Propel Peer classes vs. Eloquent query builders, schema.xml vs. migrations).

Gotchas and Tips

• Archived = no security patches. Do not add this to any codebase with a dependency scanner (Dependabot, Composer audit) — it will flag and you cannot upgrade out of it except by replacing it. There are 0 dependents on record and 14 stars; there is effectively no community support.
• Propel is the real problem. Even in Symfony ecosystems, Propel was superseded by Doctrine and, for new Symfony work, by the Doctrine ORM. Committing to this bundle means committing to a dead ORM. A Laravel developer should treat any "bring Propel into Laravel" idea as a hard no — Eloquent + migrations + Filament cover the same ground with maintained tooling.
• No Twig → Blade mapping. Sonata overrides templates via Twig. There is no sensible path to reuse these views in Laravel. If you like a Sonata template, port the layout intent, not the file.
• Service-tag configuration is Symfony-specific. The sonata.admin tag with manager_type, label, model_class attributes has no Laravel analog. Closest equivalents: Laravel's service container binding + Filament's automatic resource discovery, or Nova's Nova::resources() registration.
• Debugging. In Symfony you'd lean on the web profiler's admin panel and Sonata's sonata_admin config dump. In Laravel, the analog is Telescope plus Filament's debug toolbar and php artisan about for package state — useful to know if you're reading Sonata docs while designing a Laravel port.
• Extension points worth copying conceptually. Admins here can override list/form/show templates, register custom routes/controllers per admin, and add custom datagrid filters. Each of these is a supported, maintained feature in Filament (Resource::getPages(), custom tables, Filter classes). Copy the shape of the extension points, not the implementation.
• Bottom line for a Laravel developer: treat this repository as a historical reference for the "admin class per model" pattern, not as a dependency. The correct day-to-day move is to install Filament (or Nova/Backpack) and never look at this bundle again unless you're migrating a legacy Symfony+Propel admin off it.