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

[xwiki-devs] [Contrib] SecureJira Macro
by Antoine Roger 15 Oct '14

15 Oct '14

Hello, I would like to introduce the macro; The securejira macro allow user to get jira task with user authentification. You can manage username/password/jira_url directly from the administration area. Repo name should be: macro-securejira My github account is: 42aroger Thank you!

2 1

[xwiki-devs] [Proposal] Remove some meta tags
by Guillaume "Louis-Marie" Delhumeau 15 Oct '14

15 Oct '14

Hello. Flamingo is still not HTML5 valid, so I am working on it. We actually use some <meta> tags that are become invalid in HTML5. = X-UA-Compatible = <meta http-equiv="X-UA-Compatible" content="IE=edge" /> It forces the Compatibility mode for IE browsers to use the latest rendering mode. We can replace it by adding the X-UA-Compatible in the HTTP headers, but I actually propose to surround this tag like this:  The code is valid (because inside a comment so the validator does not parse it) and it is still usable with IE. = imagetoolbar = <meta http-equiv="imagetoolbar" content="no"/> it disables the toolbar that comes up when you mouse over an image in MSIE. Same, I propose to add a conditional comment:  = Content-Script-Type = <meta http-equiv="Content-Script-Type" content="text/javascript" /> It defines the default scripting language that is used for intrinsic events (e.g. onmouseover attributes). This tag has been deprecated, and there is nothing to replace it. I don't think this tag is very useful because most of the browsers assume that an intrinsic event will be handled by javascript. Actually I did not know this meta tag before today and my inline javascript did always work! So I propose to just remove it. = Distribution = <meta name="distribution" content="GLOBAL" /> (from XWiki.XWikiPreferences) It actually defines either the website should be considered as public or local (see See http://www.metatags.info/meta_name_distribution) I propose to remove it. = reply-to = <meta http-equiv="reply-to" content="" /> (from XWiki.XWikiPreferences) To be useful, the content should not be empty, so the administrator should set it. Moreover, it is very not well-known, and it could be a problem since the spam bots can read it. I propose to remove it. If the administrator wants it, she can put it in the preferences, with the proper value filled. = language = <meta name="language" content="en" /> (from XWiki.XWikiPreferences) It is actually redundant with <html lang="en">. I propose to remove it. What do you think? Thanks, -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

2 4

[xwiki-devs] improve flamingo menu?
by Pascal BASTIEN 13 Oct '14

13 Oct '14

Hello If javascript on browser is disabled or (a javascript function crashed) flamingo menus is not expandable anymore... It is possible to write a expandable/collapsed menu in pure CSS(without javascript) to avoid that. WDYT? Perhaps you already think about that... Menu in pure CSS will generate more problems? Pascal B

5 6

[xwiki-devs] [Contrib] [Notice] Renaming 'application-forum2' to 'application-forum'
by Ecaterina Moraru (Valica) 13 Oct '14

13 Oct '14

Hi, This mail is sent for reference and gardening purposes. The following actions have been made: * https://github.com/xwiki-contrib/application-forum has been deleted ** This repo was created on 6 July 2011 by mpaun, but never released. It contained 2 commits (readme and pom.xml), but nothing beside that. Deleting it in order to preserve xwiki-contrib clean. * https://github.com/xwiki-contrib/application-forum2 has been renamed to the now available https://github.com/xwiki-contrib/application-forum Thanks, Caty

1 0

[xwiki-devs] [XWiki Day] BFD#65
by Eduard Moraru 10 Oct '14

10 Oct '14

Hi devs, Today is BFD#65: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays For the 1 year period we are at 114 bugs behind, we really need to catch up. See: http://jira.xwiki .org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-Resolved-Chart/10470 Here's the BFD#65 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=12692 Thanks and happy bug fixing! -Eduard

2 3

[xwiki-devs] IE9 and flamingo
by Pascal BASTIEN 10 Oct '14

10 Oct '14

Hello, This bug on Xwiki 6.2.1 seem to be still there: XWIKI-10664: "Strange behaviour of the panels layout using the WYSIWYG editor, Flamingo, and IE9" and it is tagged "fixed on 6.2rc1"... http://jira.xwiki.org/browse/XWIKI-10664 I tested with 6.2.1 jetty package on Win7 and IE9. Thanks you. Pascal B

2 1

[xwiki-devs] Fwd: [Discussion] New location of the "Add" menu in the new Flamingo skin
by Guillaume "Louis-Marie" Delhumeau 08 Oct '14

08 Oct '14

Hi. I have done the "test-on-my-wife" thing :) She finds it more intuitive to add a page from the current page, so in the current location, instead of the "black bar that gives the impression of not beeing a part of that page" (that she did not manage to find by herself). I then explained that the buttons inside the page only concern the actions that you can do on that page, meanwhile adding a new page should be put in an other location. She did not like this logic :) Users' logic and developer's logic are not the same. I like the current location too, except that we should propose "create page" before "create wiki". I really would like to have some feedback of normal users, with the 2 proposals. We, as developers, are not good at making things that look simple for other people, so we should not take this decision alone. Thanks, -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 22

[xwiki-devs] [Discussion] What the "templates" directory should contain?
by Guillaume "Louis-Marie" Delhumeau 08 Oct '14

08 Oct '14

Hi. Since 6.2, we have the following issue: http://jira.xwiki.org/browse/XWIKI-11027 "The templates directory has VMs from Colibri". Until now, we used to have all *.vm files in this directory, and nothing in the "colibri" one, because Colibri was the default skin. Now that Flamingo is the default skin, we have to decide what we do with this directory. Should we move all Flamingo's files in that directory? Should we only put the files that Colibri & Flamingo have in common? I have reported a list of problems that these decisions make, on the Jira. Actually, the "templates" directory seems to mean that we should put only "generic" templates. But what does it mean? Most of the files depends on the skin, so they are not generic. Except some files for the Distribution Wizard that should not be skin-dependent. What do you think about it? Thanks, -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

4 11

[xwiki-devs] [Contrib] Request repository for Recruitment Application
by Alexandru Chelariu 08 Oct '14

08 Oct '14

Hello, I would like to request a repository on xwiki-contrib for the Recruitment Application i am working on. I'd like the repo to be named application-recruitment and also jira component. My github username is chalx. Thank you, Alexandru Chelariu

4 3

[xwiki-devs] [Brainstorming] Issue tracking for xwiki-contrib projects
by vincent＠massol.net 07 Oct '14

07 Oct '14

Hi everyone, ATM the rule we have for contrib projects is to use JIRA (see http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HHostingtools) I’ve heard that some people have been proposing using other trackers. So I’d like to poll your opinion on the following alternatives: Option A: all projects use JIRA =============================== This is the current option in use. Pros: * A single place for people to view and search for issues in the XWiki Ecosystem Cons: * For XWiki admins, creating a new JIRA project takes 5 minutes Option B: all projects use GitHub issues ======================================== Pros: * Simple to set up for admins (hosted by GitHub) * Simple to use (too simple sometimes?) Cons: * No single place to search all issues related to XWiki (both JIRA + GitHub) * No single place to report JIRA issues * Tied to the SCM choice. When we stop using Git as our SCM and move to the next SCM tool we’ll have to import all issues (see https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-i…) * Need to implement feature on extensions.xwiki.org to add a link to the issue tracker for each extension Option C: let each project decide ================================= Pros: * Simple to set up for admins when project decides on GitHub Cons: * No single place to search all issues related to XWiki (both JIRA + GitHub) * No single place to report JIRA issues * Tied to the SCM choice. When we stop using Git as our SCM and move to the next SCM tool we’ll have to import all issues (see https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-i…) * Need to implement feature on extensions.xwiki.org to add a link to the issue tracker for each extension Option D: XWiki Task Manager ============================ http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Applicati… Pros: * Eat our own dog food. * Forces us to improve this extension Cons: * Pressure to fix bugs * Increases volume of data on xwiki.org and thus impact performances * Maintenance cost: More work when upgrading xwiki.org * No single place to search all issues related to XWiki (both JIRA + GitHub) * No single place to report JIRA issues * Need to implement feature on extensions.xwiki.org to add a link to the issue tracker for each extension WDYT? Other options? Personally and based on all pros/cons I think the best ATM is really Option A. And if we really want, it’s possible to improve the cons by doing a bit of java coding: https://developer.atlassian.com/display/JIRADEV/Creating+a+Project+Template Thanks -Vincent

10 27