Weave Code
Laravel Themes Manager Laravel Package
hexadog/laravel-themes-manager
Laravel Themes Manager lets you add multiple themes to a Laravel app, each with its own views, assets, translations, config and routes. Switch themes at runtime, scaffold new themes with Artisan commands, and keep theme files isolated and publishable.
Bring multi themes support to your Laravel application with a full-featured Themes Manager
Frequently asked questions about Laravel Themes Manager
- How do I install hexadog/laravel-themes-manager in a Laravel app?
- Install the package with Composer and rely on Laravel package discovery. You typically publish the package configuration and create theme directories using the provided Artisan commands. The main effort is moving existing views, translations, config, and assets into theme namespaces rather than the installation itself.
- Does laravel-themes-manager support Laravel 12 and Laravel 13?
- Version 1.15.0 adds Laravel 12.x and 13.x compatibility and refreshes the orchestra/testbench dependency. However, Laravel 13 is not yet a stable production target, so treat that compatibility claim cautiously. Confirm the package CI matrix and test against a stable Laravel 13 release before relying on it in production.
- Can I switch themes at runtime for multi-tenant Laravel applications?
- The package is designed for runtime theme switching and layers theme resolution over Blade views, translations, configuration, and assets. For multi-tenant use, verify that theme selection is resolved correctly per request and that tenant context cannot leak between requests. Pay special attention to long-running workers and Octane, where theme state may need explicit resetting.
- How does it work with Vite, Inertia, Livewire, and Blade component namespaces?
- The package primarily targets Laravel-side theme resolution for Blade views, translations, config, and assets, not JavaScript bundling. Vite, Inertia, and Livewire integration is not automatic, so test asset URLs, view namespaces, and component resolution in a branch. Blade component namespaces should be verified carefully because theme view precedence can collide with package-provided views.
- What happens if a theme directory or view is missing?
- Fallback behavior for missing theme directories or views should be verified in your own application before production. Create a test theme with only some views present and confirm whether Laravel falls back to default views or throws an error. This is especially important when themes are incomplete during incremental migration.
- What is the recommended production asset strategy for theme assets: publish, symlink, or CDN?
- Asset publishing or symlinking can fail in containerized environments with read-only filesystems or ephemeral storage. Prefer publishing theme assets during the build step or serving them from a CDN where possible. Avoid relying on runtime symlink creation unless your deployment platform explicitly supports it.
- Does theme state reset correctly under Laravel Octane and queue workers?
- Theme context can leak across requests or jobs in long-running processes such as Octane and queue workers. You should explicitly reset or re-resolve the active theme at the start of each request or job. Test this behavior under your actual worker configuration before deploying to production.
- What are the exact PHP and Laravel version constraints in composer.json?
- The exact PHP and illuminate/* constraints are defined in the package composer.json and should be checked against your application. Version 1.15.0 widens Laravel compatibility to include 12.x and 13.x and updates orchestra/testbench. Also verify compatibility with other packages that pin Laravel framework components.
- Is v1.15.0 a breaking change and safe to upgrade?
- Based on the release notes, v1.15.0 appears to be an additive compatibility and maintenance release rather than an architectural change. Run your application test suite after upgrading, especially if you rely on custom theme resolution or asset publishing. For a framework upgrade, upgrade the package first and perform the Laravel upgrade in a separate branch.
- When should I avoid laravel-themes-manager or consider alternatives?
- It fits Blade-based white-label, multi-brand, and tenant-facing applications that need view and asset isolation. It is less relevant for API-only services or SPA-heavy applications where themes are compiled into a JavaScript bundle. If you only need a few view overrides, Laravel view namespaces or a small custom resolver may be simpler than adopting a full themes manager.
Weaver
How can I help you explore Laravel packages today?