February 2016 - xwiki-devs@xwiki.org

[xwiki-devs] [Proposal] [XWiki.org] Download page layout
by Ecaterina Moraru (Valica) 14 Mar '16

14 Mar '16

Hi, This proposal wants to improve the current download page layout found at http://enterprise.xwiki.org/xwiki/bin/view/Main/Download <http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationStandalone> The proposal is here: http://design.xwiki.org/xwiki/bin/view/Proposal/XWikiOrgDownload2Layout <http://design.xwiki.org/xwiki/bin/view/Proposal/XWikiOrgInstallationLocal> The proposal splits the current information into multiple pages (version, type). Make sure you read the "Changes" section from the proposal. Let me know what you think. Thanks, Caty

4 9

[xwiki-devs] How to show page edit history across all the translated pages
by Vishal Erande 07 Mar '16

07 Mar '16

Suppose, I have one page with two language translations, e.g. English and Hindi. When someone edits English version, the history of its Marathi version page should also show those edits. How can I do that?

2 1

[xwiki-devs] [Proposal] Extension Points needed in 8.x
by Ecaterina Moraru (Valica) 07 Mar '16

07 Mar '16

Hi, In the past releases (7.3, 7.4) we added more extensions points related to menus. These are good steps towards making XWiki even more easier to customize, still we could add more extension points and mechanisms. With the help from Anca, I've created this page in order to detail some needs: http://design.xwiki.org/xwiki/bin/view/Proposal/UIXP8x - Order: should be handled by all extension points - Aliases - Disabling mechanism - UIXP: -- Content Menu -- Content Title (after) -- Content Footer -- Page Docextra -- Page Footer (before) - other??? Feel free to discuss about them in their dedicated issues or use this thread to add more ideas of needed extensions points. Thanks, Caty

2 1

[xwiki-devs] [Proposal] README.md Template for xwiki-contrib extensions
by vincent＠massol.net 07 Mar '16

07 Mar '16

Hi devs, I’d like to propose that we standardize on the following Template for README.md for all extensions on xwiki-contrib and that we start modifying all repos to use it: —— start here ————— # <Pretty name of Extension, e.g. Flash Messages Application> <Short Description of Extension, taken from the description element in the pom.xml> * Project Lead: <info taken from the jira project, e.g. Vincent Massol> * Extension Page(s): <urls on e.x.o, e.g. http://extensions.xwiki.org/xwiki/bin/view/Extension/Flash+messages+applica…> * Issue Tracker: <url on jira.xwiki.org, e.g. http://jira.xwiki.org/browse/XAFLASHM> * License: <license,taken from the pom.xml, e.g. LGPL 2.1>. * Development Practices: <either a sub list listing all practices or a URL pointing to a site defining the list of practices to be followed by contributors when contributing on this project> * Minimal XWiki version supported: <taken from the pom.xml, e.g. XWiki 6.4.7> ## Others (<use N/A when not used>) * Continuous Integration Status: [![Build Status](http://ci.xwiki.org/buildStatus/icon?job=<url-encoded job name on ci.xwiki.org>)](http://ci.xwiki.org/job/<url-encoded job name on ci.xwiki.org>/) * Sonar Dashboard: <url to the project’s dashboard on sonar.xwiki.org, e.g. http://sonar.xwiki.org/dashboard/index/10464> —— stop here ————--- Example: https://github.com/xwiki-contrib/application-antispam/tree/master WDYT? Thanks -Vincent

7 24

[xwiki-devs] [VOTE] Synchronize the context wiki with the context document (1-way)
by Eduard Moraru 04 Mar '16

04 Mar '16

Hi devs, I`ve noticed that we have an issue in our context API that allows setting the context wiki and the context document independently, thus creating (by design) a desynchronization between the 2. The downside is that you can set the context document to something from a different wiki while the context wiki will not be updated and still report the old wiki. Any system/component that relies on the current context wiki will not behave as expected since it will work with the outdated wiki instead of using the newly set context document's wiki. Please see http://jira.xwiki.org/browse/XWIKI-13138 for more details, but what I am proposing here is to make the first step in that direction and ensure that at least the context wiki is updated when the context document is updated (what I call 1-way sync) to avoid problems. Here's my +1. Also, Thomas has already expressed his concerns that this might be a risky change to introduce in 7.4.x, so it will only be pushed on the 8.x (master) branch and for 7.4.x we`ll just set the context wiki in the right places to fix the translations issue. Thanks, Eduard P.S.: I will push this change in master ASAP and, should there be any -1, revert it.

2 2

[xwiki-devs] [Proposal] Releasing a contrib project - Guidelines
by vincent＠massol.net 03 Mar '16

03 Mar '16

Hi devs, I’d like to propose to add some guidelines to contrib.xwiki.org when someone wants to release a project, especially when that person is not the project lead. * The person wanting to do the release should contact the project lead, preferable either through IRC or the mailing list to mention its intent to perform a new release. ** This allows anyone who also want to have some issue fixed be able to do so in the same release for example. ** Usually that person will not have the permission to create a version in JIRA for that project and thus he/she’ll need the Project Lead’s help for that WDYT? Thanks -Vincent

4 11

[xwiki-devs] [Proposal] Behaviour change when restoring a document regarding its history
by vincent＠massol.net 03 Mar '16

03 Mar '16

Hi devs, I’ve just realized (thanks to a failing functional test) that we’ve changed the behavior we had when we restore a deleted document. We used to add a revision with a comment text of "Restored from recycle bin”. After https://jira.xwiki.org/browse/XWIKI-9960, there’s no new revision created when restoring a deleted document. We need to decide if that’s what we want. Apart from the fact that it’s a minor backward-compatibility breakage (for tools/scripts expecting that revision), the only downside I can see is that by looking at a document history you won’t be able to get the full list of what happened to this doc, i.e. that such user has restored the document. WDYT? Personally I think this could be acceptable but I’m not sure. Thanks -Vincent

4 7

[xwiki-devs] Proposal: Mouseflow on xwiki.org
by Benjamin Lanciaux 02 Mar '16

02 Mar '16

Hello XWiki community, I’m Benjamin, in charge of Marketing at XWiki SAS. I have a suggestion for xwiki.org. We are currently using Mouseflow on xwiki.com. This tool allows us to track and record sessions on the website. This is interesting in various aspects. First, we know more about the behavior of our website visitors. This helps us to better understand what are the paths they are using to access various contents and documents. This tools generates heatmaps for: - click, - movement, - scroll, - attention etc. You’ll get more info here > https://mouseflow.com/tour/session-playback/ At XWiki SAS, we have currently 1 licence for 3 websites. So I propose to install it on xwiki.org. I’m planning to record 1 session out of 2. If nobody is against this idea, I’ll share after one month some results with you. I will also propose some ideas to improve the path to download sections, but also to service providers and to the documentation. I’m looking forward to your feedback on this, Thanks, Benjamin -- <http://xwiki.com> *Benjamin Lanciaux* *Marketing Communications Manager* benjamin.lanciaux(a)xwiki.com tel: +33 (0)1 45 42 40 90 skype: benjaminxwiki

5 6

[xwiki-devs] [VOTE] Agree that we allow ourselves to add new Link Types
by vincent＠massol.net 01 Mar '16

01 Mar '16

Hi devs, During the discussions regarding http://jira.xwiki.org/browse/XRENDERING-290 ("Add support for linking to a user profile page in XWiki Syntax”) we hesitated adding a new link type named “user:” because that would have broken backward compatibility for users having a wiki named “user”. See http://xwiki.markmail.org/thread/vw3derowozijqalr and the ensuing http://markmail.org/message/t2wb2xq7534qsshg Now time has passed and we’ve just added the support for the “space” prefix for wiki links, as in e.g. [[space:Space1.space]]. FYI, we’ve added the following in the release notes: “ We've introduced the possibility to explicitly create a link to a Space in XWiki Syntax 2.1, e.g. [[space:Space1.Space2]]. However if you had a subwiki named space the new notation will conflict with the syntax for referencing that wiki. Thus you'll need to edit existing links such as [[space:something]] to [[doc:space:something]]. And if you wish to reference a given space in the space subwiki, you'd write [[space:space:something]]. “ The rationale is that the resource reference syntax is not really tied to the wiki syntax and we’re not going to increment the wiki syntax version each time we add a new type of resource. So with this VOTE I’d like to ensure that we’re ok to allow ourselves to continue adding new resource reference types. For example we could add “user:” in the future without having to go through a VOTE again. Whenever we do this, we would just need to mention it in the release notes. Of course we shouldn’t add a prefix named “xwiki” ;) Please cast your vote. Here’s my +1 Thanks -Vincent

7 6

[xwiki-devs] Should we move to XML 1.1 in XAR ?
by Thomas Mortagne 01 Mar '16

01 Mar '16

As recommended by W3C we are manipulating XML 1.0 in XAR format but what I did not know is that XML 1.0 does not support all possible characters (I tough at worst it would simply be encoded as a UTF8 entity but seems not) and we just got a report of Woodstox failing because of some character it cannot write in XML 1.0 (""Invalid white space character (0x1) in text to output (in xml 1.1, could output as a character entity)"). So I'm wondering if we should move to XML 1.1. It's critical IMO that we are able to export anything that can be stored in XWikiDocument and in the database and it's the case here. In theory this is most probably a breakage for people using a XML 1.0 parser but not sure how breaking it is in practice. WDYT ? I'm +1 for this but I won't apply it until I get more point of view (ideally from people having more experience that me on XML 1.0 vs 1.1). -- Thomas Mortagne

4 5