xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

by Antoine Roger

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!

10 years, 3 months

[xwiki-devs] [Proposal] Remove some meta tags

by Guillaume "Louis-Marie" Delhumeau

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

10 years, 3 months

[xwiki-devs] improve flamingo menu?

by Pascal BASTIEN

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

10 years, 3 months

[xwiki-devs] [Contrib] [Notice] Renaming 'application-forum2' to 'application-forum'

by Ecaterina Moraru (Valica)

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

10 years, 3 months

[xwiki-devs] [XWiki Day] BFD#65

by Eduard Moraru

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

10 years, 3 months

[xwiki-devs] IE9 and flamingo

by Pascal BASTIEN

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

10 years, 3 months

[xwiki-devs] Fwd: [Discussion] New location of the "Add" menu in the new Flamingo skin

by Guillaume "Louis-Marie" Delhumeau

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

10 years, 3 months

[xwiki-devs] [Discussion] What the "templates" directory should contain?

by Guillaume "Louis-Marie" Delhumeau

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

10 years, 3 months

[xwiki-devs] [Contrib] Request repository for Recruitment Application

by Alexandru Chelariu

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

10 years, 3 months

[xwiki-devs] [Brainstorming] Issue tracking for xwiki-contrib projects

by vincent＠massol.net

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 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs