smirik/propel-admin-bundle
Symfony bundle that adds a Propel-powered admin backend: generate CRUD screens, lists, forms, and filters for your models with minimal configuration. Useful for quickly building management panels in Propel-based Symfony apps.
A v1.0.0 tag now exists — the release note is a one-liner ("officially live, feel free to use it") with no changelog, no compatibility matrix, and no migration notes. Treat that as a signal the project is alive again, not as evidence it supports your stack. The bundle was built for Symfony 2.x + Propel 1.x; nothing in the release note claims otherwise, so verify before committing.
Minimal path:
Install via Composer, pinning the new tag rather than tracking the branch:
"require": {
"smirik/propel-admin-bundle": "^1.0"
}
If Packagist metadata hasn't caught up with the tag, temporarily fall back to dev-master plus minimum-stability: dev and a repositories entry pointing at the GitHub repo — but get back to a tag before you ship.
Probe compatibility before you build anything. With no changelog, the fastest read is the tagged commit itself: check composer.json for require constraints (PHP, Symfony, Propel) and eyeball a few classes for scalar type hints or array() syntax. Five minutes here saves a day of debugging "class not found" later.
Enable the bundle in app/AppKernel.php:
new Smirik\PropelAdminBundle\SmirikPropelAdminBundle(),
Confirm Propel is wired up. The bundle has no ORM of its own — it reads your propel config and existing model classes. Run app/console propel:build first so the admin generator has models to point at.
Look first at the bundle's Resources/config/ (routing and service definitions) and any Admin/ example classes shipped in Tests/ or the README. Documentation is still thin; the admin base class and its template defaults are your real reference.
First use case — expose a list view for one model:
/admin)./admin/<your-entity> and confirm the grid renders.If that single list view renders, the rest of the bundle (filters, forms, actions) follows the same per-model admin-class pattern.
One admin class per Propel model. The core workflow is unchanged: for each Propel table you want to manage, write a small admin class declaring list columns, form fields, and available actions. This is the closest analogue to Sonata's Admin classes but scoped to Propel's generated Peer/Query objects rather than Doctrine repositories.
Declarative field configuration. Typical day-to-day work is editing arrays of field definitions: label, type (text, textarea, select, date, relation), sortable flag, and whether the field is shown in list vs. form. Treat this config as the "schema" for your admin screens and keep it in one method per view (list/form) so diffs stay readable.
Filters via Propel Query objects. Where the bundle exposes filtering, it usually hands you a ModelQuery instance you can ->filterBy...() on. Pattern: build a base query in your admin class, apply user-supplied filters from the request, then let the bundle paginate. Keep custom filter logic in a dedicated method, not inline in the action.
Custom actions. Beyond CRUD, admins typically add "publish", "export", "duplicate" style actions. Implement them as methods on the admin class and wire them into the action list; the bundle's routing then dispatches to them. Prefer small, single-purpose actions over one overloaded handler.
Template overrides. Point your app/Resources/SmirikPropelAdminBundle/views/ at the bundle's templates and override per-view (list, form, layout) rather than editing vendor files. This is the intended extension point and the only thing that survives a Composer update — which matters more now that updates are actually plausible again.
Routing and menu integration. Import the bundle routes under an admin prefix and register entries in whatever admin menu you have. Because the bundle predates modern menu builders, expect to hand-write menu entries pointing at the generated route names.
Pin, then read the diff. If you upgrade an existing install, diff the v1.0.0 tag against whatever commit you were on. The absence of a changelog means the diff is the changelog — watch for renamed config keys, changed route name patterns, and template moves, since any of those break overrides silently.
"Officially live" is not a compatibility statement. The release note tells you the maintainer still cares; it doesn't tell you Symfony 5/6 or PHP 8 support. Confirm against composer.json constraints and a real smoke test before planning around it.
The stack is still the trap. The real cost is standing up Symfony 2 + Propel 1. If you're greenfield, this bundle isn't a reason to pick that stack. It's viable inside an app that already lives there — and slightly more viable now that tags exist.
No changelog = unmarked breaking changes. With one prior known release in 2013 and a jump straight to 1.0.0, you can't assume additive-only. Read the diff, or run the new tag on a branch and exercise your admin screens before merging to master.
One release is not a maintenance track. A single v1.0.0 after a decade of silence suggests revival, not a cadence. Keep the same defensive posture: audit anything that renders user input (list columns, labels, custom templates) for XSS yourself rather than trusting 2013-era defaults, and don't assume future security patches.
PHP 5.x idioms may remain. Expect array() syntax and no scalar type hints unless the tag says otherwise. Code that old trips deprecation warnings (or fatals) on PHP 7.4+; budget time for a compatibility fork if you need to run it forward.
Propel models must exist first. The bundle generates UI over generated models; it does not generate the schema. propel:build failures cascade confusingly into "class not found" errors from the admin layer. Verify models load standalone before debugging the admin.
Routing name collisions. Generated route names derive from the model/prefix; two admin classes with similar names can collide. Dump app/console router:debug and grep for the admin prefix when a URL 404s.
Cache is your first suspect. After editing an admin class or its config, run app/console cache:clear — Symfony 2's container caching makes config changes appear not to take effect otherwise. Also check propel runtime config caching if you change connection settings.
Debugging views. When a list renders blank, it's usually a field type the template doesn't know how to render. Temporarily strip the admin config to one plain text column to isolate the offending definition.
Extension points are limited. You have three realistic levers: subclass the admin base class, override templates, and register custom services/actions. Don't monkey-patch the bundle's core services — with a live release track, your patch is now something you have to re-apply on every update.
Vendoring is still defensible, but less urgent. The v1.0.0 tag removes the immediate "deleted GitHub repo breaks my build" risk. Pin the tag (or a commit hash) and keep a private fork mirror; drop the in-tree vendoring only once you see evidence of a release cadence.
How can I help you explore Laravel packages today?