Gg Style Provider Extension Laravel Package

Getting Started

This is a PyroCMS/Streams Platform addon (visiosoft/*-extension) rather than a plain Laravel package. It does not expose a facade you call from controllers — it registers a style provider into the platform's asset pipeline, so the "usage" is mostly installation plus selective overriding.

Minimal path:

composer require visiosoft/gg_style_provider-extension
php artisan addon:install visiosoft.extension.gg_style_provider
php artisan addon:publish visiosoft.extension.gg_style_provider
php artisan assets:clear

If addon:install rejects the namespace, check the extension class name in src/ — the artisan slug is derived from vendor.extension.slug, which rarely matches the Composer package name exactly (underscores vs. dots).

Where to look first, in this order:

1. composer.json — confirm "type": "pyro-addon" (or streams-addon), the require block for the Streams Platform version it was built against, and any extra.publish paths.
2. src/*Extension.php (or ServiceProvider.php) — the registration method shows what gets registered: a StyleProvider binding, an asset()->add() call, a view namespace, or a control-panel section.
3. resources/ — the SCSS/CSS is the actual product. If there is an scss/ folder, the compiled CSS is generated at publish time; if there is only css/, it is copied verbatim.
4. config/ — any toggle like enabled, auto_register, or priority.

First use case: install it, load the control panel or frontend, and confirm the stylesheet appears in the rendered <link> tags. Then diff the markup against the pre-install output. If nothing changes visually, the provider is registering but its selector scope is empty — check for a CSS variable or body class that must exist first.

Implementation Patterns

Zero-code registration. The normal path is: install, publish, clear caches, done. The service provider hooks into the platform's boot sequence and appends its stylesheet. Do not add a use statement anywhere; there is nothing to import.

Scoped opt-in. If the provider reads a config flag, publish the config and gate it per environment:

// config/gg_style_provider.php (after publish)
'enabled' => env('GG_STYLE_PROVIDER', true),

This is the cleanest way to keep the stylesheet out of local development while matching production.

Layered overrides. Rather than editing the vendor CSS, register your own provider after this one and let cascade order do the work. In the Streams Platform you control order via assets config or by calling asset()->add('theme::custom.css', ...) from a later-registered addon. Publish the vendor SCSS, copy it into your own theme's resources/scss/, and override variables rather than rules.

Composing with a theme. If your theme already ships a style provider, this addon most likely sits underneath it. Verify load order in the rendered HTML — the later <link> wins for equal specificity. If the order is wrong, adjusting config/streams/platform.php asset ordering is more reliable than reordering packages in composer.json.

Using the package as a template. Given its scope, the highest-value pattern is copying its structure for your own style addon: one extension class, one provider, one resources/css folder, one composer.json with type: pyro-addon. That skeleton is what gets rediscovered in this codebase.

Gotchas and Tips

• Publish is not automatic. Composer installs the addon but the public CSS 404s until addon:publish runs. Deploy scripts that only run composer install && artisan migrate will silently ship an unstyled site.
• Cache layering. There are three caches between you and the new CSS: the platform asset cache (php artisan assets:clear), the addon manifest (php artisan addon:reinstall ... or addon:refresh), and the browser. Clear them in that order when diagnosing.
• Namespace mismatch. The Composer package is visiosoft/gg_style_provider-extension; artisan wants visiosoft.extension.gg_style_provider. Reading the extension class name is faster than guessing.
• Version drift. Last release July 2023 means it targets the Streams Platform generation of that era. On a Laravel 10/11 app with a newer Streams Platform or a Laravel-native fork of it, the service provider signature may no longer match. Check composer.json's require block before adding it to a fresh project; if it constrains the platform, install it in a throwaway branch first.
• Zero dependents / zero stars is a real signal. Treat this as vendored internal code: pin the exact version, and if it breaks, fork it into addons/ rather than waiting for an upstream fix. The src/ folder is likely under 200 lines and trivially reproducible.
• Debugging registration. Confirm the provider actually booted with php artisan tinker and inspecting the asset collection, or by grepping the compiled page source for the expected path. A provider that fails silently is common when the config flag defaults to false.
• Extension points. The practical one is the style provider contract itself — implement it in your own addon and register it alongside this one, so you inherit the same pipeline (ordering, minification, cache busting) without touching vendor files.
• CSS-variable coupling. Style providers in this ecosystem frequently assume a control-panel body class or theme variable namespace. If colors do not apply, that namespace is missing — not a bug in your install.