Use this page when an addon needs a shared Core API or helper instead of inventing a local utility. Prefer existing rails for identifiers, routing, responses, security, list controls, and public target handoff.
First Check
- Search Core for an owner before adding helper code to an addon.
- Use the narrowest helper that already matches the job.
- Keep addon wrappers thin; do not fork shared behavior into addon-local copies.
- If a helper is missing, document the gap before creating a new shared API.
Common Rails
- `core/identity/uuid.php`: UUID generation, validation, and UUID fragments.
- `core/identity/slug.php`: public slug normalization and manual slug cleanup.
- `core/http/response.php`: app-relative URLs, redirects, JSON, and error responses.
- `core/http/list_controls.php`: search, sort, pagination, filters, and row-count parsing.
- `core/security/csrf.php`: token names, issuance, and validation.
- `core/security/permissions.php`: permission checks for protected admin actions.
- `core/routes/router.php`: route registration and request dispatch.
- `core/hooks/*`: hook and event registry and dispatch rails.
Addon Pattern
$slug = amv_core_slug_normalize_manual($title);
$pageUuid = amv_core_uuid_v4();
$url = amv_core_response_app_path('/admin/index.php?view=wiki');
Keep the owning addon responsible for business rules. Shared helpers should shape common mechanics only.
Handoff Notes
- Admin screens should pair `core/http/list_controls.php` with the shared list layout.
- Public linkable addon records should expose public targets for Menu Manager.
- Permission keys should be declared in the manifest and enforced with Core permission helpers.
- Route keys and paths should remain visible to system governance and Installer through manifest/admin route contracts.
Related pages: Identity, Slug, and Key Helpers, Shared Admin List Behavior, Public Target and Menu Selection Contracts, Permission Manifest Declarations, and Hooks and Events/Hook and Event Overview.