November 2015 - xwiki-devs@xwiki.org

[xwiki-devs] [VOTE] Stop bundling the Statistics Application by default in XE
by Vincent Massol 08 Jan '16

08 Jan '16

Hi devs, Since statistics are disabled by default, I'm proposing to not bundle the Statistics application by default. Admins who want to enable stats on their would need to install it through the EM. In addition, the Stats app's quality is not exactly perfect either and performances are not that great so I think it makes sense to not promote it too much either. Last, since 5.3M2 the stats app is now visible in the Applications Panel (for Admins), thus not bundling it by default seems even more needed now IMO. WDYT? Thanks -Vincent

9 14

[xwiki-devs] [Idea] Deprecate terminal pages
by Guillaume Lerouge 06 Jan '16

06 Jan '16

Hi Devs, after trying XE 7.4 snapshot some more, I kept asking myself what was the point of even allowing terminal pages to exists. I couldn't see a good reason why any given page would *need* to be terminal, whereas it poses some issues: - There is no visual distinction between terminal pages and nested pages in the interface (besides "WebHome" in the URL, which would be cleaner to remove) - We're planning to make it possible to reference a nested page in wiki syntax without having to write "WebHome" in it - When creating a new page from a terminal page, you're creating a sibling instead of a child page, which breaks the user expectation (and the breadcrumb) - For AWM applications, data/content pages are created as terminal pages, which makes it impossible to add further content underneath them in the future (say, sub-tasks that would go as child pages of tasks) - To my knowledge, there is no easy way to transform a terminal page into a nested page should the need arise later on - However, I don't see any problem from a page being a nested page instead of being a terminal page In summary: why bother with terminal pages at all? I understand they're an artefact from our pre-nested-spaces model, but do they really make sense now? We could let existing terminal pages live on, but not remove the ability to create new ones even for admins. Am I missing something obvious? Thanks, Guillaume

6 18

[xwiki-devs] [Proposal] Adding Blockers systematically to release notes?
by vincent＠massol.net 05 Jan '16

05 Jan '16

Hi devs, I’d like to suggest a new best practice which would consist in systematically adding blockers issues in the release notes corresponding to the affects versions, at the top, using an error macro. For example I’ve updated the release notes for 7.2 and 7.3: - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki72 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki73 The idea would be to update our Release Notes template to automatically list them using this template snippet (example for XWiki 7.2): " {{error}} The following blocking issues were found after this version was released. You should verify if you're using the affected features and if so, you can click on them to see in which version they are fixed): {{jira url="http://jira.xwiki.org" style="list" source="jql"}} category = "Top Level Projects" and affectedVersion in ("7.2-milestone-1", "7.2-milestone-2", "7.2-milestone-3", "7.2-rc-1", "7.2") and fixVersion > "7.2" and priority = Blocker and resolution = Fixed {{/jira}} {{/error}} “ The goal is to make it easy for our end users to see blocking issues in a given release. The goal is also to make it visible to us how many blockers we introduce in each release and work on reducing this number as much as possible. WDYT? Thanks -Vincent

5 14

[xwiki-devs] [ANN] New extension that ease adding properties to the wiki descriptor from velocity
by Denis Gervalle 14 Dec '15

14 Dec '15

Hi devs, I have just released the first version of api-wiki-customproperties, a new extension that provides a scripting API to access and manager generic custom properties in wiki descriptors. You can get quick overview of it from the extension page at http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Custom+Properties… I hope you will find this new API useful for your projects. Please, could someone with enough privileges create a new JIRA project for this extension. Thanks, -- Denis Gervalle SOFTEC sa - CEO

3 3

[xwiki-devs] [Proposal] Remove TinyMCE files from the XWiki WAR
by vincent＠massol.net 14 Dec '15

14 Dec '15

Hi devs, Here’s what I commented on https://github.com/xwiki/xwiki-platform/pull/307 : “ Thanks Pascal. I've just noticed that we still bundle TinyMCE in XWiki's WAR. It was probably left for backward compatibility but since it's been like 6-7 years that we've dropped it, I believe we could vote about dropping it from our sources and if someone really needs it they'll still be able to manually install them in their wikis. I'll follow up on the devs list, thanks. “ WDYT? Are you ok to remove it? Thanks -Vincent

9 17

[xwiki-devs] [Proposal] Put the "Search" icon to the left of the "Watchlist" icon in the top menu
by Guillaume Lerouge 14 Dec '15

14 Dec '15

Hi Devs, a minor suggestion after trying a 7.4 snapshot locally: shouldn't we put the search icon before the watchlist icon? Right now clicking the search icon moves the watchlist icon laterally, which is a bit surprising => if the search icon was leftmost, this would not be a problem. WDYT? Thanks, Guillaume

4 3

[xwiki-devs] [Idea] Rewrite Activity Stream + Stats using Elastic Search
by vincent＠massol.net 14 Dec '15

14 Dec '15

Hi devs, I think that for data that are both not critical and high volume we should use ElasticSearch instead of saving them in our RDBMS. So the idea would be to have an embedded ES in XWiki by default (using the permanent directory to store its data) and admins could configure XWiki to use a separate ES instance (very similar to what we do with SOLR). Whenever a user modifies/creates/deletes/does operations on XObjects/etc, this is sent to ES. The AS UI queries ES to display the data. The Stats UI does the same. Pros: - scalability - performance - extensibility. It’s easy to evolve the schema in ES, and we can easily have several formats (as was proven by the Active Installs code) I’d like to start a POC in my “free” time. WDYT? Thanks -Vincent

7 8

[xwiki-devs] [ANN] XWiki 7.4 Milestone 1 released
by vincent＠massol.net 30 Nov '15

30 Nov '15

The XWiki development team is proud to announce the availability of XWiki 7.4 Milestone 1. This is our last stabilization release for the XWiki 7.x Cycle. It brings polishing and stabilization for the Nested Pages feature and the changes in UI that resulted from it, especially for the Watchlist. 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/ReleaseNotesXWiki74M1 The following people have contributed code to this release (sorted alphabetically): Marius Florea Vincent Massol Ecaterina Moraru Eduard Moraru Thomas Mortagne Clemens Robbenhaar Jean Simard Manuel Smeria Thanks for your support -The XWiki dev team

1 0

Re: [xwiki-devs] [xwiki-users] [Idea] Make Markdown syntax available as an optional subset of the XWiki 2.1 syntax
by Caleb James DeLisle 27 Nov '15

27 Nov '15

The point is not to use someone else's code or even to duplicate the logic to a perfect binary-compatible tee, the point is to be "standard enough" that it's familiar to people who come in from Github, StackOverflow, Slack, Reddit etc. The php-inspired macro idea is another attempt at making it more familiar to people and thus more intuitive. Thanks, Caleb On 27/11/15 16:54, vincent(a)massol.net wrote: > > > > On 27 Nov 2015 at 16:41:34, Paul Libbrecht ([email protected](mailto:[email protected])) wrote: > >> >> >> Caleb James DeLisle wrote: >>> I had just imagined an extension to the markdown standard, not sure >>> exactly >>> how macros ought to be implemented... One possibility: >>> >>>>> $doc.getFullName() >>> ?> >>> >>> or >>> >>> ?> >> Hey, that is very "standard" in the sense of PHP-ish. >> I like it but I am sure it can clash heavily somewhere. >> >> Another proposal is here: >> https://github.com/codingcoop/markdown-macros >> More compact... thus less portable… > > Can you explain why you’re trying to do something that’s already implemented? You don’t like our current implementation? > > Thanks > -Vincent > >> Paul > > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users >

1 0

[xwiki-devs] [Idea] Make Markdown syntax available as an optional subset of the XWiki 2.1 syntax
by Guillaume Lerouge 27 Nov '15

27 Nov '15

Hi Devs, as you probably noticed it, Markdown has recently become somewhat of a reference syntax for many developer tools, most notably GitHub. I have recently discussed with teams using XWiki who are also using GitHub and Slack and who are interested in being able to use Markdown syntax inside XWiki. Although it is already possible to use Markdown syntax in XWiki in a limited way <http://rendering.xwiki.org/xwiki/bin/view/Main/Markdown11>, I don't think that a wiki could really work with only Markdown, due to the following limitations: 1. We have invested a lot in the XWiki rendering and the XWiki 2.1 syntax in order to make them address a lot of use cases and work seamlessly with the WYSIWYG editor 2. Conversely, Markdown syntax is very limited by design <https://daringfireball.net/projects/markdown/syntax> and does not support many of the important features of XWiki syntax, forcing users to rely on HTML for a lot of use cases What's interesting however is that Markdown syntax is very close to XWiki syntax in a number of regards, notably line breaks, bold and lists. Some notable differences include the syntax for links, images and code blocks. My line of thinking is the following: what if we made it possible as an option for users of XWiki 2.1 syntax to have XWiki interpret the main elements of Markdown syntax? In practice, this would mean adding a set of 5-10 additional rules to the rendering engine. The obvious benefit would be to improve adoption of XWiki by dev teams who are already familiar with Markdown. I don't see any obvious drawbacks (besides the need to code and maintain the feature of course), but I clearly don't master all the subtleties of the XWiki rendering engine. Thanks, Guillaume

4 7