XWiki 12.x cycle roadmap

Help / Discuss
, ,
#1

Hi everyone,

We’re just starting the new XWiki cycle: XWiki 12.x.

We’re curious to hear from XWiki users what they’d like to see and what they think we should focus on. No promises but we’ll listen :slight_smile:

I’ll also post later some ideas that we have.

Thanks. Let’s start!

PS: For reference, the previous brainstorming threads:

#2

A smoother experience for deleting pages, automatically going back to the parent for example.

A way to easily select things to not copy when creating a wiki from a template wiki (i.e. users, local users, comments, etc.).

Better handling of quotes in macros’ parameters.

An easy way to get notifications of object changes.

#3

Thanks Michael for the feedback. Plenty of good ideas.

Not sure if we should redirect automatically since user may want to see the status before the redirect, but having a button to “Go to parent” could be nice indeed.

Would be great if you could create a jira issue at https://jira.xwiki.org

Seems like a good idea. I’d propose the full tree of pages with ways to select/unselect a set of pages (like users, etc).

Would be great if you could create a jira issue at https://jira.xwiki.org

Could you provide ore details by what you mean by better? AFAIK it’s handled correctly already.

It would be easy I think to add this as a filter (we already have the special case for comments). What’s your exact use case? (why are you interested in just object changes for ex). And are you interested in a specific xclass or all of them?

35

Would be great if you could create a jira issue at https://jira.xwiki.org

Keep the ideas coming!
Thanks

#4

Hey there,

a few suggestions from me:

  • Possibility to move multiple pages at once (via Drag & Drop would be ideal). Example: If you have 20 pages on the same subpage-level but only want to move 10 of them, you have to click and deteremine a place for each site 10 times.

  • Having an * added hidden and automatically to a search term (dont know the name of this function). Right now if I have a page named “My Awesome Page” and type in “awes” I dont get a suggestion for that page whereas “awes*” gets me one.

  • Showing more Users & Groups on all Rights-Management Pages would improve them a lot.
    Example: When I have 22 Groups in my Wiki and I want to manage the rights for a page, I have so much vertical space to show these groups, but only 10 at a time are shown and I have to click on the pagination to get to the other ones. Increasing this number to e.g. 100 would be a lot more comfortable.

#5

On this last point, I have some remarks:

  1. Why would you want to show more? You can start typing in columns to filter out entries. At some point showing a lot is going to be hard to read, no? What’s your use case?
  2. You can choose how many you select to display. It’s 15 by default but you can click and show up to 100. 38
  3. For me 15 is just about the right size to take all the vertical space

Thanks for the other ideas, they seem good!

#6

Thanks for your reply, I’ll gladly answer:

I refer to the Setting Rights Pages which you encounter for example in the Admin Menu or on setting rights on pages themselfes:

download

There is no option to show more than 10 results.

Our use case is for example creating new groups and then setting rights to a page similar like other exisiting groups. Right now we would have to go back and forth between for example results 1-10 <–> results 31-40 and dont have an overview at a glance.
If we use the filter, we would filter out the groups we want to set and also cant see multiple “target”-groups at once if they dont have similar names. So we had to back and forth between typing in the group we want to see, delete the string and then type in the group we want to set.

Another use case is if you have more than 10 groups, you cant see the standard-groups “XWikiAllGroup” and “XWikiAdminGroup” at a glance and have to navigate to the end of the list.

I know this is just a small issue and only a comfort one, but I thought I’d add it because it seems to be an easy improvement (I hope :smiley: )?

#7

ok that’s because you’re in an oldish version of XWiki! We’ve refactored this already :wink:

1 Like
#8

My bad, sorry then…
We are using LTS 10.11.8

#9

ok that explains it! :slight_smile:

See all that you are missing: https://www.xwiki.org/xwiki/bin/view/Blog/XWiki11CycleReleaseNotes

To be precise I think it was implemented in 11.8RC1 with this feature: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.8RC1/Change014/

:slight_smile:

1 Like
#10

FWIW here’s my personal wish list for 2020:

  • Offer Kubernetes packaging (helm chart)
  • Build is passing without any test flicker and find a way to make that the norm!
  • Implement CD for XWiki releases
  • Active installs increased to 7-10K active instances by end of 2020 (we’re at 5200-5700 right now)
  • Highly scalable Notifications architecture designed and in place
  • Improved performances (response times)
  • Inline editing and specific WYSIWYG editors for various macros (Gallery, Container, Code, Script macros, etc)
  • Usability: Less page navigations (inline editing for example), more autocompletions everywhere, think about each action a user can do in xwiki and find the simplest possible way to implement it
  • Much simpler global UI/layout, uncluttered (while retaining the power of xwiki but hidden)
  • Strong REST/GraphQL APIs in order to easily build client-side dynamic UI with JS and state of the art frameworks (React, Vue.js)
  • Nice GSOC projects!

What’s your? :slight_smile:

#11

I wish everyone a good switch to 2020 in a few hours!

Concerning wishes for Xwiki 12:

  • More and reliable inline editing would be nice.
  • Easier reordering of pages (as @OezDur wrote) also would be nice.
  • Reliable RTWYSIWYG editing (But maybe this already works in Xwiki 11? I’m still on 10 LTS.)
  • Better support for “my page (sub) hierarchy actually represents one big structured document”:
    • XWIKI-16453 ‘Provide Some Explicit “Ordering” for Pages and Sub-Spaces in a Given Space’
    • XWIKI-16452 ‘Navigate to Next/Previous Sibling Feature’
    • Utilize those features in the Office document importer (XWIKI-16575, XWIKI-16574).
#12

ok that’s because you’re in an oldish version of XWiki! We’ve refactored this already

We refactored the User and Groups administration sections but the Rights section is still using a custom live table that doesn’t provide the option to change the number of rows per page. We need to decide if it’s worth fixing this issue alone (by using the standard live table component) or wait for http://jira.xwiki.org/browse/XWIKI-14416 .

#13

This is https://jira.xwiki.org/browse/XWIKI-11046

and this is https://jira.xwiki.org/browse/XWIKI-14596 and https://jira.xwiki.org/browse/XWIKI-10306 .

1 Like
#14

Here are my top 10 wishes regarding XWiki 12 so far, open for debate :–)

  • Better support for simultaneous editing of content or objects.
  • Ability to be in edit mode by default when authorized for speeding up modifications.
  • New skin based on React or Vue for easier component-based programming, likely to result in a more efficient user experience. See existing Vue prototype.
  • New livetable harnessing the newly selected JavaScript framework.
  • Ability to plug new code or wysiwyg editors. See also the existing Monaco extension.
  • Make the Ring application a recommended extension.
  • New content hierarchy layout allowing to not bloat content spaces with code spaces.
  • Easier upgrades, possibly with having several versions of the same extension installed in the wiki but in different locations, allowing to migrate an application more progressively (not sure).
  • Notification scalability.
  • Improved performance.
#15

Not sure what you mean. Each namespace (each wiki for example) can have its own version of an extension.

1 Like
#16

That depends only on you actually :slight_smile: See https://extensions.xwiki.org/xwiki/bin/view/ExtensionCode/RecommendedExtensions/RecommendedDefinition/ If the extension already abides by these points then it can be recommended right now.

1 Like
#17

Actually I see that it’s mentioned " Not to be installed directly with the Extension Manager, please refer to the installation notes.". BTW this shouldn’t be in the title but in the description as a warning or int he installation instructions.

What would it take to make it installable?

1 Like
#18

Regarding the Ring extension: ok, I’ll make sure the warning is not in the subtitle anymore in the next release (I just removed it manually from the wiki page for now), it’s already present in the installation instructions. Making it installable via the extension manager would require fixing XCOMMONS-1814. Thanks for the link about the recommended extension criteria, I’ll see what I can do.

#19

Indeed, but what I have in mind would be to have several versions installed in the same wiki. Each standard extension would be made entirely read only. Then, a user willing to customize for instance the BlogSheet would create a page MyBlogApp.BlogSheet elsewhere, which would contain a metadata hinting at the fact that this page should have priority over the standard Blog.BlogSheet (possibly a bit like the alias feature idea, not sure).

I have not investigated much but I was wondering if it could make things easier for upgrades: the standard extensions would be installed without risk since they are read only. The ones that got customized in the wiki would live together with the new standard ones, and would be merged step by step. Once they have been successfully merged, the customized versions would have priority again over the standard ones.

We could draw an analogy with Eclipse plugins (as discussed with @caubin some time ago): Eclipse is both made of plugins, and used for creating or customizing plugins, just like XWiki. When a new version of Eclipse is installed, it comes with all its new or updated plugins, and the customized ones are present in the new environment but they live in their own area, I guess: they do not override “physically” the original ones, do they? They probably inherit from some public classes, or use extension points rather than strict physical overrides? “Physical” overriding eases the customization process but at the cost of a high upgrade cost process in my opinion, not sure though.

#20

We decided a long time ago we wouldn’t go in that direction since that meant OSGi and it was too complex. It would be quite hard to change now I think.

1 Like