Anomaly Theme Laravel Package

Getting Started

• Install: composer require anomaly/anomaly-theme — but in practice you almost never install this directly. It is pulled in transitively by anomaly/streams-platform and Streams-based products (PyroCMS 3.x). Check composer show anomaly/anomaly-theme on an existing install before adding anything.
• Where to look first: resources/views/ (the Blade templates the admin renders), the theme service provider in src/ (it extends the Streams Theme base class and declares the addon slug, typically anomaly.theme.anomaly), and public/ or resources/assets/ for the admin CSS/JS. Read the provider before touching anything — it tells you the slug, the asset registrations, and any view namespaces.
• Registration: Streams themes are discovered by the platform's addon manifest. You generally do not add anything to config/app.php. Confirm the theme is registered via the Streams admin (Appearance / Addons) or php artisan theme:list if the CLI is available.
• First use case: rebranding the admin. Copy the specific view you want to change into your project's own theme (or a resources/views/vendor/... path) rather than editing vendor files, then clear view and asset caches. That is 90% of what a day-to-day developer does with this package.

Implementation Patterns

• Child theme over vendor edits. Create a small project theme (acme/admin-theme) that requires this package and overrides a handful of views, then register it as the admin theme. This survives composer update and keeps upstream diffs reviewable.
• Override the smallest unit possible. Streams resolves theme views through its namespace fallback chain; overriding a single partial or form section is far less brittle than copying an entire layout. Full-layout copies break silently on platform upgrades.
• Customize through Streams, not the theme. Field types, form sections, and assignments are rendered by the theme but configured outside it. Prefer extending those config surfaces over template surgery — it's the supported extension point and isn't tied to theme internals.
• Assets go through the asset service. Use asset()->add('admin.css', ...) inside a service provider (Streams' Anomaly\Streams\Platform\Asset\Asset) rather than raw mix() calls. This gives you ordering, versioning, and inclusion in the combined bundle the admin actually loads.
• Branding workflow: fork the repo once as an internal package, pin it in repositories, override a few views and an asset stub, and stop there. Anything deeper and you're maintaining a theme, not integrating one.
• Local dev loop: after any view or asset change, expect to clear Streams' view cache and asset cache (admin → System → Cache, or the corresponding Artisan commands). Iterating without clearing will make you think your override isn't being picked up.

Gotchas and Tips

• Not a standalone Laravel package. Nothing in this repo is useful without anomaly/streams-platform. Do not require it into a plain Laravel app expecting an admin panel.
• Version lock-in. The theme's composer.json constrains the platform version; bumping one without the other breaks admin views. Pin the theme version alongside the platform version.
• Near-zero community signal. 1 star, 0 dependents. There is essentially no external documentation, no Stack Overflow trail, and issues may go unanswered. Treat the source as the documentation and budget time to read it.
• Never edit vendor/anomaly/anomaly-theme. composer update wipes it. Override via a child theme or published views, always.
• Two different "namespaces." The Composer package name and the Streams addon slug (anomaly.theme.anomaly) are distinct. Config keys, view namespaces, and asset handles use the slug. Mixing them up is the most common configuration error.
• Stale caches are the default failure mode. Missing view overrides → view:clear plus the Streams view cache. Stale CSS/JS → the asset bundle cache. Check that before debugging templates.
• Debugging: enable APP_DEBUG, watch storage/logs/laravel.log for asset/view resolution warnings, and turn on view file hints in the admin to see which template actually rendered.
• Extension points to prefer: field types, form sections, and view overrides. Avoid subclassing theme internals — they are not documented as a stable API and move between platform releases.
• MIT license means you can fork, but the platform it depends on has its own release cadence, so a hard fork means you own the maintenance indefinitely.
• Practical verdict: evaluate this as an internal dependency of Streams/PyroCMS, not as an independent package. You don't "integrate" it — you customize on top of it and keep your diffs small.