xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

by Guillaume "Louis-Marie" Delhumeau

The XWiki development team is proud to announce the availability of XWiki 6.2.7. This is a stabilization release that fixes important bugs discovered in the 6.2.6 version. You can download it here: http://forge.ow2.org/project/showfiles.php?group_id=170 Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki627 Thanks -The XWiki dev team

9 years, 10 months

[xwiki-devs] [ANN] XWiki 6.4.2 released

by Guillaume "Louis-Marie" Delhumeau

The XWiki development team is proud to announce the availability of XWiki 6.4.2. This is a stabilization release that fixes important bugs discovered in the 6.4.1 version. 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/ReleaseNotesXWiki642 Thanks -The XWiki dev team -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

9 years, 10 months

[xwiki-devs] [Proposal] Adding a setting in the skins to select the rendering syntax

by Guillaume "Louis-Marie" Delhumeau

Hi. Problem: in XWiki, we have currently 2 main skins, Colibri (to be deprecated) and Flamingo, that did not share the same doctype. Colibri templates are using the XHTML 1.0 syntax, meanwhile Flamingo uses the HTML 5 syntax. Currently, we have hard-coded in a lot of places the fact that we use XHTML 1.0 syntax, but I would like to replace this by a new setting, skin-dependant, to select the rendering syntax we want. It would enable us to generate valid code (with the HTML cleaner, among other things) for each skin we support. This setting will be located in the XWiki.XWikiSkins objects, and in the skin.properties file for file system skins. Of course we also need to add a new API to get the current rendering syntax. The alternative is to create a global setting or constant to set the rendering syntax for the whole XWiki instance. Some discussions about this there: http://jira.xwiki.org/browse/XWIKI-11602 Here is my +1, Thanks, -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

9 years, 10 months

[xwiki-devs] [Proposal] A new mechanism to overwrite a skin file

by Guillaume "Louis-Marie" Delhumeau

Hello. This proposal is about the following issue: http://jira.xwiki.org/browse/XWIKI-11803. Currently, our mechanism to overwrite a skin file in the wiki has some problems: 1 - we need to add a property in the XWiki.XWikiSkins class for every file that we want to overwrite. It is not clean to change a system class just to use a feature. Moreover, all the existing skins are polluted with any new property added to the class, even if the skin does not need it. 2 - we cannot overwrite a file placed in a subdirectory (like "less/style.less.vm") since we cannot have the "/" character in a property name. This blocks http://jira.xwiki.org/browse/XWIKI-11394. To avoid the problem 1, people usually attach their overwriting files to the skin documents. But it causes some other problems: it is not the wiki spirit to edit a file locally and then to upload it. It would be far better to edit the code directly in a textarea. To fix these 2 problems, I propose a new mechanism, that Eddy have described previously [1]: * we create a new XClass called XWiki.XWikiSkinFileOverride. * this class would contain 2 properties: ** a path (eg: htmlheaders.vm, less/buttons.less...) ** a content (a textarea). Then, on the skin document, we add one XObject per file that we want to overwrite. The system is simple and flexible. (On the future, we can even imagine that XWiki automatically merges the content of the XObject with the existing file in the skin, but this idea is not a part of this proposal.) Depending on the time I will have, I may not be able to fully implement this for 7.0. So I plan to make it work for the LESS files first, that we cannot overwrite currently. Here is my +1, Thanks [1] http://jira.xwiki.org/browse/XWIKI-10568?focusedCommentId=81939&page=com.at… -- Guillaume Delhumeau (gdelhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

9 years, 10 months

[xwiki-devs] Wrong displayer for 'date' and 'List of Users' format

by Pascal BASTIEN

Hello, I created an application with Xwiki 6.4.0, I created my Class (with string, date and /'List of Users' properties), a Sheet and Template. My fields are displayed correctly except if I export my page. In PDF/ODT export file, I obtain "Unknown display mode." instead of the value for all 'date' and 'List of Users' field. Did you notice that? I found this issue http://jira.xwiki.org/browse/XWIKI-8694 (I didn't tested with 'List of groups' but I can if you want to) Thxs Pascal B

9 years, 10 months

[xwiki-devs] [ANN] XWiki 6.2.6 released

by vincent＠massol.net

The XWiki development team is proud to announce the availability of XWiki 6.2.6. This is a bugfix release. 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/ReleaseNotesXWiki626 Thanks -The XWiki dev team

9 years, 10 months

Re: [xwiki-devs] [xwiki-users] Description and priority list for XWiki translations

by Valdis Vītoliņš

To manage translations better I've updated http://l10n.xwiki.org/xwiki/bin/view/L10N/StatusByLanguage page which generates links to translation pages. I added JavaScript sorting, which seems to work only alphabetically :-/ When I work on laptop, I haven't enough screen to fully see translation tables, therefore I added XWiki.StyleSheetExtension with dynamic style which hides panel on smaller width. @media (max-width: 1366px) { #leftPanels, #rightPanels { display: none; } #contentcolumn div.main.layoutsubsection { margin: 0 !important; } div#contentcolumn div.main.layoutsubsection { padding: 0 !important; } } Can anybody with appropriate rights add and include similar object to Translation class http://l10n.xwiki.org/xwiki/bin/view/L10NCode/TranslationFileClassSheet20 Also. And maybe add similar JavaSript sorting for translation tables also? (Or somebody could give modify permissions for valdisvi user to this class.) It would improve usability a lot. Thanks! Valdis > I'm updating XWiki translations in http://l10n.xwiki.org/ and after > resource redesign I wonder where should I start. > > Can you provide some list of description/priorities for all XWiki > platforms and files, which should be translated first to cover needs of > the most usual XWiki users. > > Thanks! > Valdis > > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users

9 years, 10 months

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

by Eduard Moraru

Hi devs, Today is BFD#80: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 70 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#80 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13095 Thanks and enjoy your bug fixing day! -Eduard

9 years, 10 months

[xwiki-devs] [Proposal] Improving our functional test framework: XWikiWebDriver + Automated speed check

by vincent＠massol.net

Hi devs, I’m working on improving our test framework by doing the following: * Introduce a wrapping RemoteWebDriver called XWikiWebDriver * Move all the generic methods (i.e. that are not related to XWiki’s specific UI) we have in TestUtil + BaseElement into XWikiWebDriver (all the findElement(s)WithoutWaiting(), hasElement*(), waitFor*(), etc). The idea is simply to augment the WebDriver-provided APIs with all the methods we have created because they were useful to us. * Add an automated check when calling method that wait (e.g. findElement(), findElements()) so that if the timeout is incurred, we fail the test. The reason is that if we incur the timeout it means the test itself is not doing it right and is taking too much time! Let me know if you don’t agree with something (as quickly as possible since I’ve already spent a few hours on it ;)). Thanks! -Vincent

9 years, 10 months

[xwiki-devs] Inject Warning in Page when Macro in Space not exists

by Matthias Wegner

Hi All, i want to put a {{warning}} in the header of a page when a specific macro is not contained. How can i do that. I tried in a Listener when the needed Macro-Block is not contained with doc.getXDOM().getRoot().addChild(new WordBlock("{{warning}}Warning Text.{{/warning}}")); context.getWiki().saveDocument(doc, context); This not works. What is the correct way to manipulate the Document DOM on Load? Regards, Matthias -- View this message in context: http://xwiki.475771.n2.nabble.com/Inject-Warning-in-Page-when-Macro-in-Spac… Sent from the XWiki- Dev mailing list archive at Nabble.com.

9 years, 10 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