Menu (PRO)
Extra items in the manager menu, created from the constructor. This is how a table you built stops being something people reach through the PageBlocks section and becomes a normal part of the admin panel.
PageBlocks → Constructor → Menu.
What an item holds
| Setting | What it does |
|---|---|
| Title | The caption in the menu |
| Description | Hint shown under the caption |
| Parent | Which item it nests under. Empty means the top level |
| Icon | Icon class |
| Handler | What the item opens |
| Folder | A container: opens nothing itself, only expands its children |
| Position | Place among its siblings |
| Published | An unpublished item is not rendered |
Who sees it
Each item carries permissions — a list of users and user groups. Leave both empty and the item is visible to everyone with access to the manager; fill either and it narrows to them.
This hides the item, not the page
The menu is navigation. Removing an item from someone's menu does not stop them opening the address directly. Guard the page itself with middleware — modauth, SudoOnly, or your own — and treat the menu permission as tidiness rather than access control.
Folders
A folder item has no page of its own. Give it a title and children, and it becomes a group in the menu.
That is the usual shape once you have more than three or four tables: one folder named after the area — Catalog, Orders — with the tables inside, instead of a flat list that pushes the rest of the manager off the screen.
Why bother
A table in the constructor is reachable, but the path is long and it looks like a developer tool. An editor who opens Catalog → Products every morning should not have to go through a section named after a component.
The same argument as tabs, one level up: the structure should match how the site is actually worked on.