October 2018 - xwiki-devs@xwiki.org

[xwiki-devs] Fwd: [xwiki/xwiki-commons] One of your dependencies may have a security vulnerability
by Vincent Massol 16 Oct '18

16 Oct '18

nice… Even though we rolled back this upgrade since it has regressions ;) -Vincent > Begin forwarded message: > > From: GitHub <notifications(a)github.com> > Subject: [xwiki/xwiki-commons] One of your dependencies may have a security vulnerability > Date: 16 October 2018 at 19:02:58 CEST > To: xwiki/xwiki-commons <xwiki-commons(a)noreply.github.com> > Cc: Security alert <security_alert(a)noreply.github.com> > Reply-To: xwiki/xwiki-commons <noreply(a)github.com> > > <https://github.com/> Sign in <https://github.com/login> > vmassol, > We found a potential security vulnerability in a repository for which you have been granted security alert access. > > xwiki/xwiki-commons <https://github.com/xwiki/xwiki-commons> > Known moderate severity security vulnerability detected in org.dom4j:dom4j < 2.1.1 defined in pom.xml <https://github.com/xwiki/xwiki-commons/blob/master/pom.xml>. > pom.xml <https://github.com/xwiki/xwiki-commons/blob/master/pom.xml> update suggested: org.dom4j:dom4j ~> 2.1.1. > Always verify the validity and compatibility of suggestions with your codebase. > Review vulnerable dependency <https://github.com/xwiki/xwiki-commons/network/alert/pom.xml/org.dom4j:dom4…> > > Only users who have been assigned access to security alerts will receive these notifications. > > Unsubscribe <https://github.com/notifications/unsubscribe-vulnerability/AAmWKxhmdIzJDKAX…>· Email preferences <https://github.com/settings/emails> · Terms <https://help.github.com/articles/github-terms-of-service/> · Privacy <https://help.github.com/articles/github-privacy-policy/> · Sign into GitHub <https://github.com/login> > > GitHub, Inc. > 88 Colin P Kelly Jr St. > San Francisco, CA 94107 >

1 1

[xwiki-devs] [ANN] XWiki 10.8.1 released
by Thomas Mortagne 15 Oct '18

15 Oct '18

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

1 0

[xwiki-devs] State of Velocity 2.0 upgrade
by Thomas Mortagne 15 Oct '18

15 Oct '18

Hi devs, Some of you may know that I started working on upgrading our scripting engine to Velocity 2.0. The corresponding Jira issue is https://jira.xwiki.org/browse/XCOMMONS-1296. Those of you who want to take a look at breakages with standard Velocity 2.0 upgrade (if you directly use Velocity API) can take a look at http://velocity.apache.org/engine/2.0/upgrading.html. The following details are about XWiki Velocity "engine": = The code You can see the current state of the upgrade on the following branches: * https://github.com/xwiki/xwiki-commons/tree/feature-velocity2 * https://github.com/xwiki/xwiki-rendering/tree/feature-velocity2 * https://github.com/xwiki/xwiki-platform/tree/feature-velocity2 = Bad news == Definitive (probably) breakages * it was not easy in Velocity 1.7 but it's now impossible in Velocity 2.0 to use the hack we currently use to make macro "return" something. I mitigated this a bit by working on a #setVariable directive (the name of the helper we currently have in macros.vm) but it's not yet working in all situations and any code that was not going trough #setVariable will be broken anyway * the hypen ( - ) cannot be used in variable names anymore Those changes make impossible to upgrade to Velocity 2.0 in 10.x branch IMO, to big to be done in the middle of a cycle. == Temporary (hopefully) breakages * impossible to have $ or # at the end of a " based string literal (we have that a lot in various regex for example). This looks like an unplanned regression (since it's not documented) so I'm waiting for some kind reaction in the issues I reported (https://issues.apache.org/jira/browse/VELOCITY-897 and https://issues.apache.org/jira/browse/VELOCITY-896) == Not too impacting (hopefully) breakages The Velocity API changed quite a lot, fortunately not in classes we expose publicly (basically all we expose is VelocityContext). Also reminder: directly manipulating even XWiki Velocity API is considered legacy things (better use templates or wiki content and ScriptContext). = Good news == Macros handling The way to manage namespaces and macros has been completely changed (it does mean that lots of API has been broken in the process but we don't expose this API) and the good news is the new design will allow us to (finally) do proper caching of velocity scripts. I also removed a few hacks we had to do to not end up with endless memory leaks and milti-thread issues caused by the old namespace handling system. == Less stuff on our side I was able to move the following to legacy: * an equivalent of our chainable uberspector system has been implemented in Velocity standard * a DeprecatedCheckUberspector has been implemented in Velocity standard == Retro compatibility I was able to add * XWiki will keep supporting $velocityCount and $velocityHasNext (with a warning). It imply using XWikiVelocityContext instead of VelocityContext if you create it directly (which is a very bad idea) but you don't need to worry about that if you get your context from VelocityManager * a new #setVariable directive help supporting a few use case of macro "return" but unfortunately not all yet (Velocity AST is not super obvious to navigate...) == Performances Other than the caching on our side I already mentioned (huge boost planned when implemented) there is some memory and performance improvements claims in Velocity 2.0 release note (but I did not had time to do any testing myself yet). = TODO a) waiting for answer about the regressions I reported b) try find a way to make #setVariable directive works in a macro which is itself called in another macro (but it may not be possible) c) send a mail to discuss when to merge the Velocity 2 branch when at least a) is resolved Thanks, -- Thomas Mortagne

1 1

[xwiki-devs] Proposal for Macro inline edition
by Simon Urli 15 Oct '18

15 Oct '18

Hi everyone, I'm working on the roadmap issues related to the inline edition with WYSIWYG editor for macro content and macro parameters. The first step is to add a flag to allow user specify that a content or a parameter can be edited inline with the WYSIWYG editor. The second step is to allow the CKEditor to detect where the content and/or parameters should be edited. Let's take the exampe of a simple macro without any parameter, which currently produces this code: <div class="box infomessage"> <div class="title"> <span class="icon info"></span> some title </div> Some content </div> We propose (me & Marius) to ask users to add a wrapper with a specific class around the content to tell the editor it should only allow editing this content, e.g.: <div class="box infomessage"> <div class="title"> <span class="icon info"></span> some title </div> <span class="editable-content">Some content</span> </div> About parameters, our idea was to define a new metadata attribute and to ask users to use it for specifying the content is editable, such as for a parameter named foo: <span class="editable-content" data-parameter="foo">my foo parameter value</span> However I don't know right now how the editor would manage cases such as: <span class="editable-content">Some content with <span class="editable-content" data-parameter="myparameter">a parameter</span></span> So: 1. Do you agree on the usage of a class named "editable-content" which would be used as a tag to allow inline edition? 2. WDYT about using a data-parameter and this class for inline editing of parameters? Thanks, Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli(a)xwiki.com More about us at http://www.xwiki.com

5 34

[xwiki-devs] [Documentation] Upgrade
by Ecaterina Moraru (Valica) 12 Oct '18

12 Oct '18

Hi devs, Since I didn't understood a lot of things the first time I've read the Update documentation, I've made a proposal on improving the grouping of the content. You can see: - The original https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Upgrade - The proposal https://design.xwiki.org/xwiki/bin/view/Proposal/Upgrade/SimplerUpgrade/Dra… Since the content is highly technical, if you find mistakes or want to add stuff, please just edit them yourself. I've just took the existing content and reorganize it. Let me know what you think about this version and if we can replace the current version with the draft. Thank you, Caty

2 4

[xwiki-devs] [XWiki Day] BFD#192
by Oana-Lavinia Florean 12 Oct '18

12 Oct '18

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

1 1

[xwiki-devs] [Proposal] Deprecate Document#getName()
by Vincent Massol 12 Oct '18

12 Oct '18

Hi devs, I’d like to propose deprecating Document#getName() in favor of Document#getDocumentReference(). The main reason is that it’s misleading since users will use nested pages by default and this method returns “WebHome” all the time in this case. In addition, it doesn’t make sense anymore with nested pages to have access only to the last part of the reference. WDYT? Thanks -Vincent

2 1

[xwiki-devs] [XWiki Day] BFD#191
by Oana-Lavinia Florean 05 Oct '18

05 Oct '18

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

1 1

[xwiki-devs] [Brainstorming] "Code" subspace for apps
by Vincent Massol 01 Oct '18

01 Oct '18

Hi devs, I’ve just had a quick chat with Edy and I found that we had a difference of opinion on the Code subspace practice. On https://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPr… we say: "Technical pages must be put in a subspace named Code” Now Edy says that this should be done only for data-generating apps. It’s not my recollection that this rule was only for this case and this is what I’d like to discuss here. For example, I’ve noticed that ActiveInstalls has all technical pages under ActiveInstalls, see https://github.com/xwiki/xwiki-platform/tree/053f0a2757cea18a5916632a58c604… I would fix it to have only the WebHome remain under ActiveInstalls and move all the technical pages under ActiveInstalls.Code. The only case where it could make sense to not have a Code subspace would be when the app has no UI at all. Even in this case, you might argue that we should always have a home to provide a description about the content of the space. So right now I’m personally in favor of continuing the rule we defined in the best practices: "Technical pages must be put in a subspace named Code” WDYT? Thanks -Vincent

5 6

[xwiki-devs] [Proposal] Turn off redirects in page move/rename
by Vincent Massol 01 Oct '18

01 Oct '18

Hi devs, We see more and more wikis with tons of redirects and issues to manage them, see https://jira.xwiki.org/browse/XWIKI-14570 “ Rationale for turning it off by default: - Several users have reported a usability issue about automatic redirects. The way they express it is the following: "I have duplicates pages in my wiki. I don't understand why this is happening. I'm choosing to rename pages and not to copy them but I still get duplicates in the Navigation panel". - Automatic redirects are especially useful for public wikis where users can have bookmark on pages and you don't want to break them. It can also be useful for internal wikis but it's less an issue. - Even for public wikis not all pages need automatic redirects. Technical pages don't need them for example. “ I’ve had Ludovic report that to me too again this morning. Since we’ve been knowing about the problem for a while already and since it’s very easy to change the default behavior, I’d like to propose that we turn it off by default in XWiki 10.8 (ie right now, or if you think it’s really too dangerous in 10.9), and that we implement an option to configure the default behavior later on (https://jira.xwiki.org/browse/XWIKI-13384) WDYT? Thanks -Vincent

5 9