Pyrocms Theme Laravel Package

Getting Started

Before writing a single line, confirm that the package is even relevant to your install: anomaly/pyrocms-theme is the deprecated admin theme for PyroCMS, superseded by anomaly/accelerant-theme. In practice your first move is to open composer.json and check which admin theme your project actually requires — if you see anomaly/accelerant-theme, stop here; this package is only useful for maintaining a legacy install that hasn't migrated yet.

If you are on a legacy PyroCMS 2.x/early 3.x control panel, the things to look at first are:

1. The theme manifest — theme.json (or resources/theme.json depending on version) declares the theme name, slug, version, and assets. This is the entry point the PyroCMS theme registrar reads.
2. The service provider — a *ThemeServiceProvider that registers the theme via the Anomaly\Theme\Theme contract or the theme repository, binding views under the admin namespace.
3. View layout hierarchy — resources/views/layouts/, partials/, and dashboard/ typically override the control panel chrome (header, nav, sidebar, breadcrumbs).
4. Published assets — resources/assets/ (CSS/JS) mirrored into public/ via the theme publish command.

First use case: you're maintaining a PyroCMS control panel and need to brand or tweak the admin UI — changing the logo, nav layout, dashboard widgets, or CSS. That is the only realistic reason to touch this repo today.

Implementation Patterns

Theme registration. The theme is registered through the theme repository, usually inside a service provider's boot():

$this->themes->register('anomaly/pyrocms-theme');

or via config/themes.php depending on the PyroCMS version. Verify which mechanism your install uses before copying patterns from the repo — the API shifted across PyroCMS majors.

Layout overrides. The day-to-day pattern is extending the base control panel layout and overriding named sections/blocks. Admin views are resolved from the theme's namespace, so an override of layouts/default.twig or layouts/default.blade.php (depending on your version) takes precedence over the core admin view. Keep overrides as thin as possible — override the partial, not the whole layout.

Partial composition. Header, sidebar, breadcrumbs, and footer are separate partials. Customizing the nav means editing the sidebar partial plus whatever view composer feeds it menu items, not the layout itself. This keeps upgrade paths open.

Asset publishing. Theme assets should be published, not referenced from vendor/. Typical workflow:

php artisan theme:publish anomaly/pyrocms-theme

(or the equivalent PyroCMS command for your version), then reference paths from public/ in the layout. Never hand-edit files in public/ — they get overwritten on republish.

Dashboard widgets. The admin theme exposes a dashboard region where addon-provided widgets render. Integration pattern: register a widget with the dashboard repository and give it a view under the theme namespace; the theme handles layout, the widget only owns its inner view.

Branding pattern. Logo, favicon, and accent colors are typically driven by theme config merged into the manifest. Prefer these config values over hardcoding in CSS so a single config change re-brands the panel.

Gotchas and Tips

• It is deprecated. Do not add it to new projects, and treat any bug you find as won't-fix. If you're starting fresh or migrating, target anomaly/accelerant-theme — it is the supported path and the API/registration surface is what current PyroCMS expects.
• Version coupling is brutal. This theme was written against a specific PyroCMS generation. Composer constraints may pin you to old laravel/framework, twig/blade, and PHP versions. Read composer.json before assuming it will install at all on a modern stack.
• View namespace collisions. Admin theme views are resolved through a namespace; if two themes register the same namespace (e.g. after installing Accelerant alongside this one), the last registration wins and you get phantom overrides. Check the registered theme list, not just the filesystem.
• Asset caching. After editing theme CSS/JS, run the publish command and clear caches (php artisan view:clear, plus any theme/asset cache the PyroCMS version provides). Stale published assets are the most common "my change did nothing" bug.
• View resolution debugging. When an override isn't taking effect, find out which file actually renders. Add a temporary trace in the layout or use Laravel's view event listener to log the resolved path. Do not guess the resolution order — the theme namespace plus the core namespace both expose similarly named views.
• Don't fork it in place. If you must customize, override views and assets from your own theme/provider that extends this one, not by editing vendor/. A composer update will erase your work.
• Menu/nav content is data, not views. If the sidebar looks wrong, the bug is usually in the menu repository or a view composer feeding it, not in the theme partial — check the composer first.
• Migration checklist. Moving to Accelerant: inventory every overridden view and published asset, re-implement them against Accelerant's structure, then remove this package. Keep a diff of your old overrides so you can verify feature parity (logo, nav, dashboard widgets, custom CSS) after the switch.
• Bus factor. One star, zero dependents, no maintenance. Budget for owning this code if you keep it, and document the PyroCMS/PHP versions it works with in your repo so the next developer isn't spelunking.