Modules

A module is how you add a feature to Tiger. If it has controllers, routes, an API, views, or ACL — it's a module. If it's shared, route-less plumbing — it's the app library instead. This page is the module reference; for a hands-on first run see Your first module.

A module is a folder

Modules live in application/modules/<name>/ and are auto-discovered — Tiger scans the modules dir and runs each active module's Bootstrap.php. There's no central registry to edit, no "register your module here" step. One catch: an app module is opt-in — it stays inactive (its Bootstrap.php, routes, config, and ACL don't load) until you activate it. The first-party modules bundled in core are the opposite: active by default (opt-out).

application/modules/billing/
├── Bootstrap.php                     # the module's entry point (auto-run on boot)
├── controllers/IndexController.php
├── services/Example.php              # your /api surface — Billing_Service_Example
├── views/scripts/index/index.phtml   # .phtml view scripts
├── configs/
│   ├── module.ini                    # module settings
│   ├── acl.ini                       # who can reach what (deny-by-default)
│   ├── routes.ini                    # pretty URLs (optional — the canonical path works free)
│   └── dependency.ini                # modules this one requires
├── models/                           # Billing_Model_* (extend Tiger_Model_Table)
├── migrations/                       # additive-only schema changes
├── layouts/                          # optional — a module can ship its own
└── assets/                           # published to /_modules/billing on activate

models/, migrations/, layouts/ and assets/ are created empty, ready for you to fill. Add forms/ (Billing_Form_*) and languages/en/billing.php yourself when you need them — they're conventions Tiger discovers, not files the generator writes.

Purely additive — it touches no core file

This is the contract that makes modules safe:

• Config — the module's configs/*.ini merge into the global config. It doesn't edit anyone's config; it adds to the cascade.
• Behavior — it exposes Module_Service_* classes; the core /api gateway resolves them by convention. Thin controllers, fat services.
• Permissions — resources are class names, gated by the ACL; the module ships its own acl.ini.
• Views / i18n / routes — same additive pattern, all namespaced to the module.

Because nothing in a module reaches into Tiger, and nothing Tiger ships reaches into a module, composer update can replace the framework under you without disturbing your feature. Arrows point one way: modules → core, never the reverse.

Activation is zero-infrastructure

vendor/bin/tiger module:activate billing      # on
vendor/bin/tiger module:deactivate billing    # off
vendor/bin/tiger module:list                  # what's installed / active

On activate, a module's assets/ (if present) are symlinked to public/_modules/<slug> — reference them at /_modules/billing/… (and route them through $this->asset() for cache-busting). A module never touches Apache/nginx, DNS, or anything outside its own dir. That's a hard rule: infra-touching activation would break 1-click install. A pretty public URL is a PHP-layer route override, not a rewrite rule.

Modules can also declare lightweight dependency alerts in configs/dependency.ini — activate warns if a required module is off; deactivate warns what depends on this one. They're convenience alerts, never hard blocks.

Scaffold, don't hand-write

Don't build the folder by hand — generate it:

vendor/bin/tiger make:module billing

You get a live controller + /api service + ACL + views + config to build from. Then it's the loop from Your first module: add a method to the service, and it's callable.

Where things go

Rule of thumb, any time you're unsure: does it have a route? Route → module. No route → library.