Weave Code
Themes Laravel Package
devdojo/themes
DevDojo Themes is a lightweight Laravel package for adding switchable themes to your application. Organize theme views, assets, and settings, then activate a theme to change your app’s look without modifying core code.
A package to add themes functionality in your Laravel application (Currently for Voyager)
Frequently asked questions about Themes
- What is devdojo/themes and what problem does it solve in a Laravel app?
- devdojo/themes is a small Laravel package that adds theme management: it lets you keep Blade views, assets, and configuration grouped into separate themes instead of scattering presentation files across your core application. A thin service provider registers config and publishes theme assets/views, and a resolution layer swaps the active theme at runtime. The durable value is the theme resolution abstraction (active theme to view path, asset path, and fallback chain), which is roughly a couple hundred lines of code most teams would otherwise write themselves. It is presentation-layer only and does not touch application logic.
- How do I install devdojo/themes in a Laravel application?
- Install it with Composer, then publish the package config and assets using the vendor:publish command so the theme configuration and public theme directories are created. You then create your theme folders (typically resources/views/themes/{slug} for Blade templates and public/themes/{slug} for CSS, JS, and images) and seed the theme metadata the package expects. Finally you register whatever middleware or helper sets the active theme. Expect about a day of integration work for a developer familiar with Laravel packaging, plus design and content work to actually populate the themes.
- Do I need Voyager to use devdojo/themes, or can it run standalone?
- The package's stated scope is currently for Voyager, and the theme picker is surfaced through Voyager's admin panel, so the intended use case is a Laravel monolith already running Voyager. Before committing, check composer.json to confirm whether tcg/voyager is a hard require or only a suggest, because a hard require pulls Voyager's dependency tree and its Laravel support ceiling into your application. If Voyager is a hard require, that ceiling effectively becomes your upgrade ceiling. If it is only suggested, you can likely wire the theme resolution layer into your own admin UI and use it standalone, but verify this rather than assuming.
- Which Laravel and PHP versions does devdojo/themes support?
- The package targets server-rendered Laravel applications using Blade, and the README does not publish a clear forward-looking support matrix. You should read composer.json directly to confirm the required PHP version and the illuminate/* version range before adopting it. There is no well-documented policy for tracking new Laravel majors, and Composer constraints that block a future major release are the most expensive failure mode here. Treat the installed Laravel/PHP combination as a verified constraint, not an assumption.
- How does runtime theme switching work in devdojo/themes?
- The package resolves an active theme and points Blade's view resolution at that theme's directory, so switching the active theme changes which templates render without modifying core application code. The exact mechanism matters for your architecture: whether it uses View::addLocation, a custom FileViewFinder, or a middleware-driven path swap determines cache behavior and whether per-request theming is viable. Runtime switching is convenient for operator-facing settings, but it is not a substitute for a build or deploy pipeline if you are shipping an Inertia, SPA, or API-first front end. Confirm the implementation before designing multi-tenant theming around it.
- Is there a fallback when the active theme is missing a Blade view?
- A fallback chain is central to whether theming is safe in practice: if a theme omits a template, you want resolution to fall through to a base theme or the default application views rather than fail hard with a missing view error. The package is described as providing theme-aware view resolution with a fallback chain, but the exact behavior is not spelled out in the overview. Test it explicitly by deleting a template from an active theme and confirming what renders. If it fails hard, plan to enforce a required-template contract across all themes.
- How are theme assets such as CSS, JS, and images handled, and does it work with Vite?
- Assets are organized per theme, typically under public/themes/{slug}, and referenced through the package's asset helpers so URLs follow the active theme. The package predates modern Vite-based pipelines and most likely assumes simpler asset helpers or Laravel Mix, so theme asset references may need to be rewritten at the theme contract level to compose with a Vite build. Verify this before scoping, because it is the point where a runtime theme layer most often conflicts with a compiled asset pipeline. A safe pattern is to build each theme's assets in your pipeline and let the theme only supply the manifest and directory layout.
- Does devdojo/themes work with view:cache and other production optimizations?
- Custom view finders can interact badly with view:cache and other compiled-view optimizations, so this is a known risk area rather than a guaranteed behavior. Run php artisan view:cache and route:cache against a themed build in a staging environment and confirm the correct theme still resolves. If caching bakes in a single theme path, you may need to disable view caching or re-clear caches whenever the active theme changes. Also budget for testing that theme switching behaves correctly under load and across queued or scheduled work.
- Is devdojo/themes actively maintained and safe for production?
- Signals are thin: roughly 21 stars, zero dependents, and single-vendor maintenance, with a last release around August 2024 but low ongoing activity. Zero dependents is the loudest indicator, because it means there is no ecosystem exercising this code in production and you will be the first to hit edge cases. The pragmatic posture is to treat it as a vendored internal component rather than a normal third-party dependency: fork it, name an internal owner, and pin the version. Confirm the license (assumed MIT) and whether internal forking and redistribution are permitted before you build on it.
- Should I use devdojo/themes or build my own theme resolution layer?
- If you are already on Laravel, Blade, and Voyager 1.x and want an operator-facing theme picker without building one, the package is a reasonable fit and saves you writing the resolution abstraction. If you are not on Voyager, the better trade is usually to implement the active-theme-to-view-path-and-asset-path resolution yourself in a small service provider, avoiding Voyager's dependency tree and Laravel version ceiling. For Inertia, SPA, or API-first front ends, theme switching belongs in a build and deploy pipeline rather than runtime settings, so this package is not the right tool. Either way, define a theme contract (manifest or naming convention) and a fallback chain up front.
Weaver
How can I help you explore Laravel packages today?