[Brainstorming] XWiki 11.x cycle roadmap



Especially the CKEditor is typically broken after each update (of ckeditor), forcing the user to [Ctrl]+[F5]) the page. Clearing the browser cache also works, but this is undoable for casual users.




I’ll quantify more exactly on the upcoming 10.10 update to show you what I mean.

The only reason it bugs me is that it takes a noticeable enough time that I think with each update, “do I want to do this now?” rather than just updating without thinking about it.

FWIW, the process is much less painful than it was with Confluence, so I might just be nitpicking, hence the low priority.


pinned #27


I’ve added some improvements ideas that could improve the Usability at https://forum.xwiki.org/t/usability-10-x-analysis-and-11-x-suggestions/4010


pinned globally #29


Hi! I have some ideas .My English is poor, please forgive me for my poor expression.

1. XWiki’s UI and UX should improve.

We have used XWiki for half a year , so we have modify much of page UI and UX. There is our XWiki page demo:
I think XWiki should provide some more modern flavors which have a better UI.
And UX , such as :
We have made a change that automatically redirects the user to the target page when a page is copied successfully.There are the origin XWiki’ copy status page:
But I think user do not care about the copy status, just show the target page when copy is success. Like github fork a repository, when success, it will direct to the target repository.

2.Improve XWiki’s wysiwyg-editor

I have to say that XWiki has a powerful editor which can parse scripts, insert macros and so on . The syntax of XWiki/2.1 is so cool. But I also have some advices.

  1. The editor is best updated to CKEditor5. CKEditor5 is provide a better UI and edit experience. And it is more easy to develop autosave feature.
    I have tried CKEditor5 on XWiki ,look :
    But there also have some hard problem wait to solve.
    So I hope the XWiki 11.x would upgrade to CKEditor5 officially. it is XWiki’s jira issue.

3. Fix XWiki’s markdown syntax bug.

The jira issue. But the syntax not only this problem .Such as :
it is the markdown source code :


in Github , it is well:
but in XWiki :
So markdown syntax is too hard to use in XWiki.

Also have some other ideas . I will post later.



I would like that very much :slight_smile: but currently we don’t have the resources to handle more than one skin on the community side. Plus we are trying to make the default skin as generic as possible and to accommodate any Flavor’s requirements.
Still, custom skins could be placed in the Extensions Repository and I would love to see more contributors there :slight_smile:
BTW your screenshot looks very nice!

This is a very interesting note. There are already some issues created for:

We currently display the status and prepare ourselves if things go badly, so that the user can take action.
But indeed, if the operation is successful, we could try to do the automatic redirect. Now, this should be mandatory in case of rename / move, but in case of Copy the user might want to go to the old version. Anyway, if we do this change, we should do it consistently for all the cases.

Maybe you could create an issue with this suggestion?

We should also update to CkEditor5 at some point. Again, need to find the resources and the time. But you have a good point.

Apparently we have over 1000 active installs across all Markdown syntaxes, so it has some decent usage. Still, would be nice if you could vote on the issue, to have a way of knowing that this issue is important for our community.

Thanks @wuguokai for your suggestions. They are really nice.



One very important thing to fix that I forgot is https://jira.xwiki.org/browse/XWIKI-15620. Filesystem attachment storage is close to unusable for non-latin languages right now.

1 Like


One important thing can be about having separate location for User Profile pages and Group pages which are currently under XWiki page.
It would be really simple to manage users in that way.



A short discussion on BigBlueButton as xwiki extension here.

An example [here](https://doc.tiki.org/BigBlueButton 7).



@Vishal Thanks for the idea. However this is not going to be a core feature, i.e. not in XWiki Standard which is the main scope for this brainstorming. In practice this means it would be great for the community (thus including you) to participate to the development of this feature which would be packaged as an extension (ideally a contrib extension on https://github.com/xwiki-contrib).

Anyone interested in developing it? XWiki core devs would be very happy to help answer questions and are available on IRC/Matrix + devs mailing list.


PS: Another possibility is to ask for someone to develop it and sponsor its development. XWiki SAS supports such sponsored development if you’re interested, see https://www.xwiki.org/xwiki/bin/view/Main/Support#HProfessionalSupport



Hey I am no developer. But I would like to contribute to this wonderful wiki project.
I will really look into the sponsoring in near future.

Thanks XWiki



Hi, a brainstorming?

(Post edited to add: a nice way to decrease xwiki URL ie with lot of % characters and too long when refering to a sub sub sub children page)






Here’s your zen mode for http://playground.xwiki.org/xwiki/bin/view/Sandbox/ for example:




Nice! ty



But it would be a good idea to have a menu entry to lead to this, in the “…” menu for example.

A jira would be nice :slight_smile:




By the way, in WYSYWIG editor my users want a simple way to colorize some lines (or column) of a table.




Update page Navigation tree so that hidden items are visually distinguished from content normal users would see.

For example: I have “display hidden pages” set to “Yes” under my profile preferences; however, I cannot easily distinguish between Normally hidden pages and always visible pages in the Navigation Tree.

Also- I think setting this option to “Yes” also shows redirects in the navigation tree - if so, it would be useful to visually distinguish these as well.

1 Like


New idea for 11.x cycle: Allow customization of Solr search defaults via Admin GUI.

For example: we have a main wiki and a “dev” sub-wiki. I would like to limit search results to the main wiki by default.

In general, it would be nice if admins could easily manipulate the default facets / scope for Solr.

(this is detailed on: https://extensions.xwiki.org/xwiki/bin/view/Extension/Solr%20Search%20Application#HSearchAdministrationSection)



I only start using xwiki as a user and really like it. Well, not sure if this is only in our installation(s), but when adding a macro using CKEditor one ends up at the beginning of the page all the time after adding … one need to scroll down to the paragraph where the macro was inserted … a bit annoying …

Anyone else experiencing this? If this is normal behavior, it would be nice if one would stay at the position of the page where the macro was added

Thank you