Sonata Theme Bundle Laravel Package

Getting Started

First, calibrate expectations: this is a Symfony bundle (RaindropSonataThemeBundle) that themes sonata-project/admin-bundle. It is not a Laravel package — there is no service provider, no config/sonata-theme.php, and no Blade views. A Laravel developer should treat it as a design reference and template source, not a dependency to composer require into an existing Laravel app.

Where to look first, in order:

1. composer.json — read the require block. Confirm the Symfony and sonata-project/admin-bundle version constraints it targets. This tells you whether the templates are compatible with the Sonata version you might be evaluating.
2. Resources/views/ — the Twig templates that override Sonata's default admin layout (dashboard, list, show, edit, form).
3. Resources/public/ — CSS/JS/SCSS assets that define the visual theme; these are the most portable piece for a Laravel project.
4. DependencyInjection/ and RaindropSonataThemeBundle.php — see whether it only ships templates or also registers services/compiler passes.
5. Any Resources/config/ YAML — the theme likely expects to be wired into sonata_admin config.

Minimal Symfony-side install (for evaluation only):

composer require raindrop/sonata-theme-bundle
# register in config/bundles.php
# wire theme in config/packages/sonata_admin.yaml (templates/assets)
bin/console assets:install --symlink
bin/console cache:clear

First use case: load a Sonata dashboard and confirm the Raindrop skin is applied (colors, nav, login page). If you are in Laravel, the first equivalent use case is exporting the SCSS/CSS into resources/css and reproducing the layout in Blade (or in Filament/Inertia) — you are porting the design, not the bundle.

Implementation Patterns

Symfony / Sonata integration (the intended path):

• Theme wiring via config, not code. Most Sonata themes are activated by pointing sonata_admin template keys at the bundle's Twig files, e.g. sonata_admin.templates.layout, dashboard, list, show, edit. Check the bundle's README for the exact map; if absent, diff its Resources/views/ against vendor/sonata-project/admin-bundle/src/Resources/views/.
• Asset override pattern. Publish the bundle assets to public/bundles/raindropsonatathemebundle/ with assets:install, then either let Symfony serve them or pull them through Webpack Encore for versioning. Do not edit files under vendor/ or public/bundles/ directly — they are regenerated.
• Override blocks, not whole pages. Extend the bundle's Twig and override {% block %}s in your app's templates so upgrades to the bundle don't collide with your customizations.
• Bundle inheritance for tweaks. If you need small changes but want to keep the bundle's services, create a thin wrapper bundle or use Twig @RaindropSonataTheme/... namespacing to extend individual templates.

Laravel-side patterns (realistic day-to-day):

• Extract design tokens. Copy the SCSS variables (colors, spacing, typography) into resources/css/theme/ and configure Tailwind theme.extend from them. This is where the package actually earns its 0.75 "opportunity" score.
• Reproduce layouts in Blade. Recreate the dashboard/list/show/edit layouts as Blade components (<x-admin.layout>, <x-admin.sidebar>), mirroring the Twig block structure. Keep them as partials so they compose like Twig blocks.
• Admin-panel mapping. If you're on Filament, Nova, or Orchid, translate the theme into that panel's theme hook (e.g., Filament's ->colors([...]) and a custom panel.css) rather than copying HTML.
• Vite pipeline. Move published CSS into resources/css/app.css imports and build with Vite; do not reference public/bundles/... URLs from a Laravel app.

Suggested workflow: clone the repo into a throwaway Symfony project → apply the theme → screenshot every admin page → port tokens and layout to your Laravel admin stack. Keep the Symfony install strictly for visual reference.

Gotchas and Tips

• Framework mismatch is the primary gotcha. Installing this into a Laravel app pulls in Symfony/Sonata dependencies you will never use and may conflict with Laravel's Symfony components. Do not composer require it in laravel/laravel. Vendor it as a reference or extract assets only.
• Sonata version pinning. Sonata admin makes breaking changes across majors (template paths, asset handling, sonata_admin config keys). Verify the constraint in composer.json matches the Sonata version whose templates you are reading; otherwise the "theme" is for a different admin UI.
• Low-maintenance signal. 14 stars, 0 dependents, score 0.53 — expect thin or absent docs. Budget time to read Resources/views and the bundle class yourself; do not plan on upstream support or a changelog.
• Asset publishing quirks. assets:install --symlink plus cache:clear is usually required after any template/asset change. A stale Twig cache will hide your overrides.
• Debugging template resolution. In Symfony, bin/console debug:twig shows which template file actually resolves for a given name — use it to confirm the Raindrop override is winning over Sonata's default. var/log/dev.log and dump() in Twig catch most layout errors.
• Config location. Any configuration is Symfony YAML/PHP under config/packages/sonata_admin.yaml, not Laravel's config/*.php. Don't look for a Laravel-style published config file.
• Extension points worth knowing: Twig block overrides, the sonata_admin.templates config map, and getParent() bundle inheritance. Everything else is CSS.
• If you must reuse code verbatim, keep the Twig files out of resources/views (Blade will not parse them) and instead translate block-by-block. Treat Twig as the spec, Blade as the implementation.
• Licensing/attribution: small unmaintained packages sometimes lack a clear license; check LICENSE before copying large template/CSS chunks into a commercial codebase.