Custom menus
Tiger ships admin-authored navigation menus — build a menu in the back office, drop it into a theme, and it renders auth-filtered, localized, and tenant-aware with no code.
The model
A menu is rows in the menu table sharing a menu_key — one flat, self-referential,
tenant-cascading tree (an org's rows override the global ones). Each item's properties are stored
1-to-1: label, a page link or a URL, icon, CSS class, DOM id, target, and an optional ACL
resource/privilege.
Three ways a theme uses one
Reference the same menu however suits the template — all three are equivalent:
<?= $this->menu('primary') ?> // view helper
// shortcode (in CMS content)
Tiger_Menu::getHTML('primary'); // direct call
Every render is:
- Auth-filtered — an item with an ACL resource/privilege hides when the viewer can't access it.
- Localized — labels are translation keys.
- Resolved — a
page_keylink resolves to that page's current slug (retired slugs don't rot). - Marked — the active item is flagged.
Under the hood it compiles the tree to Zend_Navigation. Need the raw tree (no ACL filtering) for
custom rendering? Tiger_Menu::getData().
Authoring — the drag-drop builder
The admin Menus screen manages them: a DataTables list, plus a two-pane drag-drop builder — a
tabbed, filterable source palette (Pages / Custom) whose chips drag into the structure. The structure
is a flat SortableJS list with WordPress-style indent-by-drag (drag right/left to nest/outdent,
capped one level below the row above; parent/child is derived from order + depth). Each chip opens a
properties modal; everything persists over /api — insert on drop, reorder on move, update on save.
See also
- Authorization — how items hide by ACL.
- Localization — label translation + slug resolution.