Base Theme Laravel Package

Getting Started

This is not a general-purpose Laravel package — it is a PyroCMS/Streams Platform addon of type pyrocms-theme, published by Visiosoft for the OpenClassify classifieds platform. Treat it as a theme scaffold you extend or override, not a library you call.

Minimal steps:

1. Confirm the host. You need an application running pyrocms/streams-platform (OpenClassify, PyroCMS 3.x). A vanilla Laravel app cannot meaningfully consume this package — there is no facade, no config file to publish, no service to resolve.
2. composer require visiosoft/base-theme in the host application.
3. Inspect composer.json first. Look at "type", the extra block (addon/theme metadata), and the require constraints. This tells you which Streams version and PHP/Laravel range the theme was built against, and whether auto-discovery applies or you must register the provider manually in config/app.php (Streams addons often rely on the platform's own addon registry rather than Laravel package discovery).
4. Open src/BaseThemeServiceProvider.php. Themes in Streams typically extend Anomaly\Streams\Platform\Addon\Theme\Theme and set $name, $slug, $version, $author, plus optional $styles/$scripts/$assets arrays. That class is the real API surface — read it before anything else.
5. Inspect resources/views/. Layouts, partials and the theme:: namespace root live here. Note which view names other addons expect to find.
6. Publish/compile assets (php artisan addon:publish visiosoft.base-theme or the platform's theme asset command) and clear caches (php artisan view:clear, php artisan cache:clear) before judging whether it "works".

First use case: activate the theme in the admin panel (or via the settings/theme config table) and load the front page. Then create a one-file child override of the main layout to prove the view-resolution chain is pointed at this package. If the front page renders with your override, the theme is wired correctly; if you get a "view not found" error, the namespace or slug is wrong, not the theme.

Implementation Patterns

Extend, don't fork. The intended pattern is a sibling/child theme addon that declares this one as a dependency and overrides views by name through the theme:: namespace. Copying files out of vendor/ defeats the purpose and makes composer update a hazard.

Layout inheritance. Expect a master layout (theme::layouts/default or similar) with @extends/@section blocks. Override at the smallest granularity possible — a partial, a component, a single section — rather than replacing the whole layout. Streams resolves views by namespace and then falls back to the platform default, so a partial-level override usually survives upstream changes; a full layout copy rarely does.

Blade partials as the integration seam. Anything business-specific (pricing badges, listing metadata, navigation menus) belongs in your own addon's views, @included from overridden base partials. Keep the base theme responsible for markup structure and CSS, keep your addon responsible for data.

Asset pipeline. Theme assets are registered in the theme class ($assets, $styles, $scripts) and served through Streams' asset/asset-path helpers. Don't hardcode public/vendor/... paths — use the helpers, and re-run the publish command after any asset change. If you add a build step (Vite/Mix), wire it in your child theme, not here.

Multi-site and admin scoping. In an OpenClassify install the theme is selected per site/domain. Test any override on a secondary site, not just the default, before rollout — theme resolution goes through the settings repository and behaves differently when a site has no explicit theme assigned.

Deployment workflow. Pin the version in composer.json, run composer install --no-dev then php artisan addon:publish as part of your deploy script, and include view:clear in the release tasks. Themes cache compiled Blade views aggressively; a stale cache will make you think your override isn't loading.

Local development. Symlink your child theme into the addon path, or develop it as a path repository with a composer.json repositories entry, so edits are picked up without a reinstall. Keep this out of production config.

Gotchas and Tips

Zero stars, zero dependents, last release October 2023. There is no community, no issue triage, and no evidence of ongoing maintenance. Budget for the possibility that you own this theme's future. Vendor it, read every line, and be prepared to patch it yourself.

It is an OpenClassify theme, not a Laravel package. If your composer install pulls it into a project without pyrocms/streams-platform, you'll get a provider that references classes which do not exist. Guard the install; don't assume PSR-4 alone makes it usable.

Namespace and slug mismatches are the single most common failure. The composer name (visiosoft/base-theme), the provider class, the theme $slug, and the view namespace theme:: are four different things that must line up. A "view not found" almost always means the slug the platform resolved differs from the slug in the theme class.

Auto-discovery is unreliable with Streams addons. If the theme doesn't appear, check that the platform's addon cache has been rebuilt (php artisan addon:scan / addon:refresh depending on version) and that the package is listed in the appropriate addon config. Clearing only Laravel's config:cache won't help.

Asset publishing is a separate step from install. Files land under public/ and are not re-published automatically. On immutable deployments, run the publish command during release and make it idempotent.

Stale view cache after override edits — php artisan view:clear first, debug after. Similarly, Streams caches theme lists; a new child theme may not register until you clear the platform cache.

Version pinning matters. With a single 2023-era release, a minor composer constraint is effectively no constraint. Pin to the exact version and treat any upstream bump as a change requiring a front-end regression pass.

Extension points to prefer: the theme class properties ($assets, $styles, $scripts), Blade partial overrides, and your own addon's service provider for view composers. Avoid editing markup deep inside layout files — that is where fork-and-diverge starts.

No tests ship with it. Add a smoke test in your own suite that boots the host app, asserts the theme resolves, and GETs the homepage. That single test will catch most upgrade breakage, and it is the only safety net you're going to get.