Helper Plugin Laravel Package

Getting Started

The anomaly/helper-plugin is a PyroCMS (Streams Platform) addon rather than a general-purpose Laravel package, so the first step is confirming your app actually runs on that stack. Pull it in with Composer and let package auto-discovery register the service provider:

composer require anomaly/helper-plugin

If you are on an older PyroCMS install without auto-discovery, add the provider to config/app.php:

Anomaly\HelperPlugin\HelperPluginServiceProvider::class,

Where to look first: open the package's src/ directory and scan for its service provider and any helper/loader classes. That is the ground truth for what functions, Blade directives, or macros are exposed — with zero stars and zero dependents there is effectively no external documentation, so the source is the docs.

First use case: drop the provided helpers into a Blade view or an addon's controller to replace repetitive formatting logic — e.g. resolving stream values, formatting output, or wiring a helper into a CP view. A typical first integration looks like:

// In an addon controller or a Streams field's presenter
$value = helper_function($entry->field_slug);

and in Blade:

{{ helper_function($entry->title) }}

Verify the helper is available by dumping it once (dd(function_exists('helper_function'))) before wiring it into templates.

Implementation Patterns

Treat it as an addon, not a package. Register it inside the PyroCMS addon system (install via the CP addons module or php artisan addon:install anomaly/helper_plugin) so its views, translations, and service bindings load in the expected lifecycle. This is how the helpers become globally reachable across addons and the control panel.

Centralize calls in your own helper layer. Because the package gives you global procedural helpers, wrap them in a thin class (e.g. an App\Support\Helpers or an addon-level Helper wrapper) and inject that. This keeps you insulated if the addon is abandoned or renamed, and makes the helpers testable.

class ThemeHelper
{
    public function label($entry): string
    {
        return helper_function($entry->name) ?: '—';
    }
}

Use in Blade via a directive or view composer rather than raw function calls. If the plugin exposes a Blade directive, prefer that; otherwise expose your wrapper through a view composer so templates stay clean:

{{ $helpers->label($entry) }}

Compose with Streams Platform models. The realistic day-to-day pattern is passing EntryInterface / stream field values into these helpers when rendering listing tables, CP forms, or front-end modules. Keep the helper call at the rendering boundary and leave domain logic in repositories.

Reuse across addons by depending on it. Add anomaly/helper-plugin to the require block of any addon that needs the shared utilities so installs are reproducible, and reference the helper names consistently.

Pin the version. With no releases activity to speak of, lock the exact tag/commit in composer.json so a stray update does not break templates mid-sprint.

Gotchas and Tips

Abandonment risk is real. Zero stars and zero dependents means no community safety net and likely no maintenance. Before adopting, diff the source against what you need and consider copying the handful of useful functions into your own helper file — often less risk than depending on it.

Compatibility is version-sensitive. PyroCMS/Streams Platform and Laravel versions moved fast; the addon may target an older framework. If helpers throw "class not found" or binding errors, check the service provider's require and provide sections against your installed versions first.

Global function collisions. Procedural helpers are loaded into the global namespace. If you (or another addon) define a function of the same name you will get a fatal redeclare error. Grep your codebase and other addons for the helper names before enabling it.

Auto-discovery can silently skip it. If the provider is not listed in the package's composer.json extra.laravel.providers, the helpers will not be registered and function_exists() returns false with no error. Confirm registration explicitly in a tinker session.

Config and publish quirks. Some addons ship a config file that must be published (php artisan vendor:publish) or they fall back to defaults that may not match your environment. Check for a config/ directory in the package and publish it if present.

Debugging tip. When a template dies on a helper call, isolate it in php artisan tinker first — if the function exists and runs there, the problem is a missing addon registration or a wrong Streams field type, not the helper itself.

Extension point. Most value here is as a reference implementation: read how the addon's service provider wires helpers, then fork the pattern into your own addon so you control the helpers, their namespacing, and their lifecycle instead of inheriting an unmaintained dependency.