Your XWiki usability pain points

Hi XWiki users,

We’d like to gather your main pain points when using XWiki. This would help us define the future roadmaps.

Please reply to this post with your pain points, explaining the issue and mentioning the version of XWiki you’re using.

Thanks for your help!

The main issue that I keep facing is with user rights. I don’t know about others but I feel when you set some global or page rights, they should apply to the extensions on the page as well. E.g, if I add the menu extension to the home page, and set the home page to be viewed by unregistered users, I would hope the menu is also viewed as well. If I recall correctly, I had to change the permissions for the menu extension application as well in order for it to be viewed before it worked. Unless I had done something wrong before. Hope this helps and makes sense.


1 Like

For me, the very important pain point is url verses name issue.
As we had discussed in past, we should really have two fields while creating page…
1)Title and 2)URL

Currently, it is possible for an advanced user, though it too needs an extra click.

To really remove this confusion and to use both concepts fully, we should really have both fields one below another for all users.
Further if possible, we can have url beautification by replacing spaces with - or _ or other user choice by default.

I really hope this to be a priority for XWiki in near future.


Another issue is mobile UI for search bar on XWiki. The suggestions box for search bar doesn’t fit to the viewport/ mobile screen. It is wider and leave no choice to see full suggestions.

This is important for our organization as more than 90% users on our wiki are through mobile source.

On this topic, I thought about you today when I used a website which was showing both name + URL:


It could work I think if we show the URL being built.

Do you remember where this was discussed? Which JIRA or which mail?

It was discussed in

BTW, have you reported a jira issue for this on
By mistake I put it n wrong section.

Moved to thanks

With regards to the Navigation Panel: the data for this thing desperately needs to be cached. Having to load from the server every single time you open a page / click an “expand” arrow is infuriating. Cache the data, then load any changes in the background and update the interface. 99% of the time I am looking for a page that I have already seen.

The navigation panel seems to be my biggest problem too. Not only the reload every time you change to another page but also not being able to sort the panel or hide things from it (like blacklisting things).

I think this panel is not intuitive at all and it should give an easy to use navigation panel by default :slight_smile:


Thanks, but you’re describing a possible solution not the problem. I assume that the problem is that the tree is too slow to load / expand? As a simple user I don’t care how the data is loaded or if it is cached. How long does it take to load the tree and to expand a node? How many pages do you have? What version of XWiki and what database are you using? On we did some tests with a few thousands of pages and the request time was decent. See also my last comment there:

I did another test on MySQL with a page that has 100k child pages (half of which are terminal). The mean time (over 20 requests) for expanding this page node and paginating its child nodes is 1.5 seconds. The other nodes in the tree are not affected: expanding the Sandbox page is still ~50ms.

OK, I’ll start again:

AS A USER, I WANT THE NAVIGATION PANEL TO HAVE INSTANT INTERACTIVITY. I do not want to wait for a spinner on every single click of “expand.” I do not want to have to wait for the same spinners every time I navigate to a new page. As for your questions:

It takes 200ms - 1000ms per expand click. Anything less than instantaneous is unacceptable.

Top level: 5 categories. Next level: 7 - 19 categories (which seems immaterial, since you cap the responses at around 15 and slap a “more” label that has to be clicked leading to a spinner.)

Ubuntu 16.04
xwiki-enterprise-common/stable,now 9.4
xwiki-enterprise-mysql-common/stable,now 9.4
xwiki-enterprise-tomcat8-common/stable,now 9.4
xwiki-enterprise-tomcat8-mysql/stable,now 9.4
libmysql-java/xenial,now 5.1.38-1
mysql-client-5.7/xenial-updates,xenial-security,now 5.7.19-0ubuntu0.16.04.1
mysql-client-core-5.7/xenial-updates,xenial-security,now 5.7.19-0ubuntu0.16.04.1
mysql-common/xenial-updates,xenial-security,now 5.7.19-0ubuntu0.16.04.1
mysql-server/xenial-updates,xenial-security,now 5.7.19-0ubuntu0.16.04.1
mysql-server-5.7/xenial-updates,xenial-security,now 5.7.19-0ubuntu0.16.04.1
mysql-server-core-5.7/xenial-updates,xenial-security,now 5.7.19-0ubuntu0.16.04.1

Running on an AWS t2.small instance.


First, great work done on xwiki :slightly_smiling_face:

Second pain points:

  • from developper. Too much .js in xwiki now. It is difficult to debug/customize code. IMO using CSS instead would be better and accessibility friendly. When some js code doesn’t work well, most of features are down.
  • from user: too much js with lag (ie spinner.gif) and SpaceIndex macro ’ like missing.
    I mean a light tool to displayed all recent children pages of a parent page (with date update decr order)


One of my pain points is with adding users to groups. Ideally, it would be great to edit a user and specify all the groups that they should be a member of. Instead, “editing” a user (admin > users > click user) brings up their “preferences”. It wouldn’t be so bad if Admins had a tab for “Group Membership” here.

Related to this, I have to go through the Groups and add the user to them one at a time. But it’s really annoying that after adding the user to the group, it refreshes the table and goes back to the first page. So now I have extra clicks to get back to the page (when in reality the groups haven’t changed so why refresh?)

@crw I agree that the data should be cached and actually it is already cached. We cache all the documents. Thus it’s not normal that it’s slow for you. Maybe you have a lot of docs and you have a too small document cache? Look in the performance page for how to configure this. Except for this we’d also like to introduce a title cache which would allow us to not have to load documents at all and should increase perf even further, especially for the cases when some docs are not in the cache. The downside would be that there would be some cases when the displayed title is not fully up to date but that should not happen often and is IMO an acceptable trade off.

Hi Vincent, thanks for your reply! I am talking specifically about the Navigation Panel. It looks like a nested tree view of the page titles of the wiki.

36 PM

The loading spinners that show up on that thing are super-annoying, especially because it is a highly-trafficked widget, at least in my use case.

With regards to caching, I specifically meant caching in the browser; either in localStorage or IndexedDB. Basically, cache the tree structure so you don’t have to keep making user-visible JSON calls. It would be better to show old data and then fill in updates in the background even if it mutates the UI while I am looking at it. The current “wait every time for tree level n to load every time you click the expand arrow” is driving me crazy.

Yes, I understood that. My reply was in that context, i.e. the document titles are extracted from documents that are loaded in the XWiki document cache. Now that I’m online I can point you to the doc for the document cache, in case you have lots of docs:

If you want fast operations you need to have a large enough doc cache so that all frequently used docs find themselves in the cache.

Yes that could be an extra layer of optimization. But we’d still need the title cache if we want to go beyond the doc cache.

Normally the tree should open in under tens of milliseconds (ie almost instantaneously). I’ve just tried it on and I get instantaneous results. Maybe the connection from your browser to your server is slow?