May 2013 - xwiki-devs@xwiki.org

[xwiki-devs] Tools/approaches to manage Xwiki custom project publicly
by Valdis Vītoliņš 09 May '13

09 May '13

I'm working on a project, which potentially could be useful for more than one customer. Therefore I'm thinking how to manage automated updates for Xwiki content (xar file for partial export) and ../webapps/xwiki (additional jar files and differences/replacements for existing files) folder. On the one hand it should provide easy steps for Linux/web admins, which are not very familiar with Xwiki for upgrading their, on the other hand, it shouldn't be too hard to manage for me also. I assume, it could be some (xwiki?) github project though I wonder, what structure should I have there. To not reinvent the wheel, can you describe what tools/approaches you see as the best? E.g. how you manage content for: https://github.com/xwiki/xwiki-enterprise/tree/master/xwiki-enterprise-ui/s… Thanks! Valdis

2 1

[xwiki-devs] [Reminder] BFD #20 today
by Marius Dumitru Florea 09 May '13

09 May '13

Hi everyone, Today is BFD20. Our new goal is now to have more bugs closed than created for the past 1000 days! We're behind by 36 bugs, see: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Let's try to close the gap during this BFD. Here's the BFD#20 dashboard: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11517 Thanks Marius

1 0

[xwiki-devs] [Proposal] Roadmap for XWiki 5.1
by Vincent Massol 08 May '13

08 May '13

Hi devs, Content Proposal ============== Here are some ideas for the XWiki 5.1 roadmap which I have already discussed offline with Thomas D, Thomas M, Marius, Caty, Sorin and Manuel! * Thomas D continues to work on security fixes (especially on reviewing Andreas' branch) * First usable version of SOLR implementation - Thomas M for the back end, Caty for the UI design, Marius for the UI implementation and Sorin/Manuel for ensuring the quality of the new SOLR is at least as good as our current Lucene search so that we could switch to the SOLR version ASAP (would be great to be able to do that at the end of 5.1) * Continue weekly BFDs - All * Then, by order of priority and time permitting: ** Horizontal menu - Marius ** Home Page Improvements - Marius + Caty - Needs to be defined precisely by Caty/Marius and jiras created ** AWM Add the ability to publish an application as an extension - Marius ** XWIKI-8495: Unable to edit a page using the WYGIWYG editor after adding a dashboard macro to it ** XWIKI-7905: Cannot change document title from "inline" mode Let me know if this is ok for everyone, especially for those for whom I've put names next to tasks! :) If other devs want to work on other stuff please mention your itch here. I'll then prepare the roadmap page on xwiki.org and ask all devs to create JIRA issues related to their tasks and reference them from the roadmap page. Date Proposal ============ * 5.1M1: 27 May * 5.1M2: 10 June (one week shorter than usual because we've been late by more than 2 weeks on 5.0 so trying to catch up a bit since we'd like to finish the 5.x cycle at year end if possible) * 5.1RC1: 24 June * 5.1 final: 1st of July This would mean: * 5.2 final: around September (counting holidays) * 5.3 final: November (will need to make it a small release) * 5.4 final: December * 5.5 final: January 2014 WDYT? Thanks -Vincent

5 5

[xwiki-devs] [VOTE] New Link and Image syntax for XWiki Syntax 2.2
by Vincent Massol 08 May '13

08 May '13

Hi devs, Following this thread http://markmail.org/thread/vw3derowozijqalr it seems clear that we need to introduce a better syntax for links and images in XWiki Syntax 2.2 (in order to cope with use cases such as http://jira.xwiki.org/jira/browse/XRENDERING-290) The need is to be able to plug new reference type handlers without breaking backward compatibility in XWiki Syntax 2.2 (since right now with XWiki Syntax 2.0 and 2.1 adding a new type reference handler would break backward compatibility). So here are various proposals to that effect for XWiki Syntax 2.2 (I've only kept the interesting proposals from the previous thread). Please vote for the one you prefer or add new solutions if you have other better ideas. Proposal 1 ========= Force XWiki Syntax 2.2 to *ALWAYS* use the full form when creating a link or image, i.e. all links would need to be written: [[label>>type:reference]] Examples: * [[label>>doc:space.page]] * [[label>>doc:wiki:space.page]] * [[label>>path:/some/path]] * [[label>>url:http://xwiki.org]] * [[label>>user:evalica]] * [[image:doc:wiki:space.page@image.png]] * [[image:icon:someicon.png]] CONS: * Harder to write links to documents which is the main use case Proposal 2 ========= Same as with XWiki Syntax 2.1 but for links or images to subwikis force the user to use the "doc:" notation Examples: * [[label>>space.page]] or [[label>>doc:space.page]] * [[label>>doc:wiki:space.page]] * [[label>>>path:/some/path]] * [[label>>http://xwiki.org]] or [[label>>>url:http://xwiki.org]] * [[label>>user:evalica]] * [[image:doc:wiki:space.page@image.png]] * [[image:icon:someicon.png]] PRO: * Still easy to reference docs and images in the current wiki * Close to current XWiki Syntax 2.1 CONS: * Harder to write links to documents in subwikis (for workspaces users for example, see example of xwiki.org) Proposal 3 ========= Always define the type as a link or image parameter, i.e. separate subwiki notation from type. Examples: * [[label>>space.page]] or [[label>>space.page||type="doc"]] * [[label>>wiki:space.page]] or [[label>>wiki:space.page||type="doc"]] * [[label>>>/some/path||type="path"]] * [[label>>http://xwiki.org]] or [[label>>>http://xwiki.org||type="url"]] * [[label>>evalica||type="user"]] * [[image:wiki:space.page@image.png]] or [[image:wiki:space.page@image.png||type="doc"]] * [[image:someicon.png||type="icon"]] PRO: * Still easy to reference docs * Clear separation between subwiki and types CONS: * Harder to write typed links * Harder to write references in non xwiki/2.x syntax that would not support link parameters Thanks -Vincent

7 22

[xwiki-devs] [ANN] XWiki 5.0.1 released
by Thomas Mortagne 07 May '13

07 May '13

The XWiki development team is proud to announce the availability of XWiki 5.0.1. This is a bugfix release triggered by an important bug (the merge was not taking into account syntax and hidden document fields). 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/ReleaseNotesXWiki501 Thanks -The XWiki dev team

1 0

[xwiki-devs] Need help to upgrade myxwiki.org to 5.0 ASAP
by Vincent Massol 06 May '13

06 May '13

Hi devs, I think we should upgrade myxwiki.org to XWiki 5.0 ASAP. We're supposed to use myxwiki.org as our test bed for latest versions but we're not using it enough. Anyone who some free time/will to help upgrade myxwiki.org to 5.0? Latest upgrades: http://myxwiki.org/xwiki/bin/view/XWiki/UpgradesLog From what I see Marius did an EM/DW upgrade last time so new upgrades should be pretty simple. Thanks -Vincent

2 8

[xwiki-devs] [xmorpho] XWiki Mobile client: repository updated
by Ludovic Dubost 04 May '13

04 May '13

Hi, The mobile client repository has been renamed https://github.com/xwiki-contrib/xwiki-mobile-morpho and now the code of the latest mobile application is in the trunk. The "v2" branch should not be used anymore and will be deleted soon. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

1 0

[xwiki-devs] [Proposal] New URL configuration parameters - Naming choice
by Vincent Massol 03 May '13

03 May '13

Hi devs, I've implemented "XWIKI-3951: Replace oldcore Entity URL parsing by the new URL module" and this means using more the xwiki-platform-url module. It also means replacing the 2 xwiki.cfg properties by new ones located in xwiki.properties. To be replaced: xwiki.virtual.usepath xwiki.virtual.usepath.servletpath New properties: #------------------------------------------------------------------------------------- # URL #------------------------------------------------------------------------------------- #-# IMPORTANT: The URL module is a feature still in development and as such should be considered experimental at the #-# moment. The configuration parameters below are used only in some part of the code at the moment. The idea is to #-# progressively refactor more and more till only the new properties are used. For the moment you should continue to #-# use the following old properties located in xwiki.cfg: #-# xwiki.virtual.usepath #-# xwiki.virtual.usepath.servletpath #-# [Since 5.1M1] #-# The id of the URL format to use. This allows to plug in different implementations and thus allows to completely #-# control the format of XWiki URLs. #-# #-# The default is: # url.format=standard #-# [Since 5.1M1] #-# Defines where the wiki part is defined in a URL pointing to a subwiki #-# If true then the wiki part is located in the URL path (a.k.a path-based), for example: #-# http://server/xwiki/wiki/mywiki/view/Space/Page #-# If false then the wiki part is located in the URL host domain (a.k.a domain-based), for example: #-# http://mywiki.domain/xwiki/bin/view/Space/Page #-# #-# The default is: # url.standard.multiwiki.isPathBased=true #-# [Since 5.1M1] #-# For path-based setups, this property defines the path segment before the one identifying the subwiki in the URL. #-# For example if set to "thewiki", then the following URL will point to a subwiki named "mywiki": #-# http://server/xwiki/thewiki/mywiki/view/Space/Page #-# Note that the mapping in web.xml has to be modified accordingly if you don't use the default value: #-# <servlet-mapping> #-# <servlet-name>action</servlet-name> #-# <url-pattern>/wiki/*</url-pattern> #-# </servlet-mapping> #-# #-# The default is: # url.standard.multiwiki.wikiPathPrefix=wiki We need to decide if we're ok with these new names or if we want something else. Since these are properties used quite often it's important that we agree on the naming. BTW note that I've implemented LegacyStandardURLConfiguration (in xwiki-platform-legacy-url) to fall back to the old xwiki.cfg properties if they are defined. Thomas proposed the following properties instead: url.standard.multiwiki.path.enabled=true|false url.standard.multiwiki.path.prefix=wiki url.standard.multiwiki.domain.enabled=true|false WDYT? Thanks -Vincent

3 3

[xwiki-devs] [ANN] XWiki 5.0 released
by Thomas Mortagne 03 May '13

03 May '13

The XWiki development team is proud to announce the availability of XWiki 5.0. This is the first version of the new development cycle 5. This release comes with virtual mode enabled and uses the new security authorization module for rights checking. It also brings improvements to the Extension Manager, Distribution Wizard and the WYSIWYG editor. 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/ReleaseNotesXWiki50 Thanks -The XWiki dev team

1 0

[xwiki-devs] [Contrib] Encryption Application
by Thomas Delafosse 03 May '13

03 May '13

Hi all, I would like to have a repo on xwiki-contrib on github for a little application I've made that enables admins to directly encrypt passwords in the wiki and to choose who should be able to decrypt them. It can be called encryption-application or something like that. Thanks, Thomas

2 4