Style Selector Module Laravel Package

Getting Started

This is an OpenClassify/PyroCMS-style addon module that adds a "style selector" UI for switching site style presets — it is not a standalone Laravel package. You cannot meaningfully install it into a plain Laravel app; it expects the Streams Platform (addon registry, addon:install, modules folder layout) to be present.

Minimal steps inside an OpenClassify project:

1. Add the repository to composer.json (it is unlikely to be on Packagist under a stable tag given the release history):

   composer config repositories.style-selector vcs https://github.com/openclassify/style_selector-module
   composer require openclassify/style_selector-module:dev-main
   

2. Install the addon through the platform so it registers itself:

   php artisan addon:install visiosoft.module.style_selector
   

   (Alternatively, enable it from the admin Addons screen — the module's {Name}Module.php class declares its slug/namespace, so the installer needs that file present.)
3. Confirm the service provider is discovered and run php artisan optimize:clear if the admin menu entry does not appear.

Where to look first: open src/StyleSelectorModuleServiceProvider.php and src/StyleSelectorModule.php — that is where the routes, bindings and menu hooks live. Then look in src/Resources/ for config/, views/ and lang/. The actual list of style presets is almost certainly a config array or a section in the module's Resources/config/; that file is the single most useful thing to read before touching anything.

First use case: boot an OpenClassify instance, log into the admin, navigate to the module's section (usually under Settings or Addons), and toggle the active style. You are essentially validating that the module's routes load and that its view partials render inside the active theme — most integration problems show up at this step.

Treat this as an admin-side theme switcher, not a front-end component library. If your requirement isn't "let an operator flip a predefined style preset in an OpenClassify install," the module is the wrong tool and a small settings panel of your own will be easier.

Implementation Patterns

Wiring a new style preset. The module's selector renders whatever options are declared in its config/lang files. To add a preset, edit the config array (or the lang/{locale}/addon.php labels) and point each option at a theme/css asset that already exists in your active theme. Because the module was last released in 2022, avoid relying on any documented schema — read the view that renders the radio/select to see exactly which keys it expects:

// src/Resources/config/settings.php (illustrative — verify against the source)
'styles' => [
    'default'   => ['label' => 'Default',   'css' => 'theme::css/styles/default.css'],
    'compact'   => ['label' => 'Compact',   'css' => 'theme::css/styles/compact.css'],
],

Persisting the choice. OpenClassify/PyroCMS modules of this age typically store the selection via the Settings/Preferences API (Streams Settings repository or setting() helper), keyed by a namespaced slug like visiosoft.module.style_selector::style. Use that key in your own code rather than inventing a new one:

$style = setting('visiosoft.module.style_selector::style', 'default');

If the module instead stores it on the user or site record, mirror that — do not double-store. Check the controller's post/save action to confirm the storage mechanism before writing dependent code.

Integrating in the theme. The usual pattern is a Blade include in the theme layout that pulls the active preset's asset:

@include('visiosoft.module.style_selector::partials.style', ['style' => $style])

Or, in the theme's service provider, push the stylesheet conditionally. Because the module ships its own views under Resources/views/, publish/override rather than editing vendor files if you need to customise markup.

Admin-facing workflow. If the module exposes a settings form, extend it by adding fields to the module's settings definition (Streams form fields) rather than building a parallel page. The admin form is the natural extension point; custom routes on top of a 2022-era PyroCMS module tend to break across OpenClassify upgrades.

Route naming. Routes are typically registered as visiosoft.module.style_selector::admin.styles.index etc. Use the full route name in links so the selector keeps working regardless of which admin namespace you're in.

Gotchas and Tips

• Last release is April 2022 and there are zero dependents. Treat it as unmaintained. Pin the commit hash in composer.json and vendor-lock it — a dev-main constraint against a low-activity repo is asking for a broken build on a fresh composer update.
• It is not a standalone package. Every error you'll see (missing service provider, "Addon [visiosoft.module.style_selector] not found", undefined Route method) traces back to the module being loaded outside a Streams-enabled app. Verify the platform version in composer.json before debugging the module itself.
• Discovery is cached. PyroCMS/Streams caches addon manifests aggressively. After installing, adding a route, or changing config, run:

  php artisan addon:reinstall visiosoft.module.style_selector
  php artisan cache:clear
  php artisan view:clear
  

  The most common "my change did nothing" is a stale addon manifest cache, not a code bug.
• No documentation exists for this repo beyond its code. Do not infer behaviour from the module name (e.g. assuming a StyleSelector facade or model exists). Grep the src/ tree for setting(, ->route, and class.*Controller to build your own mental model — it will take ten minutes and save hours.
• Migrations/settings table naming is the sharp edge. If you migrate to a newer OpenClassify and the module's settings namespace changed, stored selections silently fall back to the default. Add a defensive default (setting($key) ?? config_default) anywhere you read the value.
• Asset publishing is manual. Check for an assets/ or public/ folder and a publishes() call in the service provider. If it isn't there, you'll need to copy the CSS/JS to public/vendor/... yourself and update any hard-coded paths in the module's views.
• Escape hatch. Because the module is small, the realistic long-term tip is: use it as a reference implementation, not a dependency. Fork it into your addons/ directory, strip it to the settings key + a Blade partial, and own it — that eliminates the upgrade risk entirely while preserving the operator workflow.

Overall: a tiny, unmaintained, single-purpose admin addon that is fine as a starting point inside an OpenClassify project and a liability as a versioned dependency. Read the source (it is small), pin the commit, and be prepared to fork.