Filament Module Manager Laravel Package

Getting Started

• Treat this as a small admin UI over nwidart/laravel-modules, not as an installer or package manager. It is archived, so pin the version and verify compatibility with your Filament v4/Laravel/PHP matrix before adopting.
• Install into an app that already has Filament v4 and nwidart/laravel-modules configured:

composer require alizharb/filament-module-manager

• Register the plugin in the panel provider where module administration belongs:

use Alizharb\FilamentModuleManager\FilamentModuleManagerPlugin;

public function panel(Panel $panel): Panel
{
    return $panel
        ->plugin(FilamentModuleManagerPlugin::make());
}

If the plugin class name differs in your installed version, inspect vendor/alizharb/filament-module-manager/src first.

• Look first at:

  • the package src/ for the Filament plugin, Module Manager page, and Modules overview widget classes;
  • config/modules.php for nwidart module paths/discovery;
  • modules_statuses.json as the source of truth for enabled/disabled modules;
  • Modules/ for actual module code and service providers.

• First use case: create or pick an existing module, then manage it from the panel:

php artisan module:make Blog
php artisan module:list

Open the Module Manager page in the Filament admin panel, toggle Blog, then confirm the state with php artisan module:list. Put the Modules overview widget on an admin-only dashboard for a quick enabled/disabled health check.

Implementation Patterns

• Use the Module Manager page as a development/staging convenience: enable a module while building it, verify its routes/migrations/config, then clear caches immediately after toggling.
• Keep module state under version control. Treat modules_statuses.json like deploy configuration: commit intentional status changes, review them in PRs, and avoid ad-hoc production toggles.
• Pair UI toggles with the commands they do not replace:

php artisan optimize:clear
php artisan module:clear-compiled
composer dump-autoload
php artisan module:migrate Blog
php artisan module:seed Blog

• Register the plugin only in the admin panel. For multi-panel apps, do not expose module management to customer-facing panels.
• Add authorization around the page/widget. Filament navigation hiding is not authorization; use panel access, gates/policies, or a forked page with canAccess() if the package does not provide granular permissions.
• Put the overview widget on the admin dashboard for day-to-day visibility: enabled count, disabled count, and obvious stale/disabled modules. If the widget queries module state frequently, cache the counts and clear that cache after toggles.
• Use the package as a lightweight module health dashboard, not as a deployment orchestrator. Production module lifecycle should still run through deploy scripts, migrations, autoload regeneration, and smoke tests.
• If you need richer behavior—dependency checks, audit logging, per-module actions, custom metadata—fork the package or build a small Filament page around nwidart’s module repository instead of extending an archived dependency heavily.
• Before disabling a module in a shared environment, check for dependents, route/service-provider references, config usage, and queued jobs. A UI toggle is not a dependency resolver.

Gotchas and Tips

• Archived status is the biggest risk: no security patches or Filament v4 compatibility fixes. Lock the version, fork if it becomes important, and budget for maintenance.
• Toggling a module does not install, remove, or fully wire it. It will not run Composer, publish assets, run migrations/seeders, or fix autoloading. Expect to run the relevant module:* and Composer commands yourself.
• modules_statuses.json must be writable and persistent. In containerized/ephemeral deployments, a UI toggle can disappear on redeploy; commit the file or manage status through deployment configuration.
• Disabling a module can cause fatal errors if its classes, routes, config, or service providers are still referenced. Clear compiled/cache state and test the app after every toggle:

php artisan optimize:clear
php artisan module:clear-compiled
composer dump-autoload
php artisan route:list

• If the page or widget does not appear, check plugin registration, panel ID, widget discovery/registration, canView/authorization, and Filament’s cached navigation/routes. Clear Filament and Laravel caches before debugging the package itself.
• Do not assume per-tenant module state. Nwidart module status is typically global; multi-tenant apps need separate guardrails or custom logic.
• Restrict write access in production. A module manager page is a high-impact admin surface; limit it to trusted super-admins and prefer read-only visibility for everyone else.
• The package is unlikely to provide audit trails for who enabled/disabled a module. Add logging around critical toggles, or fork the actions to record changes.
• Use it where it saves time—local module development, staging demos, and admin visibility—not as the only control plane for production module lifecycle.