Independence rules

Table prefixes, uninstall behaviour, child modules and the compatibility states, in detail.

The kernel enforces these. They exist so that a buyer can install, disable and remove any module without ever putting the core at risk.

1. Your tables, and only your tables#

Every table your migrations create is prefixed mod_<slug>_, with hyphens turned into underscores. For a module with slug members-plus, that is mod_membersplus_ or mod_members_plus_ depending on the slug you chose, and it is checked at install time.

Reading core data is allowed. Structural writes to anything outside your prefix are not, and a package whose migrations reach outside is refused.

2. Uninstall removes your module and nothing else#

onUninstall(bool $purge) drops your tables and clears your migration records. The core is untouched, so reinstalling starts from zero.

Disabling is the reversible operation: nothing is deleted and the module comes back exactly as it was. Make sure onDisable() is not doing any cleanup that onEnable() cannot undo.

3. No foreign keys across modules#

Never point a foreign key at another module's table. That module can be uninstalled while yours is running, and a dangling constraint would take the whole site down.

Use a polymorphic reference with a string alias instead, and resolve it through a guard.

4. Own language files#

Code

modules/<slug>/resources/lang/en/<file>.php

Loaded under a namespace and referenced as slug::file.key. Nothing of yours goes into the core language files, and every string is authored in English.

5. Failure is isolated#

Boot is resilient: a module that throws is skipped and the request continues. Do not rely on that as error handling, but do rely on it for the guarantee it gives your buyers.

6. Child modules#

parent: "<slug>" declares that your module extends another module rather than the core.

A child requires its parent installed and enabled.
Disabling the parent disables its children in cascade.
Uninstalling a parent is blocked while a child is installed.
Children are listed indented under their parent in the panel.

The payment gateways are the canonical example: each one is a child of payments and registers its driver only while the parent is active.

7. Compatibility states#

State	Trigger	Effect
Up to date	`tested_up_to` is at or above the running core	Normal
Outdated	`tested_up_to` is below the running core	Amber notice, keeps working
Incompatible	A `requires` entry is no longer satisfied	Disabled at boot, cannot be enabled until updated

Keep tested_up_to honest. It is what tells a buyer whether to expect trouble.

8. Your own settings#

A module can have its own settings pages, independent of the core ones. Declare the route name in settings in the manifest and the module list shows the shortcut while the module is enabled.

Checklist#

Tables prefixed and dropped on uninstall.
No foreign key to another module.
Every string in your own language files, authored in English.
Every cross-module call behind class_exists or Route::has.
Compiled assets in the package, no build on the buyer's host.
No inline script anywhere.