kitloom

Appearance

Installing Modules ​

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?

Installing a module ​

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

bash
composer require kitloom/redirects kitloom/redirects-filament
bash
composer require kitloom/redirects kitloom/redirects-nova
bash
composer require kitloom/redirects

Run its migrations, if it has any:

bash
php artisan migrate

That's it. On the next request:

  • the module's service providers are registered by package discovery;
  • its routes, middleware and page parts are in place;
  • its section appears in the admin panel, in its WordPress-like place in the menu;
  • its permissions appear on Users → Roles (if you use kitloom/permissions);
  • 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/seo requires kitloom/site and kitloom/shortcodes, and kitloom/post-types requires kitloom/custom-fields. A typical content site:

bash
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
bash
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

Placing the admin section yourself ​

An admin package adds its own section. If your site wants the items somewhere else — say, all SEO tools under one "Marketing" group — switch the package's automatic section off and register its resources yourself:

php
// config/kitloom-redirects.php
return [
    'filament' => ['register' => false],
];
php
// app/Providers/Filament/AdminPanelProvider.php
use Kitloom\Redirects\Filament\RedirectsPlugin;

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

kitloom plugins are idempotent: if the plugin arrives twice — from the package and from your panel provider — its resources are registered once. All switches are listed in Configuration.

Removing a module ​

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

bash
composer remove kitloom/redirects-filament kitloom/redirects

Its tables and options stay in the database; the module's own migrations do not drop data when the package is removed. If you only want to switch a module off for a while, deactivate it instead — that needs no deployment.

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: CI installs (a pull request with composer require, tests, deploy) and the admin activates what is installed.