Module developer framework

Discover, validate, version and operate third-party extensions.

Manifest

Place kbilling.json beside the module entry file. The required fields are schema, type, name, version and author. Recommended fields include slug, description, compatibility, requires, capabilities and type-specific settings.

{
 "schema": 1, "type": "servers", "slug": "acmecloud",
 "name": "Acme Cloud", "version": "1.2.0", "author": "Acme",
 "compatibility": "native",
 "requires": {"php": ">=8.2", "kbilling": ">=1.0.0"},
 "capabilities": {"vps": true, "sso": true, "power": true}
}

Discovery and validation

Modules are discovered from modules/{type}/{slug}/{slug}.php. Open System Settings → Module Developer to inspect metadata and run static safety checks. The validator rejects obvious command execution, dynamic evaluation, unsafe deserialization and disabled TLS verification. Warnings flag direct SQL, file writes, WHMCS runtime dependencies and possible card-data references.

Lifecycle

Native classes may implement install(), activate(), deactivate(), upgrade() and uninstall(). Procedural modules may implement {slug}_{action}(). Lifecycle state and version are stored centrally. Uninstall hooks run without deleting files.

Logging

kb_module_log('servers', 'acmecloud', 'info', 'Provision request completed', [
  'service_id' => $params['serviceid'],
  'token' => $secret, // automatically redacted by key name
]);

Logs are stored under storage/logs/modules/, rotate at 5 MB, and redact common credential patterns. Do not intentionally pass customer secrets or payment payloads.

Starters

Copy templates from docs/starters/. Rename the directory, entry file, class/functions and manifest slug consistently before validation.