Workshop Module Laravel Package

Getting Started

This module ships as part of the AsgardCMS platform rather than as a standalone composer require. You get it by installing the CMS itself:

composer create-project asgardcms/platform my-site

Once installed, the Workshop module appears at Backend → Workshop → Modules (/backend/workshop/module). That screen is your control panel: it lists every module discovered on disk, shows its current state (installed / enabled / disabled), and provides buttons to activate or deactivate.

Your first useful workflow:

1. Drop a module into Modules/ (AsgardCMS expects the Vendor/Name directory layout with a module.json and a service provider).
2. Clear the module cache so Workshop sees it: php artisan module:list should reveal it without a ? marker.
3. Hit Activate in the UI — this triggers the module's migrations and registers its service provider.
4. Verify with php artisan module:list and check modules table for the active = 1 row.

Where to look first when it's not behaving: config/modules.php, the modules database table, and storage/framework/cache (module discovery is cached). This is the place to look whenever you activate a module and "nothing happens."

Implementation Patterns

Activating a module programmatically. Almost everything the UI does is available via Artisan, which is what you'll actually want in deploy scripts and CI:

php artisan module:enable Blog
php artisan module:disable Blog
php artisan module:migrate Blog
php artisan module:list

The Workshop UI is really a thin wrapper over these — treat the UI as the developer-ergonomic path and the Artisan commands as the automation path.

Module state as application config. Once activated, a module's service provider is registered on boot, so day-to-day you mostly interact with the effects of activation rather than Workshop itself: routes appear, menus show up, permissions register. Treat Workshop as a one-time setup step per module, not a runtime dependency.

Migrations on activation. Workshop hooks module migrations into the activation flow. In practice this means your module's Database/Migrations folder is run when the module is first activated, and you must be careful not to re-run destructive migrations on re-activation (see Gotchas).

Deploy workflow. For a fresh environment, the pattern is:

composer install
php artisan module:list        # warms discovery cache
php artisan module:migrate --all
# then a small seeder/artisan command that calls module:enable for each required module

This is more reliable than hand-clicking the Workshop UI on a production box.

Integration with AsgardCMS menus and permissions. Because Workshop only gates activation, your other logic (menu items, permissions) should live in the module's own service provider and be registered conditionally on activation state. Don't assume Workshop will publish your assets — it won't.

Gotchas and Tips

This package is effectively abandoned. Zero stars, zero dependents, and a NOASSERTION license means you have no community momentum, no license clarity, and no realistic path to upstream fixes. Treat it as "vendored code you inherit with AsgardCMS" rather than a dependency you can lean on. If you're evaluating whether to adopt AsgardCMS today, this is a red flag worth weighing.

License ambiguity. NOASSERTION means the repository declares no SPDX-recognized license. If you're shipping commercially, get legal sign-off or fork the module under a license you control.

Re-activation reruns migrations. The activation flow re-runs migrations from the module's Database/Migrations directory, and older migrations are not always guarded. Either write idempotent migrations (Schema::hasTable checks) or never rely on Workshop for schema evolution after the first activation — use explicit php artisan module:migrate in your deploy pipeline instead.

Discovery cache. Adding or removing a module directory doesn't always show up in the Workshop list. Clear it with:

php artisan cache:clear
php artisan module:list

If a module is missing from the UI, this is almost always why.

Debugging a failed activation. When activation silently fails, check in this order:

1. storage/logs/laravel.log — the module's service provider is likely throwing on boot.
2. modules table — is there a row with active = 0 stranded?
3. composer.json of the module — missing autoload entry means the class can't be resolved.
4. module.json — malformed name/namespace is a classic silent failure.

Because Workshop swallows activation errors in the UI, the log file is your real diagnostic tool.

Extension points. The module fires lifecycle events around activation; hook these from an app-level service provider if you need to run one-off setup (seed permissions, register observers) when a module is enabled:

Event::listen('module.activated', function ($module) {
    // seed module permissions, etc.
});

Event names vary by AsgardCMS version, so grep the Workshop source for Event::fire before relying on them.

Version pinning is critical. Workshop targets a specific AsgardCMS/Laravel generation (5.x era). Do not assume it works with modern Laravel. Before adding anything, confirm your AsgardCMS version matches the Workshop branch you pull in — the module's service provider registration, migration paths, and event names all changed between AsgardCMS releases.

Prefer module:* Artisan commands over UI clicks in anything scripted. The Workshop UI is fine for local toggling; for provisioning, testing, or CI you want the commands, which are testable and reproducible.