February 2019 - xwiki-devs@xwiki.org

[xwiki-devs] [ANN] XWiki 10.11.3 released
by Simon Urli 27 Feb '19

27 Feb '19

The XWiki development team is proud to announce the availability of XWiki 10.11.3. This is a bugfix release that covers important issues that we have discovered since 10.11.2 has been released. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.11.3 Thanks for your support -The XWiki dev team

3 4

[xwiki-devs] [UX][Proposal] Notifications UI 11.x
by Ecaterina Moraru (Valica) 27 Feb '19

27 Feb '19

Hi devs, http://jira.xwiki.org/browse/XWIKI-16119 wants to make the Notifications / Activity Stream look nicer. I've made a proposal at https://design.xwiki.org/xwiki/bin/view/Proposal/Notifications11x/ Let me know what you think. Thanks, Caty

3 4

[xwiki-devs] [Proposal] Introduce a new table BackLinks for solving issues on wiki farms
by Simon Urli 26 Feb '19

26 Feb '19

Hi everyone, we currently have some issues when performing refactoring operations on pages that are linked from another wiki page. See: https://jira.xwiki.org/browse/XWIKI-8346 The current implementation of the links is to keep the local name of the current document and to create a reference containing the name of the wiki for the target document, only if it's a document from another wiki. So basically if I have a wiki:A pointing to subwiki:B, I will get a link stored in DB of "wiki", containing: - fullName: A - link: subwiki:B This forces us to currently iterate over all wikis, when we refactor a page to edit all the links on the farm. That's why we currently have an option which is disabled by default: i.e. we don't update backlinks on a farm by default. In order to allow such operation with less performance issues, I propose to add a new table dedicated to store the backlinks: basically this table would store the reversed information as Links, in the target DB. If I take back my example, the table backlinks of "wiki" would be empty, and I get in the table backlinks of "subwiki", the following information: - fullName: B - backlink: wiki:A Then we could load all backlinks of a document just by looking in one table. The impact on performance would be the necessity to update links in two tables when performing a save, but we can mitigate this by first loading the links so we only update what needs to be (currently we delete and recreate all links, each time...). IMO it would really ease the understanding of links and backlinks, solve the issues on farm and help us to maintain this code. + it doesn't break any legacy since we keep the existing Link table. WDYT? Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

3 4

[xwiki-devs] [Proposal] Changes to remove Dashboard, Crypto, Macros, Rendering entries in the Navigation Panels
by Vincent Massol 26 Feb '19

26 Feb '19

Hi devs, On a standard XS, if you show hidden document you see some entries that you shouldn’t see and that should be hidden. See screenshot. Another problem is that clicking on the Dashboard, Crypto, Macros, Rendering links lead to non-existing pages. I’m this proposing to: 1) Introduce a xwiki-platform-crypto-ui modules with a single Crypto.Webhome page and some one liner explaining what this space is about. 2) Introduce a xwiki-platform-rendering-wikimacro-ui module with a single Macros.WebHome page and some one liner explaining what this space is about. It makes sense to have it under xwiki-platform-rendering-wikimacro since it’s about providing a location for wiki macros. 3) Add a Rendering.WebHome page inside xwiki-platform-rendering-ui to explain what this space is about. The module is there and it’s just missing this page. BTW an alternative is to modify the Navigation panel algorithm to exclude spaces not having a top level WebHome page too. @Marius: any reason we’re not doing this already? By default the Navigation panel hides top level pages that are not meant to be modified so this will remove Crypto, Macros & Rendering. 4) For Dashboard it’s a bit more complex. Ideally we would refactor Dashboard.WebHome to include a new Dashboard.WikiDashboard page that would contain the current content of Dashboard.WebHome. Thus the home page would appear as not modifiable and not appear in the Navigation panel. However, since users can have modified Dashboard.WebHome, this would cause an upgrade merge conflict. Thus, instead, I propose to do what we do for the Sandbox page and instead add Dashboard to the Exclude list of the Navigation panel. WDYT? Note: I’m going to do 4) right now since it’s a no-brainer. Longer term ========= This is *not* part of the proposal but we need to start a thread again about this and start doing something about it: Right now we have apps/extensions creating pages under the top level root. I don’t think this is good at all and we should reserve the top level root for user content. It would be much better to have a place under “XWiki”, such as “XWiki.Extensions.<extension name>.<sub spaces>.<pages>” where each extension could put its content. We already started discussing this. The past thread(s) needs to be unearthed and the discussion resumed. Thanks -Vincent

2 1

[xwiki-devs] [ANN] XWiki 11.1 released
by Guillaume Delhumeau 25 Feb '19

25 Feb '19

The XWiki development team is proud to announce the availability of XWiki 11.1. This release adds support for renaming apps created with App Within Minutes and brings improvements to the WYSIWYG editor: inline editing of the Box Macro title and macro category count displayed by the Macro Selector. Advanced users can now copy the page reference from the Information tab at the bottom of each page. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.1/ Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [Proposal] Disallow / and \ in page names by default
by Vincent Massol 23 Feb '19

23 Feb '19

Hi devs, Because of tomcat and because tomcat is by far the most used container for xwiki and because we also bundle tomcat in the debian and docker dsitributions, I think we should disallow / and \ in page names by default. It's causing too much trouble for users. We keep having users posting problems and for one user who post a problem there are 100 who don't. The latest one: https://forum.xwiki.org/t/please-help-broken-link-routing-cannot-open-page-… Implementation idea: * Offer an extension point in the create page UI to allow plugging some cleaning algorithm * Provide the \ and / cleaning algorithm by default * Handle backward compat. Find ways to not break existing users who are having / and \ in page names. For example we could imagine a property in xwiki.properties that we would set to point to the hint of the / and \ cleaner component. Thus existing users would need to voluntarily upgrade their xwiki.properties to have it if they want it. We would need to provide some script to convert existing pages with / and \ too probably. WDYT? Thanks -Vincent

2 5

[xwiki-devs] [XWiki Day] BFD#208
by Oana-Lavinia Florean 22 Feb '19

22 Feb '19

Hello devs, This Thursday is BFD#208: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingday Our current status is: * -22 bugs over 120 days (4 months), i.e. we need to close 22 bugs to have created bugs == closed bugs * -148 bugs over 365 days (1 year) * -145 bugs over 500 days (between 1 and 2 years) * -340 bugs over 1600 days (4.3 years) See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Here's the BFD#208 dashboard to follow the progress during the day: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14400 Good luck at fixing bugs, Lavinia

1 1

[xwiki-devs] [ANN] XWiki 11.1 RC1 released
by Marius Dumitru Florea 19 Feb '19

19 Feb '19

The XWiki development team is proud to announce the availability of XWiki 11.1 RC1. This release adds support for renaming apps created with App Within Minutes and brings improvements to the WYSIWYG editor: inline editing of the Box Macro title and macro category count displayed by the Macro Selector. Advanced users can now copy the page reference from the Information tab at the bottom of each page. You can download it here: https://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.1RC1/ Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [contrib] Page Preview Popover extension request
by Stéphane Laurière 19 Feb '19

19 Feb '19

Hi all, I would like to contribute an extension that will display page preview popovers when hovering wiki links, similarly to what MediaWiki offers: https://www.mediawiki.org/wiki/Page_Previews https://blog.wikimedia.org/2018/05/09/page-previews-documentation/ Its name could be 'application-page-preview-popover' - what do you think? As discussed with Caty yesterday, the extension will use the Bootstrap popovers. Should you have any need or suggestion, please let me know. If the name is ok, can I ask you for the creation of a repository and JIRA project? Stéphane -- Stéphane Laurière XWiki www.xwiki.com @slauriere

6 10

[xwiki-devs] [Proposal] XS 10.2 and 10.3 roadmaps - Bug fix releases
by Vincent Massol 19 Feb '19

19 Feb '19

Hi devs, We have already started defining the roadmap for XS 10.2, see https://www.xwiki.org/xwiki/bin/view/Roadmaps/#HXWiki11.2 However, it’s come to my realization that we’re having a lot of stability issue on XS these days. I see plenty of users messages on the forum about users failing to use XWiki or to upgrade XWiki and having problems in general. I have the feeling that our quality has regressed. If we check our number of bugs created vs number of bugs closed for 2018, we can clearly see that we’re loosing the battle since Feb/March 2018, see: https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352#Created-vs-… Since Feb/March we’re at 820 vs 963 which means we have a relative difference of 143 bugs. Note that the BFD sessions are not enough and they don’t close a lot of bugs anymore (this can be seen on https://www.xwiki.org/xwiki/bin/view/Blog/XWiki%20Days) I believe that XWiki’s stability and reducing user frustration for installation/upgrades is a key aspect and it’s one of the biggest possible contributor to Active Installs. Thus I’m proposing to devote 2 releases (i.e. 2 months) to focus on bug fixing and thus on XWiki stability, namely * XS 10.2 * XS 10.3 Note that this is something that I’ve already discussed with committers from XWiki SAS. Please voice your opinion if you disagree (or even if you agree, always good to get confirmation we’re going in the right direction ;)). Thanks -Vincent

2 3