Installing Modules

• Introduction
• Installing a module
• Requiring several modules
• Placing the admin section yourself
• Removing a module
• Why not install from the admin?

Introduction

Installing a module is a Composer operation: require the domain package and the admin package for your panel, run the migrations, deploy. There is no installer in the admin panel, on purpose — see Why not install from the admin?

A new site picks its modules once, while it is created from a skeleton: php artisan kitloom:install asks which to keep and removes the rest with Composer — see Installation. A module left out then, or one that came out later, is installed as below.

Installing a module

Pick the module in the catalog, then require its packages:

Filament

composer require kitloom/redirects kitloom/redirects-filament

Nova

composer require kitloom/redirects kitloom/redirects-nova

Headless

composer require kitloom/redirects

Versions

Every kitloom package is released at once, under one version, so composer require writes the same constraint (^1.0) for all of them and composer update moves them together. See the Changelog.

Run its migrations, if it has any:

php artisan migrate

On a Filament site, composer also runs php artisan filament:upgrade (in the skeleton's post-autoload-dump scripts), which publishes the scripts and styles of packages that have them, such as the visual editor. If you cache config and routes in production, run php artisan optimize as part of the deploy, as for any new package.

That's it. On the next request:

• the module's service providers are registered by package discovery;
• its routes, middleware, page parts and REST routes are in place;
• its section appears in the admin panel, in its WordPress-like place in the menu, with Settings and How it works at the end;
• its permissions appear on Users → Roles;
• it is listed as active on the Modules screen.

New modules are active

The site stores the list of deactivated modules, not the active ones. A module that was just deployed works immediately, without anyone visiting the Modules screen.

Requiring several modules

Modules that build on each other declare it in their composer.json, so Composer installs what is needed. For example, kitloom/shop requires kitloom/payments and kitloom/media, and kitloom/post-types-nova requires kitloom/custom-fields-nova. A typical content site:

Filament

composer require \
    kitloom/seo kitloom/seo-filament \
    kitloom/redirects kitloom/redirects-filament \
    kitloom/custom-fields kitloom/custom-fields-filament \
    kitloom/forms kitloom/forms-filament \
    kitloom/media-filament kitloom/navigation-filament

Nova

composer require \
    kitloom/seo kitloom/seo-nova \
    kitloom/redirects kitloom/redirects-nova \
    kitloom/custom-fields kitloom/custom-fields-nova \
    kitloom/forms kitloom/forms-nova \
    kitloom/media-nova kitloom/navigation-nova

kitloom/media-filament / kitloom/media-nova and kitloom/navigation-filament / kitloom/navigation-nova are not modules but the admins of the platform's media library and menus; most sites want them.

Placing the admin section yourself

An admin package adds its own section and places it in the menu. An administrator can rearrange the whole menu from the admin with the Admin Menu module — see Filament and Nova. To decide it in code instead, switch the package's automatic registration off and register it yourself.

Filament

// config/kitloom-redirects.php
return [
    'filament' => ['register' => false],
];

// app/Providers/Filament/AdminPanelProvider.php
use Kitloom\Redirects\Filament\RedirectsPlugin;

return $panel
    // ...
    ->plugin(RedirectsPlugin::make());

Nova

// config/kitloom-redirects.php — keep the resources, drop the sidebar section
return [
    'nova' => ['menu' => false],
];

// app/Providers/NovaServiceProvider.php — list them in a section of your own
use Kitloom\Redirects\Nova\Resources\NotFoundLogResource;
use Kitloom\Redirects\Nova\Resources\RedirectionResource;
use Laravel\Nova\Menu\Menu;

Nova::mainMenu(fn (Request $request, Menu $menu) => $menu->append(
    MenuSection::make('Marketing', [
        MenuItem::resource(RedirectionResource::class),
        MenuItem::resource(NotFoundLogResource::class),
    ]),
));

kitloom Filament plugins are idempotent: if the plugin arrives twice — from the package and from your panel provider — its resources are registered once. In Nova, nova.menu exists for the packages whose resources a site is likely to regroup (Redirections, Internal Links, Search & Replace, Import & Export); nova.register removes a package's admin entirely. Nova keeps one Nova::mainMenu callback: a site that uses the Admin Menu module and builds its own menu sets kitloom-admin-menu.nova.register to false, calls AdminMenu::sort($menu, $request) from its callback and lists AdminMenuTool among its tools. All switches are listed in Configuration.

Removing a module

To switch a module off for a while, deactivate it on the Modules screen — that needs no deployment.

To take a module out of the code base, remove its packages, admin first:

composer remove kitloom/redirects-filament kitloom/redirects

Composer keeps a package installed while another installed package still requires it. Its tables, options and meta stay in the database: removing a package runs none of its down migrations. Drop them yourself if you no longer need the data. If the module was deactivated, its name may stay in the list of deactivated modules; the list ignores packages that are no longer installed.

Why not install from the admin?

Installing Composer packages from a web request looks convenient, but on a real site it means:

• the web server needs write access to vendor/ and composer.lock — and so can run arbitrary code;
• a half-finished install breaks the site in the middle of a request;
• the code on the server drifts away from the lock file your deployment knows;
• several servers or containers each need the same change;
• there is no clean rollback.

So kitloom splits the job: the deployment installs — a pull request with composer require, the tests, the deploy — and the admin activates what is installed.