XWiki 11.x cycle roadmap

Improve the speed of updating the extensions after an xwiki version upgrade

The current update process seems to take a very very long time. Not sure why. It’s a better admin experience if this time could be reduced.

Priority? Low.

Version control the urls of various version dependent elements

I believe there is already a jira issue about this.

When you update the wiki, users have to force reload the pages to get the wiki working again. It’s an annoyance that most users have to be hand held into doing this before they can use the wiki after an update.

Priority? medium

Could you tell us what you consider a very very long time? And how many subwikis you have? And whether you include conflict resolution as part of the time?

When I do upgrades, I also find it too long but I’d say the usual time I get is about 2-3 minutes.

+1

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.

@vmassol

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.

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

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:
image
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:
image
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 :
    image
    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 :
image

    <parent>
        <groupId>io.test</groupId>
        <artifactId>test-framework-parent</artifactId>
        <version>0.8.0.RELEASE</version>
    </parent>

in Github , it is well:
image
but in XWiki :
image
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.

Thx

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?
Then

(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)

thxs

Pascal

:slight_smile:

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

http://playground.xwiki.org/xwiki/bin/view/Sandbox/?xpage=plain&htmlHeaderAndFooter=true

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:

https://jira.xwiki.org/browse/XWIKI-16031

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

Thxs

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