- Is presta/pimp-my-sonata-bundle compatible with Laravel?
- No. It is a Symfony bundle built specifically for SonataAdminBundle, not a Laravel package. Laravel has no bundle or DI-extension model and no Sonata admin layer for it to hook into, so the integration surface is effectively zero. For Laravel admin theming, use Filament, Nova, or Backpack instead.
- How do I install presta/pimp-my-sonata-bundle?
- In a legacy Symfony app you would run composer require presta/pimp-my-sonata-bundle, register the bundle in AppKernel, and enable it alongside SonataAdminBundle. It also expects Twig and typically Assetic for asset handling. Note that the upstream repository is archived, so installation on a new project is not recommended.
- Which Symfony, SonataAdminBundle, PHP, and Twig versions are supported?
- The package targets the legacy Symfony 2.x/3.x era and an older SonataAdminBundle, with Twig and likely Assetic in the dependency chain. There is no published compatibility matrix, so you must inspect composer.json and test constraint resolution against your app. Expect conflicts with modern Symfony, Twig, and asset tooling.
- What does the bundle actually ship — Twig templates, CSS/JS assets, or config?
- Its purpose is overriding and restyling the Sonata admin UI, so it typically ships Twig template overrides, form themes, and CSS/JS under Resources/public. Before adopting it, audit composer.json, the DI extension, and Resources/views to confirm what is included. That audit determines whether you can extract a few files instead of inheriting the whole dependency.
- Is presta/pimp-my-sonata-bundle safe to use in production?
- Treat it as high risk. The repository is archived with zero stars and zero dependents, meaning no security patches, no bug fixes, and no version bumps for PHP, Symfony, Twig, or Sonata. Pinning it can also lock unpatched transitive dependencies across your whole application. Ownership of maintenance transfers entirely to your team.
- What are the alternatives to a Sonata bundle for admin UI theming in Laravel?
- Laravel does not use Sonata, so the equivalent choices are Filament, Laravel Nova, or Backpack. These are actively maintained and provide first-class theming, custom fields, and resource scaffolding. Matching your admin requirement to the right Laravel ecosystem tool is far cheaper than trying to bridge to a Symfony bundle.
- Will it work with Webpack Encore or Vite instead of Assetic?
- Unlikely. The bundle is from the Assetic era, and its asset assumptions will not line up with modern Symfony pipelines like Webpack Encore or Vite. If you only need the visual changes, port the CSS and JS into your own build instead of installing the bundle. Rewriting assets into SCSS/JS you control avoids the deprecated dependency entirely.
- How do I fork or vendor the bundle into my own codebase?
- The recommended approach is to diff its templates and assets against stock Sonata, extract only the visual changes you need, and reimplement them as local Twig overrides plus a small SCSS/JS layer. If you must fork, vendor the package into a private repository, pin the version, and treat it as internal code you own. Isolate overrides behind a theme layer or feature flags so they can be removed cleanly.
- How do I test admin screens after installing these overrides?
- Run a full regression pass on every Sonata admin screen: list, show, edit, filters, forms, datagrids, and bulk actions. Overrides can silently conflict with other admin customizations, producing hard-to-trace UI regressions, so cover each screen explicitly. Also verify behavior under both the stock Sonata theme and any other theme you run.
- Should I install it or use modern Sonata theming instead?
- Start by defining the concrete UI gap you need to close. Modern Sonata theming or a maintained admin theme may already solve it, which removes the need for an abandoned dependency. If the delta is small, reimplement the few visual changes locally and schedule a permanent replacement. Do not let a fork become the long-term solution.