Submenu Plugin Laravel Package

Getting Started

What you're actually getting. visiosoft/submenu-plugin is a Streams Platform addon (the PyroCMS successor framework that OpenClassify is built on), not a generic Laravel package. It exists to support OpenClassify's navigation model — a secondary/sub navigation layer that hangs off a primary menu or page. Treat it as an internal module that leaked onto Packagist rather than a standalone library: zero stars, zero dependents, no README worth the name, and a single release.

Install and register the addon. In a Streams/OpenClassify application the flow is Composer plus the addon installer, not just composer require:

composer require visiosoft/submenu-plugin
php artisan addon:install visiosoft.submenu-plugin
php artisan addon:publish visiosoft.submenu-plugin   # assets/views if present

If you're on a plain Laravel app with no Streams Platform, stop here — the package will autoload but its service provider expects Streams' addon collection, CP routing, and asset pipeline to exist.

Where to look first, in order.

1. src/SubmenuPluginServiceProvider.php — what it registers (routes, view namespaces, migrations, bindings). This tells you more than the description ever will.
2. src/SubmenuPlugin.php — the Streams addon descriptor: slug, name, version, dependencies.
3. migrations/ — the schema is the real spec. Whatever tables it creates (likely a submenu / submenu_items pair linked to menus) is the data model you'll actually program against.
4. resources/views/ — the render contract. If there's a submenu view or a make/render partial, that's your integration surface.
5. config/ — anything tunable. Usually thin in Visiosoft addons.

First use case. The realistic day-one task is: display a nested nav under an existing menu in an OpenClassify-themed page. Expect to (a) create a submenu record with the admin UI or a seeder, (b) attach items pointing at the parent menu, and (c) render it in a Blade view through the addon's registered view namespace or a Streams menu()-style helper. Verify the exact helper name by grepping the addon source for view( and function before assuming — this is the single biggest time sink with undocumented Streams plugins.

Implementation Patterns

Seed the structure rather than clicking through the CP. Streams addons rarely ship seeders, but the underlying tables are plain Eloquent-accessible via the Streams repository layer. For reproducible environments, write your own seeder that creates the parent menu, then the submenu, then items in order. This is also your best documentation: a seeder that runs proves the schema and foreign keys.

Render through the addon's view namespace. Streams registers addon views as visiosoft.submenu-plugin::... (or submenu-plugin::... depending on conventions used at build time). Grep loadViewsFrom in the service provider to get the exact namespace, then:

@include('visiosoft.submenu-plugin::partials/nav', ['submenu' => $submenu])

Prefer including the addon's own partial over re-implementing markup — you inherit its accessibility/aria handling and its link-generation logic, which is where these plugins actually add value.

Wrap in a view composer, not controller logic. Submenus are chrome, present on many pages. Resolve the active submenu in a View::composer bound to your layout, keyed off the current route/menu slug, and pass it down. This keeps controllers clean and gives you one place to add caching later.

Integrate with the parent menu, don't fork it. The plugin's value is that items reference existing menu entries. If you find yourself duplicating URLs into a second table, you've lost the point — you'll drift from the main nav every time marketing edits a link. Read the migration's foreign key to confirm the relationship direction (submenu → menu vs. item → item) and build your admin tooling around it.

Extend by overriding views, not editing vendor code. Publish the views (addon:publish), then edit the copies. If the addon supports a config-driven view override, prefer that. Never patch vendor/ directly — with a 2023 one-shot release, you'll never get upstream fixes, so your overrides are permanent; make them visible and versioned.

Treat it as a dependency you own. With one release and no maintainers actively shipping, the pragmatic pattern is: pin the exact version in composer.json, and keep a short internal note of what you changed and why. If the submenu logic is small, consider vendoring the relevant class into your own addon and dropping the dependency — for a plugin this size that's often cheaper than long-term ownership.

Gotchas and Tips

Version drift is the main risk. The last release is November 2023. Streams Platform has moved on; the addon's composer.json constraints may not resolve against a current OpenClassify. Check its require block before anything else — if it pins laravel/framework to 9.x or streams/core to an old minor, budget for a fork or a compatibility shim.

Streams caching will make you think it's broken. Menu and addon metadata are cached aggressively. After installing, changing config, or editing a view: php artisan cache:clear and, if you have it, php artisan addon:rebuild / view:clear. Ninety percent of "the submenu won't show up" reports against these addons are stale cache.

Migrations are namespaced and order-sensitive. Addon migrations run under the addon's own namespace and reference Streams core menu tables. If you install it before the menus module is migrated (fresh install ordering), you'll get FK failures. Install via addon:install on a working site rather than trying to hand-run migrations on a blank DB.

No tests means every upgrade is a blind upgrade. There is no test suite and effectively no changelog. Before bumping, diff the published migrations and the service provider between versions. If nothing's changed upstream (likely, given the release cadence), pinning to a commit SHA is safer than tracking a tag.

Extension point inventory (what you can realistically hook). The view namespace, the config array (if present), the published assets, and Eloquent models over its tables. That's it. There's no documented event/observer layer — don't assume one exists just because the parent platform has events. If you need behavior it doesn't expose, override the view or replace the class via a container binding in your own service provider.

Watch the package name vs. addon slug. Visiosoft packages frequently have a Composer name (visiosoft/submenu-plugin) that differs from the Streams addon slug used in artisan commands and view namespaces (visiosoft.submenu-plugin, or sometimes just submenu-plugin). Getting this wrong produces confusing "addon not found" errors. Confirm the slug from src/SubmenuPlugin.php before running any artisan command.

Have an exit plan. Given zero dependents and no stars, there is no community to fall back on and no bug reports to learn from. If the submenu UI is more than a few hundred lines of markup and link resolution, budget a half-day to reimplement it in your own addon when (not if) it breaks against a future Streams upgrade.