Here are some ideas I have about what XWiki 10.x could focus on. Feel free to propose your ideas and comment on whether you agree/disagree. This list is obviously not a commitment to anything.
Global Topics for 2018:
Fix inconsistence of WebHome appearing everywhere when using references in macros and API calls.
Autocomplete everywhere, especially on reference. Note: This would lessen the issue with WebHome.
Example 1: In object editor when the type is “Page Reference” + picker
Example 2: In WYSIWYG macro editor when a macro has a reference parameter + picker
More generally Improve WYSIWYG macro editor to make it really usable simply and without the need to type wiki syntax.
Idea: For macros having wiki content, let the user enter it in the WYSIWYG directly. When hovering over the macro allow editing content + have some icons to edit parameters (similar to the CKEditor easy image feature: Easy Image plugin · Issue #932 · ckeditor/ckeditor4 · GitHub They call it a “balloon toolbar”).
Navigation panel needs overhaul to be able for the user to blacklist nodes and control better its content
Performance improvement to go back and be better than the performances of XWiki 8.x (we’ve regressed in 9.x). Examples:
Especially focus on Navigation Panel perf since it’s an issue that’s been raised a few times
Test performance of notifications
More generally work on preventing the wiki from breaking. XWiki needs to be rock solid and not feel like you’re going to break it when you touch something. It should’t be possible to break anything (either we support it or we disallow it). Examples:
prevent deletion of important pages and spaces,
make it simpler to understand/handle merge conflicts during upgrades,
prevent or make moving applications work
Paying app feature in EM
Less navigation to perform things. For ex, inline editing and generally simplify edition flow.
Visible save (work started in 8.x and needs to be finished)
Skin refresh. No new skin since too much work but refresh of Flamingo
Even though I’ve not followed the development of XWiki during these past few years, I kept using by using some old installations. I understand that to move this old installation to new ones running the newest stable releases won’t be an easy task, and that is perfectly understandable. But I keep thinking that, in general, the upgrade process is too hard to follow.
I would like to promote UPGRADE high on the Top priorities list. In your message, there is only one instance of that word upgrade when you talk about merge conflicts resolution, but I think that it deserves much more attention as the nice page explaining the process available at…
… depicts a hard time for anyone facing the process!
Once again, thank you so much for your work and for making this great toolscape available for the community!
Well, it’s been several years that we’ve worked on improving upgrades. Maybe your experience is from old installs?
I’m all for continuing to improve upgrades since I’m sure there’s more stuff to be done but we need help from you. Could you tell us what issues you’re still getting when upgrading to recent versions of XWiki and what you suggest that we should do?
Right now the hardest thing IMO is to merge default pages that you’d have modified and that are also modified in the distribution (normal since they’re default pages ;)). What we’ve done in 2017 is preventing their deletion and what we’re planning in 2018 is to make it hard/prevent users from modifying them so that there’s never any conflict when upgrading (obviously to the exception of some pages such as the home page which we’ll need to handle differently and make the user content have priority over the default content for example).
Keep the suggestions coming and very importantly with details of what should be done in your opinion.
On my wish list I would like to see a few more page edit macros or widgets to help slicken the editing experience and make keeping a theme on large wikis easier. Don’t get me wrong, it’s already very good, and the CKeditor works nicely, but stuff like mentions (I know someone has already done some work on this), multi image layout, autoimage thumbnails, D3 graph macros.
I plan on tackling this soon on our instance, but thought I would mention it here as it would probably be useful to everyone using XWiki as a wiki, maybe not so much for websites.
I’ve tried hard to do this one several times but it’s very hard to find info about this on the JIRA side. It seems JIRA partially implement the long-deprecated opensocial spec from google and that XWiki would need to implement it too in the same manner for jira gadgets to work in XWiki.
I’ve created Loading... to keep track and continue the discussion. Thanks.