Modules
Ready-Made Modules
Six whole areas shipped as composer packages — what each one installs, what it needs from the application, and how to take one back out.
A module is one business area's manifest: the resources,
dashboards and menu heading it consists of. These six ship that manifest as a
composer package, so an area arrives with composer require rather than with a
class to write and a config line to remember.
composer require nyoncode/wire-module-users
That is the whole installation of most of them. The package's own provider registers the module as a plugin, the module fills the registries that already existed, and the menu, the router and the search palette pick it up from there — the same path an application's own module takes.
How It Works
Nothing here is a second kind of thing. A shipped module is a plugin that names resources and dashboards, and everything downstream reads it through the catalogue:
composer requireputs the package on disk; Laravel discovers its provider.- The provider registers the module with
PluginManager— no config edit, which is the difference between a shipped module and one an application declares. WireCoreServiceProviderspreads what it declares into the resource registry, the dashboard registry and the navigation groups.Route::wireResources(), the sidebar and the palette read those registries and find the new area without being told.
A module an application cannot remove is what makes people stop installing
them, so every one of them is removable in two ways: composer remove takes
the whole area out, and each module's config can drop or replace what it
contributed while the package stays. Where a module ships a screen over something
the application already owns — a settings tab, a user resource — the
application's own declaration wins over the contributed one.
What Each One Installs
| Module | Package | What arrives | Needs |
|---|---|---|---|
| Users | wire-module-users |
The user resource, its pages, a profile screen, and role management where the application has roles | A user model; nyoncode/laravel-permission-extended for the role surfaces |
| Auth | wire-module-auth |
Sign-in, password reset, e-mail verification, the two-factor challenge, Sign out in the user menu, and one-time codes where a mailed code stands in for a password or a link | laravel/fortify — it owns the security, the module owns the screens |
| Settings | wire-module-settings |
A typed settings table, its cache, and the screen over it | A database connection |
| Notifications | wire-module-notifications |
The history behind the notification bell, as a table | Laravel's notifications table |
| Audit | wire-module-audit |
A screen for the trail wire-core already records |
HasAuditable on the models you want followed |
| Media | wire-module-media |
A media library — uploads, folders, previews, and a picker for forms | A filesystem disk |
Teams and Two-Factor is not a seventh package: it is
the guide to switching on the two surfaces the users module keeps behind an
auto switch, which look for the thing itself — Fortify for two-factor, the
permission package for teams — and stay off when it is absent.
Installing Them Together
wire:install offers every module it can see and names the ones it cannot,
because offering a module that is not installed is the point — a list of
composer require lines you can copy is more useful than silence:
composer require nyoncode/wire-suitephp artisan wire:install
It never runs composer for you. See Installing Wire for what the installer does and what it refuses to do.
Writing Your Own
The six are ordinary modules with a provider around them, and
packages/module-users is the reference implementation. What a module
declares, how it depends on another, and how a package ships one are covered in
Modules.
Related
- Modules — the manifest itself, and declaring one in an application
- Resources — what a module's areas are made of
- Plugins — the registration path a module takes
- Installing Wire — the interactive installer that offers them