- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [Contrib][Ratings] Release a bugfix version of the ratings application from the contrib project
by Anca Luca 13 Jul '16

13 Jul '16

Hello all, while using the ratings application on an XWiki 6.2.4, we encountered some bugs related to the storage of ratings in a separate space and with the update of a user's rating. We fixed them in these 2 commits: https://github.com/xwiki-contrib/application-ratings/commit/07758a698d400ed… and https://github.com/xwiki-contrib/application-ratings/commit/cd2c190e22f709e… . Now, the contrib ratings application was indeed "retired" so we normally should not use the contrib repo anymore. However, the work in these 2 commits is about fixing bugs (which might even be affecting the most recent version of ratings - we need to check that, didn't check it yet), and I don't see exactly what other option we have in this case (note that we cannot switch to the "platform ratings" as we're on XWiki 6.2.4 and ratings are in platform since 6.4. So, this is what I propose: * release a 1.3.5 version from the contrib code - if I understand correctly how extensions.xwiki.org works, this release will not appear as "most recent" on the application page - if I understand correctly how maven works, this version will not be considered more recent than 8.1 even if released after, because of the version number. * this means that the version 1.3.5 will be available as an upgrade to the users that use the contrib extension (v 1.3.4 or lower), will be available for new install to all users for which the dependencies requirements are satisfied and will not impact the users which use the platform version of the ratings app. Please let me know if I'm wrong in my reasoning. The advantage of this release would be publishing the bugfix work that we've done and making it available to all users of the ratings extension on versions lower than 6.4. Also, for us the advantage would be not having to deal with a code fork and manage a release / snapshot of this forked code separately. Unless somebody -1s this in the very close feature, we will go ahead with the release. Thanks, Anca P.S. There is a larger discussion to have about how to provide bugfixes on older versions of platform applications without upgrading all the wiki, but this should be in another mail or on IRC (e.g. if we discover that indeed these issues affect ratings app, the platform version, and we make fixes for these bugs, how can we provide these fixes to an XWiki 6.4 user?)

4 4

[xwiki-devs] [ANN] XWiki 8.2 Release Candidate 1 Released
by Marius Dumitru Florea 13 Jul '16

13 Jul '16

The XWiki development team is proud to announce the availability of XWiki 8.2 Release Candidate 1. This release integrates CKEditor as the default WYSIWYG content editor and adds a *tour* on the home page to describe the XWiki user interface to newcomers. 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/ReleaseNotesXWiki82RC1 The following people have contributed code to this release (sorted alphabetically): Alexandru Cotiuga Anca Luca Ecaterina Moraru (Valica) Eduard Moraru Guillaume Delhumeau Marius Dumitru Florea Raluca Stavro Thomas Mortagne Vincent Massol Thanks for your support -The XWiki dev team

1 0

[xwiki-devs] [Blog] New Frequently Asked Questions
by Eduard Moraru 12 Jul '16

12 Jul '16

Hi, I`ve just shared on the xwiki.org blog, the (relatively) recent addition of 4 new and useful FAQ entries: http://www.xwiki.org/xwiki/bin/view/Blog/New+Frequently+Asked+Questions Thanks for Vlad and Iulia for adding them! If you have anything XWiki-related that you would like to share on xwiki.org's blog, please see my mail on how you can easily do that: http://xwiki.markmail.org/thread/r4r4celltmdprqia Thanks, Eduard

1 0

[xwiki-devs] How list objects?
by Julio Brum 11 Jul '16

11 Jul '16

Hi, I need to list events that were inserted through the MoccaCalendar application. I need to get the title, the way, the start date and the end date of the event. I need to get only the future events (> = today) and a maximum of 10 events. Unfortunately I could not do, so I ask your help. I could only do just that: #set($results = $xwiki.search("select doc.title, doc.web, doc.fullName from XWikiDocument doc where doc.space = 'MoccaCalendar. Mycalendar' and doc.fullName != 'MoccaCalendar. Mycalendar.WebHome' ")) #foreach ($item in $results) [[$item.get(0)>>doc:$item.get(2)]] #end Thank you in advance, Best Regards, Julio

1 0

[xwiki-devs] [NOTICE] Tomcat versions that are not working anymore with XWiki
by Vincent Massol 11 Jul '16

11 Jul '16

Hi everyone, The Tomcat project has brought a change in the way they handle RequestDispatcher (see https://bz.apache.org/bugzilla/show_bug.cgi?id=59317) which is causing regressions. Thus for the moment you should **not** use the following Tomcat versions: • 9.0.x for 9.0.0.M5 onwards • 8.5.x for 8.5.1 onwards • 8.0.x for 8.0.34 onwards • 7.0.x for 7.0.70 onwards (See also http://jira.xwiki.org/browse/XWIKI-13556 for more details) I’ve also added a warning on: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationTomcat Thanks -Vincent

1 0

[xwiki-devs] [Brainstorming] Alternative to Rendering Transformations
by Vincent Massol 07 Jul '16

07 Jul '16

Hi devs, Rendering Tx are great to modify an XDOM into another XDOM. However they have a limitation: they’re slow (since you have to traverse the whole AST). So if you have 10 Tx, you traverse the AST 10 times… I’d like to brainstorm about an alternative: the ability to register some Listener that will get executed at render time and that will transform the events. Use cases ======== Here are some example of Tx that would benefit being rewritten using this mechanism: * Icon Tx * Auto linking of JIRA id to jira issues * WikiWord Tx Implementation ============= It could be something like: * Introduce a ConfigurableBlockRenderer interface with a addListener() method * Modify AbstractBlockRenderer to execute those Listeners before it calls its PrintRenderer. This can be achieved with a composite listener that wraps the listeners added and the PrintRenderer. * Have a way to register some Listeners in the configuration, that should be executed when a page is rendered * Modify XWikiDocument so that those configured listeners are executed when rendering a page Differences between Tx and Listeners ============================== * Tx are slow but easy to write since you have access to the whole AST * Listeners are harder to write since you need to store the events if you need to remember them (but we have developed some tools already over the years such as the LookaheadListener) * Listeners depend on their order and they should be written carefully to minimize their interdependencies * Listener will get executed only at render time so you need to render to get the modifications to the tree, while Tx are independent of rendering. WDYT? Do you see a better way to achieve the same goal (ie removing the Tx performance limitation)? Thanks -Vincent

3 7

[xwiki-devs] [XWiki Day] BFD#110
by Alexandru Cotiuga 07 Jul '16

07 Jul '16

Hi devs, Today is BFD#110: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 109 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#110 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13622 Happy Bug Fixing Day! Thanks, Alex

1 0

[xwiki-devs] [Contrib] Request repository for "application-script-runner"
by Paul Pantiru 06 Jul '16

06 Jul '16

Hello devs, I would like a repository on xwiki-contrib for an application I'd like to call "Derzelas Script Runner". Name: application-script-runner Description: An application that simplifies running scripts on large number of documents from one or more wikis. State: It has not yet been released on e.x.o. but will be done asap. Tools needed: Github repository and Jira project. Username: ppantiru Thanks, Paul Pantiru

2 2

[xwiki-devs] [Brainstorming] Changing the Mail configuration algorithm?
by Vincent Massol 06 Jul '16

06 Jul '16

Hi devs, I’m working on http://jira.xwiki.org/browse/XWIKI-13546 ("Error in the log when sending a mail through the Mail API”). One way to fix it would to always look for the Mail.Config page in the main wiki instead of in the current wiki. Actually the current algorithm is the following when looking up a mail configuration property: * <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in the xwiki properties file</li> * </ul> We also need to implement http://jira.xwiki.org/browse/XWIKI-12435 (“Use the Main Wiki Mail Configuration if not overridden at the subwiki level”): “ Right now when sending a mail in a subwiki, the configuration is taken from that subwiki's Mail.MailConfig document. In a non-farm use case, it's a pain to have to configure SMTP settings for each subwiki. It would be better to look into the main wiki's mail configuration when there's no overridden config at the subwiki's level. " So I can see 2 options. Option 1: Drop support for looking for configuration in subwikis ======== * Rationale: there are few use cases that require overriding the mail config in a subwiki * Potential issue: if we stop looking for *.XWikiPreferences or for <current wiki>:Mail.Config then we won’t migrate configurations but always use the config from the main wiki. So backward compat is theoretically broken. * But it’s likely that the config in subwikis is the same as the config from the main wiki anyway. It’s also likely that if a subwikis smtp server is configured, then the main wiki is also configured. So it could be acceptable with a message in the Release Notes. Option 2: Continue supporting overriding in subwikis ======== * Stop bundling Mail.Config for subwikis and modify the config algorithm to be: * <ul> * <li>Look in Mail.MailConfig in the current wiki</li> * <li>[Backward compatibility] Look in (current space).XWikiPreferences in the current wiki</li> * <li>[Backward compatibility] Look in XWiki.XWikiPreferences in the current wiki</li> * <li>Look in Mail.MailConfig in the main wiki</li> * <li>Look in the xwiki properties file</li> * </ul> I’ve discussed it quickly with Denis who prefers option 1 since he even sees the ability to configure the smtp server at the wiki level a potential issue (bypassing the farm admin). Personally I’m hesitating and I’d hate to remove the local override and then find some use cases where we need it. WDYT? Thanks -Vincent

3 10

[xwiki-devs] [xwiki-users] [ANN] Tour Application v1.0.2 Released
by Alexandru Cotiuga 05 Jul '16

05 Jul '16

Hello all, A new version of the Tour Application extension is available. This is a bugfix version. See http://extensions.xwiki.org/xwiki/bin/view/Extension/Tour+Application#Hv1.0…. You can install or upgrade with the Extension Manager. Thanks, Alex

1 0