We are evaluating a XWiki for a use case with potentially a lot of pages. Using the navigation menu on the left-hand side (is there more than one implementation depending on the theme?) is getting awkward quickly, as it seems to be dynamically constructed each time the user changes to a different page (it takes a long time if you have many pages). This might be more of a principal issue - are there configuration options/strategies to get a more “static” navigation menu (including tips on having less entries in that menu)? Thanks!
Hi, if you want a pure static tree, you could have one, see https://extensions.xwiki.org/xwiki/bin/view/Extension/Tree%20Macro
Re the DocumentTreee macro there are some params, see Document Tree Macro (XWiki.org) (including the limit parameter and more).
Thank you - sorry, if this is a newbie question: where is the place for low-level configuration of these extensions - I assume I will not use a subpage of “Administer Wiki” for this?
Sorry, I,don’t understand the question.
You just need to use them wherever you need them. For example if you want to use the doc tree macro in a panel, then you use it there.
It is very likely that I am missing something obvious, sorry - the only place I found to change the panel settings was: /bin/admin/XWiki/XWikiPreferences?editor=globaladmin§ion=panels.navigation - I assume this is also where I can somehow edit the source code - but I have found no button/menu for this?
If you want to change the Navigation Panel then you need to navigate to its page and edit it, as you would do for any page. There’s no specific setting to change the content of a panel.
See Panels Application (XWiki.org)
You should be able to edit a panel from there, by going to the Panel List tab and clicking edit on the Navigation panel.
Now I don’t recommend that you do this. Instead, it’s much better to create your own panel and use it instead of the Navigation Panel.
Yes, thank you, this worked very nicely and we now have a custom Navigation panel. However, there are obvious advantages to a dynamic solution - our main problem is the performance - while this is probably not technically slowing down users, it really gives a bad impression.