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

[xwiki-devs] [Proposal] Postpone the XWiki 8.3 release

by Vincent Massol

Hi devs, Today is release day for 8.3. I’d like to postpone it to tomorrow the 11th so that we can fix http://jira.xwiki.org/browse/CKEDITOR-113 which is a blocker. I started debugging over the week end. I’d need some help though since I’m far from sure I’ll be able to fix it by myself. Would be great if at least one other dev could work on trying to fix it too at the same time. WDYT? Thanks -Vincent

8 years, 11 months

1
2
0 0

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

by Alexandru Cotiuga

Hello devs, This Thursday is BFD#121: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 54 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#121 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13697 Happy Bug Fixing Day, Alex

8 years, 11 months

1
1
0 0

Re: [xwiki-devs] [xwiki-users] Fw : Re: Issues when I upgraded my xwiki 7.0.1 to xwiki 8.2.1: search feature

by Sergiu Dumitriu

Something like this: https://github.com/phenotips/phenotips/blob/b5fd2933480bcdeaca0194840b1c845… On 10/04/2016 05:56 AM, Vincent Massol wrote: > >> On 04 Oct 2016, at 11:54, Pascal BASTIEN <pbasnews-xwiki(a)yahoo.fr> wrote: >> >> Thanks, you are right I forgot to removed solr subdirectory before upgrade. >> >> stop + rm + start xwiki = xwiki work again like a charm >> (sorry ;-) ) > > cool > > you don’t need to be sorry. We need to improve this. Like forcing automatically the removal when we upgrade solr and there’s been some schema changes. > > -Vincent > >> Thxs >> >> --- En date de : Mar 4.10.16, Vincent Massol <vincent(a)massol.net> a écrit : >> >>> De: Vincent Massol <vincent(a)massol.net> >>> Objet: Re: [xwiki-users] Issues when I upgraded my xwiki 7.0.1 to xwiki 8.2.1: search feature >>> À: "XWiki Users" <users(a)xwiki.org> >>> Date: Mardi 4 octobre 2016, 11h36 >>> Hi, >>> >>> Try removing your solr index. >>> >>> Thanks >>> -Vincent >>> >>>> >>> On 04 Oct 2016, at 11:26, Pascal BASTIEN <pbasnews-xwiki(a)yahoo.fr> >>> wrote: >>>> >>>> Hello, >>>> >>>> After upgrading my >>> xwiki 7.0.1 to 8.2.1, i encoutered another issue: xwiki >>> search feature doesn't work anymore. >>>> I use Tomcat 8.0.33 + Postrgesqk 9.3 and >>> attachments in file system and connected with Admin >>> account. >>>> >>>> On page >>> ./bin/view/Main/Search?text=test&f_type=DOCUMENT&f_locale=fr&f_locale=&r=1 >>> , I have this ugly error message displayed: >>>> "Failed to execute the [velocity] >>> macro. Cause: [The resolver parameter doesn't contain an >>> Entity Reference of type [SPACE]]. Click on this message for >>> details." >>>> >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Sergiu Dumitriu http://purl.org/net/sergiu

8 years, 11 months

1
0
0 0

[xwiki-devs] [PROPOSAL] Stabilize filesystem templates rights

by Thomas Mortagne

Hi devs, Right now (and since forever) the default behavior for templates is to be executed with the right of the current document content author (it's not really explicit, it's just how PR works when there is no sdoc). This means that unless you explicitly indicate an author for your template (possible since 7.x) you don't really have any idea which right it's going to have at runtime. It also make harder to properly execute templates outside of main rendering thread where the "current document" often don't really make much sense. I think we should make the default more stable. I can think of two possibilities: 1) with what we got right now the only real possibility is to execute the filesystem template with superadmin right (which is only an option right now). Makes it consistent with the "code is executed with the right of its author" rule we have for wiki pages 2) introduce some new virtual user (like "templateauthor" or "scripter" or whatever) which only have script right and use that as filesystem template author if we absolutely want template to not have too many rights by default (even if modifying a filesystem template require much more access than superadmin in practice) +1 for 1) -- Thomas Mortagne

8 years, 11 months

5
5
0 0

[xwiki-devs] [Brainstorming] Disable install count on exo for extensions bundled in XE?

by Vincent Massol

Hi devs, Question: do we agree to disable "show active installs" for extensions bundled in XE on e.x.o? (if I remember correctly that's why thomas introduced this checkbox but I want to make sure we have the same opinion) The idea is not to drown the install figures with bundled extensions which are not chosen by users (they get them by default). Right now we still have a few extensions that are bundled and have their install count displayed. I can fix it but I want to make sure first. Also we need to decide what to do with contrib extensions bundled in XE. For example: - Tour app - CKEditor - Templates app I think we should also disable their active install count, following the same rule, even though they can also be installed by themselves in older versions of XE. WDYT? To see it: http://extensions.xwiki.org/xwiki/bin/view/Extension/#|t=extensions&p=1&l=3… Thanks -Vincent

8 years, 11 months

4
5
0 0

[xwiki-devs] [Contrib][BatchImport] Release of batch import application version 1.2

by Anca Luca

Hello all, Alex and I have fixed a couple of issues on the batch import application (issues BATCHIMP-1,2,3,4,5,6) and I would like to release version 1.2 of this application. Functionally, these changes bring translations being properly activated when the app is installed, one more option configurable from the UI (clear names) and some support for the new format of AWM (the nested spaces one). It does not break compatibility, as I managed to write code that should work fine in all cases (nested or not). If nobody has anything against, I will release this tonight. Thanks a lot, Anca

8 years, 11 months

1
1
0 0

[xwiki-devs] [Proposal] 2 new rules for Application Best Practices

by vincent＠massol.net

Hi devs, Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… 1) New rule 1: “Code” subspace Current text: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. New version: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. * Technical pages should be put in a subspace named “Code” Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this. 2) New rule 2: * Technical pages without children must be terminal pages. WDYT? Thanks -Vincent

8 years, 11 months

15
52
0 0

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

by Alexandru Cotiuga

Hello devs, This Thursday is BFD#120: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 49 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#120 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13696 Happy Bug Fixing Day, Alex

8 years, 11 months

1
1
0 0

[xwiki-devs] [VOTE] Change the release cycle to 1 month

by Vincent Massol

Hi devs, Executive summary: * Replace our 3 month release cycle by a 1 month release cycle. Needs and advantages: * Be able to get our changes faster to our users. Importantly, bugfixes are released faster to users. Note: it’s not because we release faster that our users have to upgrade as fast. They can skip some versions if they want/need. * Be able to get more feedback more quickly from users. Right now, most (if not all) of our users are testing only final versions. They’re not testing milestones or RCs and thus we usually only know about problems after the final has been released and we incorporate the change in the next one (to be released 3 months later) or we have to do a bugfix release. * Get closer to cloud needs. Nowadays, could offerings happen more and more and operating a cloud means bringing improvements and fixes as fast as possible. Some software in the cloud are even updated/patched several times per day. We’re not there yet but we’re trying to get closer by reducing from 3 months to 1 month * This also means more marketing for the xwiki project since other site relay the new whenever a final version is released Proposal Details: * 1 month split in: 3 weeks to release a RC + 1 week to release the final version. It’s very important to keep the RC as a meeting point and ensuring all is going to be ready on time for the final release (jiras are closed or moved to the next release, CI is passing, documentation and RN are ready, etc). * Split large features into smaller chunks. It doesn’t matter if some code is released but unused for example (provided the build is passing). For larger refactoring that absolutely cannot be split into 3 weeks chunks (I’m not sure that really exists) then we can use branches (and create a CI job to ensure integration). * Less need for bugfix releases of stable versions. For LTS it’s still required though. * Note that this 1 month release strategy will not generate more releases (and thus more work) over the year since we’re already releasing every 2-3 weeks ATM (milestones, RCs, et) * Version Naming: from N.0 to N.10 where N is the cycle name. The reason for 11 releases and not 12 is to account for slippages + potential bugfix release at the end of the cycle for stabilization + holidays. We might even be able to do only 10 releases and not 11 but I’m suggesting we try with 11 for now. When: * I’m proposing to start this process with the 8.4 release (starting on the 10th of October). Since that version is already supposed to be a stabilization release (and thus a short 1 month release) it’s not going to change anything. We should also do bugfix releases after 8.4 is releases: 8.4.1, 8.4.2, etc till the end of the year * Then starting 9.0 we really start doing 1 month releases. WDYT? Here’s my +1 to try this. Thanks -Vincent

8 years, 11 months

5
9
0 0

Re: [xwiki-devs] [Proposal] Change the default logo in the XWiki Enterprise default color theme

by Benjamin Lanciaux

Hi devs, I would like to propose a new logo for the default color theme of XE. Instead of having the colored version of the XWiki logo, I propose using its white version. I see many advantages to this: * On a black banner, it is easier to see the XWiki brand compared to the colored one for which I barely see the "X". * This would also be more consistent with the other menu options that are placed on the black banner. See how it looks like now: http://imgur.com/a/ZzEOY And see how it would look like with my proposal: http://imgur.com/a/MF0r6 I'm looking forward to your feedback, Regards, Benjamin Lanciaux

8 years, 11 months

3
2
0 0

[xwiki-devs] [ANN] XWiki 8.3 Release Candidate 1 released

by Vincent Massol

The XWiki development team is proud to announce the availability of XWiki 8.3 Release Candidate 1. The highlight of this release is the support of Recommended Extensions (both on http://extensions.xwiki.org and inside the Extension Manager UI in XWiki). Other changes consist in minor improvements and bug fixes. 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/ReleaseNotesXWiki83RC1 Thanks for your support -The XWiki dev team

8 years, 11 months

1
0
0 0

[xwiki-devs] [Proposal] Format for @since tags

by Vincent Massol

Hi devs, I’d like to propose that we standardized on using multiple @since tags for multiple versions in order to be more semantic and not have to invent a syntax (that then needs to be followed and parsed) Instead of: @since 8.4.5, 8.3RC1 Use: @since 8.4.5 @since 8.3RC1 This is supported by the javadoc, see http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#a… Also note that our Unstable annotation checker needs to be in sync (I’ve opened http://jira.xwiki.org/browse/XCOMMONS-1071 in advance). The main rationale is that it’s more semantic to have one since per version (similar to having one author par author). WDYT? Thanks -Vincent PS: I have already made changes for commons and waiting for agreement before committing or discarding ;)

8 years, 11 months

5
6
0 0

[xwiki-devs] [Proposal] Release Notes Application

by Vincent Massol

Hi devs, I’m planning to write a Release Notes Application for xwiki.org. I’d like to do something relatively simple in order to have a first working version. Rationale ======== * Have nicer looking release notes by defining a structure and a common L&F * For users, be able to see all the release notes item from a given version to another version and by category Idea ==== Specifically for the “New and Networthy" section have: - A visual that looks like this: https://www.jetbrains.com/datagrip/features/ - 2 columns layout - For each item a screenshot and a summary text - (optional) Have a “Learn more” button that goes to the item and provides more info (and possibly more screenshots if need be) XProperties: - Version (in which the item has been added). Static list - Category (Help, Color Themes, Solr Search, AWM, etc). Static list - Main screenshot - Summary text - Additional content - Target audience (User, Admin, Developer). Static list Notes: - If no “main screenshot” is provided then the generated report will put the item in a Miscellaneous section For now I don’t want to handle other metadata for the releases notes, i.e. translations, upgrades, backward compat, tested browsers, etc). Precisely, I’m planning to write a “New and Networthy” application ATM, not a full “Release notes app”. The way it could be used is through a {{news/}} macro, e.g.: {{news from=“6.4” to=“8.2” [categories=“help,awm,...”] [targetAudience=“user,admin”] /}}. Usage ====== - There would be a page in the wiki to see the livetable corresponding to all the release notes news (the xproperties above) - Above this Livetable I imagine a form with several fields: — From version, — To Version — Category (if not empty generate the report only for that category) — Target (user, admin, dev). (if not empty only generate the report for that target audience) — + a “Generate” button to generate a dynamic "News and Networthy” report - We would also use Tags for each news to categorize it further, e.g. “usability”, “performance”, and the LT would display the tag cloud. This will allow for example to see all items between such version and such version that are related to, say, performance - We would still write a Release Notes page for each version but on that page, we would use the {{news/}} macro (with from = to = the version corresponding to that RN). On that page we would add all the other parts that are not in the app yet, i.e. translations, upgrades, backward compat, etc - When an XWiki developers codes a new feature or improvement or new API will use the app to add it. Future ====== * Add a different release notes app to include the other metadata * We could almost imagine using this “New and networthy” app to provide reference documentation for our features… :) (along with automatic “since”). That’s probably too science-fiction and I’m sure there are lots of gotchas but just mentioning it here to make us dream a bit... I’m starting to work on the POC. Let me know what you think. Thanks -Vincent

8 years, 11 months

5
18
0 0

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

by Alexandru Cotiuga

Hello devs, Today is BFD#119: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 53 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#119 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13694 Thanks and enjoy fixing bugs, Alex

8 years, 11 months

1
1
0 0

[xwiki-devs] [ANN] XWiki 7.4.5 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 7.4.5. This is a bugfix release that fixes important bugs discovered in the 7.4.4 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/ReleaseNotesXWiki745 Thanks for your support -The XWiki dev team

8 years, 11 months

1
0
0 0

[xwiki-devs] [Brainstorming] Being able to install an extension or import a XAR in a space

by Vincent Massol

Hi devs, Now that we support Nested Pages, I think it would be nice if we had the option to install an Extension in a space (i.e. a page from a user POV). Technically at the Component Manager level, we can already register a component at the farm level (root), in the current wiki, in the current space or for the current user. We already have the option to install an extension in a wiki and it would be nice to extend that concept to a space. We also already have the concept of space admin UI. Of course the app should tell whether it supports being installed in several spaces or not. The use case is simply to be able to install several times a given application. From a UI perspective, when you go the the space admin UI (called the Page Administration for users), you’d have the option to list installed extensions and install new extensions (basically what you currently have at the wiki level). Now, the same should be doable also for importing XARs, i.e. also have an Import option in the Page Administration UI. WDYT? How complex would it be to do that? Do we already have a JIRA for this (couldn’t find one)? Thanks -Vincent

8 years, 12 months

3
5
0 0

[xwiki-devs] [ANN] LDAP extensions 9.1 have been released

by Thomas Mortagne

Hi xwikiers, We decided to remove LDAP authenticator from XWiki Enterprise in 8.3. So I moved everything that was related to LDAP in https://github.com/xwiki-contrib/ldap. Don't worry It's still supported by the XWiki Dev team and got many improvements already. It just felt easier to maintain and reuse it in its own repository and is very easy to install with Extension Manager. I taken the occasion to "merge" the LDAP Authenticator and Trusted LDAP Authenticator so there is now only one with all the features of both authenticators plus a few bonuses. You can also use it since Wiki 7.4.x and get all the new features without upgrading. It won't conflict with the embedded one, you just indicate you want to use the new one which is fully retro-compatible. See more details on http://extensions.xwiki.org/xwiki/bin/view/Extension/LDAP/ and http://extensions.xwiki.org/xwiki/bin/view/Extension/LDAP/Authenticator/. -- Thomas Mortagne

8 years, 12 months

2
2
0 0

[xwiki-devs] [ANN] Release of Limits Application 1.2.

by Guillaume Delhumeau

Hi users and devs, The Limits Application has been improved again. It seems I have taken the manta "release early, release often" very seriously :). The 1.2 version has been released and brings the ability to handle custom limits. See: http://extensions.xwiki.org/xwiki/bin/view/Extension/Limits+Application Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

8 years, 12 months

2
1
0 0

[xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling

by vincent＠massol.net

Hi devs, Right now our strategy is for script services and script APIs in general to catch exceptions, store them and offer a getLastError() method to get them (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Script+Module#HBestPra…) However it would be much nicer to: * Let our script services generate exceptions * Offer a velocity script service to get the last exception raised by a java call from velocity * Implement this uberspector to catch the exceptions and to set them in the execution context That should be quite easy to implement IMO. WDYT? Thanks -Vincent PS: This is http://jira.xwiki.org/browse/XWIKI-2374

8 years, 12 months

7
29
0 0

Re: [xwiki-devs] Nested Pages - Search Links Not Working

by Keith Davis

It's very hard to manage this application with zero support. Am I blacklisted or what? I haven't received input on a single support issue since I complained about the release notes issue (which strangely enough seems to be being worked on now). Keith Davis (214) 906-5183 - I.T. Director From: Keith Davis Sent: Friday, September 16, 2016 11:54 AM To: 'devs(a)xwiki.org' Subject: Nested Pages - Search Links Not Working So we are now starting to change all of the our pages to Nested. When linking to Nested pages in the page themselves, the links appear like this in the WYSIWYG editor: [[Tickets>>Main.Intranet.Tickets<http://Home.Intranet.Tickets>]] but when saved are converted to this: <a href="/xwiki/bin/view/Main/Intranet/Tickets/">Tickets</a> However, Search results are broken. They appear like this: [cid:image005.jpg@01D20F61.C86FF330] Those do not work as the link Main.Intranet.Tickets takes me to this page: [cid:image006.jpg@01D20F61.C86FF330] I've tried re-indexing, but that does not help. Keith Davis - MCSA, ZCE P.R.I.D.E. - I.T. Director / Senior Developer www.pridedallas.com<http://www.pridedallas.com/> Mobile (214) 906-5183

8 years, 12 months

4
5
0 0

[xwiki-devs] [Proposal] New best practice for app development: namespace restrictions

by Vincent Massol

Hi, Since XWiki 8.0 we now have a way to define in which namespace an extensions work. See “xwiki.extension.namespaces” in http://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki+Commons+-+Extens… I’m proposing to add that apps should use this as a best practice in http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… WDYT? Thanks -Vincent

8 years, 12 months

5
9
0 0

[xwiki-devs] Nested Pages - Search Links Not Working

by Keith Davis

So we are now starting to change all of the our pages to Nested. When linking to Nested pages in the page themselves, the links appear like this in the WYSIWYG editor: [[Tickets>>Main.Intranet.Tickets<http://Home.Intranet.Tickets>]] but when saved are converted to this: <a href="/xwiki/bin/view/Main/Intranet/Tickets/">Tickets</a> However, Search results are broken. They appear like this: [cid:image005.jpg@01D20F61.C86FF330] Those do not work as the link Main.Intranet.Tickets takes me to this page: [cid:image006.jpg@01D20F61.C86FF330] I've tried re-indexing, but that does not help. Keith Davis - MCSA, ZCE P.R.I.D.E. - I.T. Director / Senior Developer www.pridedallas.com<http://www.pridedallas.com/> Mobile (214) 906-5183

9 years

1
0
0 0

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

by Alexandru Cotiuga

Hello devs, This Thursday is BFD#118: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 56 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#118 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13691 Thanks and waiting for your participation! Alex

9 years

2
2
0 0

[xwiki-devs] [ANN] Limits Application 1.1 has been released

by Guillaume Delhumeau

Hello. Yesterday, I announced you the availability of a new extension: the Limits Application. Since, Thomas Mortagne suggested me an idea to make it better. The UI of the application is now contained in the JAR, so it cannot be removed by mistake by an user who manipulates wiki pages. Moreover, the UI is now visible on every subwikis, without the need to install something on each of them. Also, developers will be happy because they can overwrite the default UI like any skin template! To download it or see more informations, see: http://extensions.xwiki.org/xwiki/bin/view/Extension/Limits+Application/#Hv… Thanks, -- Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

9 years

1
0
0 0

[xwiki-devs] [Brainstorming] New script API needed: isXARExportAvailable()

by Vincent Massol

Hi devs, I’d like to add a new script API in oldcore. I need a new API to know if the XAR export feature is available so that the Page level XAR export button is displayed (I’m trying to fix http://jira.xwiki.org/browse/XWIKI-13695#). I was thinking about adding some XXXScriptService in oldcore but the right hint would be “xar” and XXX would be “XAR”. The problem is that we already have one in xwiki-platform-xar (which right now is used by oldcore and thus I cannot add this new method to the existing XarScriptService that is there). I can’t find any name or hint that would make sense on the long run for oldcore. Some other ideas: * OldCoreScriptService, hint = “oldcore” and we consider it something temporary that will need to go away and deprecate * CoreScriptService, hint = “core”. Same * ImportExportSerciceService, hint = “?” Last, I have the option to continue what we’ve done so far which is increase a bit more the size of api.XWiki. For example we have in there the following method which does something similar: /** * @return true if title handling should be using the compatibility mode or not. When the compatibility mode is * active, if the document's content first header (level 1 or level 2) matches the document's title the * first header is stripped. */ public boolean isTitleInCompatibilityMode() { return this.xwiki.isTitleInCompatibilityMode(); } so I could add XWiki.isXARExportAvailable()… WDYT? Any preference? Right now I have a hard time deciding. I hate it but I’m considering adding a new method to the XWiki class, but I’d love to find something better. Thanks -Vincent

9 years

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs