#4542 - Previous, Up, Next Wiki Page Links/Buttons
-
By mythus
- Added
- 5 views
| Identifier | #4542 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Previous, Up, Next Wiki Page Links/Buttons |
| Status | Open |
| Tags |
Has Patch (custom) Roadmap: Over the horizon (custom) |
| Handling member | Deleted |
| Addon | wiki |
| Description | So, I have this problem.... I have a large wiki with lots of categories and lots of pages in said categories. When I go into a category to look at a page, I sometimes want to go to the next page following it. Or sometimes to the previous page. To do so, I typically have to go back to the gategory tree listing and click on the next page there. What I propose is to have a set of buttons at the bottom of the page. These buttons would go to the previous page or next page in the tree listing order. The Up button would bring you to the front page of the category. This would help with navigating wiki pages and taking in information listed there.
Ideally it should be a dynamic box that the website designer could add to the bottom of the page (or top if desired I guess), much like the table of contents. |
| Steps to reproduce | Try checking out my site wiki just to see why I'd want this...? |
| Additional information | This is ideal for a Wiki, but it could also be useful for catalogues. |
| Related to | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
For it to just go horizontally across parents of the same parent category:
[block multi_level="0"]wiki_nav[/block]
For it to do full tree traversal:
[block multi_level="1"]wiki_nav[/block]
Or you can put it in the WIKI_PAGE_SCREEN.tpl template like:
{$BLOCK,block=wiki_nav,multi_level=1}
Full tree traversal is less efficient as it has to load the whole tree, but I did cache the tree so it shouldn't be too bad. That's why there's an upon_query hook, to flush out the cached tree if the Wiki+ tree is changed.
The block looks at the current ID in the URL to see where the user is currently at. So it only is going to work when used directly within Wiki+. Not that you'd want to place it outside of Wiki+.
It works, of course. The odd thing is the back and forward seem to be going based on page name in alphabetical order, instead of ID #, despite looking at your php code and I swear you have it wrote to go by ID #. No biggie though, it still works for what I want it to do. Maybe I can brush off an old php book and learn a little if it bothers me too much. It is at least keeping the pages in their categories.
Thanks again Chris, you rock.
https://www.patreon.com/composr
It's ordering by the the_order field in the wiki_children table.
I am wondering if somehow that field became defunct intentionally, or if I forgot - because I can't see it being used in the code.
I'll take a look tomorrow.
And it's not, because of a bug in the sitemap code I just found, hot-fix in this issue:
https://compo.sr/tracker/view.php?id=4546
The block code did use the_order, but that was only actually in effect if multi_level=0.
EDIT: Patch is now outdated, would need refreshing.