Adds Previous and Next buttons to the bottom of backend record pages, so you can step from one record to the next without going back to the list.
The buttons follow the list you were actually looking at. If the list is sorted by company name, Next is the next record alphabetically. If you searched for something, Next stays inside the search results. If you have filters applied, Next respects them. And it steps past the end of page one instead of dead-ending at record twenty.
Because reviewing records one at a time is the single most common thing anyone does in a backend, and October makes you return to the list every time.
The naive version of this feature — walking record IDs — is worse than useless on any list that isn't sorted by ID, because the order you navigate silently disagrees with the order you see. This plugin asks the list controller for the exact query it would run itself, so the two can't drift.
When a record isn't in the current result set at all (you filtered it out after opening it), no buttons are shown. A missing button is better than a button that goes somewhere you didn't expect.
composer require albrightlabs/navigable-plugin
Then add the behavior to any backend controller that already implements
ListController and FormController:
public $implement = [
\Backend\Behaviors\FormController::class,
\Backend\Behaviors\ListController::class,
\Albrightlabs\Navigable\Behaviors\RecordNavigable::class,
];That's the whole integration. No config file, no migration, no view changes — the behavior renders itself into the page footer.
There is one option, and most installations never need it:
public $navigableMaxRecords = 5000;To work out which record comes next, the plugin reads the ordered keys of the current result set. This caps how many it will hold in memory at once.
Past the cap the plugin isn't wrong, only narrower: a record inside the window still gets exact neighbours, and only a record beyond it loses its buttons. Raise it if you routinely work deep into very large lists, and are comfortable with the memory that implies.
From the list's own recordUrl in config_list.yaml:
recordUrl: acme/blog/posts/update/:idSo the buttons open records the same way clicking a row does — update,
preview, or anything else — and they only appear on that action. If a list
defines no recordUrl, the plugin falls back to the conventional
.../update/:id.
The controller must implement both ListController and FormController. The
behavior reads the list widget to find out what the current result set is, and
the form to find out which record you are looking at.
If the list widget can't be built for any reason, the buttons are quietly omitted and a warning is written to the log. Navigation never breaks the page.
- Keyboard shortcuts for previous/next
- An optional "record N of M" position indicator
MIT