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

Re: [xwiki-devs] [xwiki-notifications] r33998 - platform/web/trunk/standard/src/main/webapp/templates
by Vincent Massol 20 Jan '11

20 Jan '11

On Jan 19, 2011, at 2:05 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2011-01-19 14:05:06 +0100 (Wed, 19 Jan 2011) > New Revision: 33998 > > Modified: > platform/web/trunk/standard/src/main/webapp/templates/macros.vm > Log: > XWIKI-5890: #setVariableFromRequest doesn't work with Velocity 1.7, replace with #readVariableFromRequest > Corrected #setVariable so that it doesn't output any whitespace. > > Modified: platform/web/trunk/standard/src/main/webapp/templates/macros.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/macros.vm 2011-01-19 13:01:30 UTC (rev 33997) > +++ platform/web/trunk/standard/src/main/webapp/templates/macros.vm 2011-01-19 13:05:06 UTC (rev 33998) > @@ -1508,13 +1508,13 @@ > * @param value the value to assign > *### > #macro(setVariable $variableName $value) > - ## Only do this if the variable name is really a valid variable name > - #if ($variableName.matches('[a-zA-Z_][a-zA-Z0-9_-]*')) > - #evaluate("${escapetool.h}set(${escapetool.d}${variableName}=${escapetool.d}value)") > - #elseif ($variableName.matches('\$[a-zA-Z_][a-zA-Z0-9_-]*')) > - #evaluate("${escapetool.h}set(${variableName}=${escapetool.d}value)") > - #end > +## Only do this if the variable name is really a valid variable name > +#if ($variableName.matches('[a-zA-Z_][a-zA-Z0-9_-]*')) > +#evaluate("${escapetool.h}set(${escapetool.d}${variableName}=${escapetool.d}value)") > +#elseif ($variableName.matches('\$[a-zA-Z_][a-zA-Z0-9_-]*')) > +#evaluate("${escapetool.h}set(${variableName}=${escapetool.d}value)") > #end > +#end So we can't use indentation in macros? Should we document this generally or is it specific to this macro (in which case maybe we should add a comment so that the next person doesn't start indenting it)? Thanks -Vincent

3 5

[xwiki-devs] How can I hide attachments from search results?
by John Lantz 20 Jan '11

20 Jan '11

We are having a problem with image attachments clogging up our search results. Say a user is searching for Orange. The topic page Orange will be ranked below an image named orange.png, as well as an image named IMAGEI68A35.png that is on a the Fruit Salad topic page. Ideally, we would be able to hide all attachments from search results. We don't want to hide attachments on topic pages-we need the images to be displayed-but we do need to hide them from search results. The problem is identical to the one posted by this user: http://jira.xwiki.org/jira/browse/XPLUCENE-63 Any suggestions? A simple bit of code I could past into a config or preference file somewhere? Any help would be greatly appreciated. Thank you very much, John Lantz Developer Advocate IdeaBlade Office: 510.596.5100 x124 Cell: 408.515.9565 Email: johnl(a)ideablade.com<mailto:[email protected]>

3 2

Re: [xwiki-devs] [xwiki-notifications] r34008 - platform/xwiki-applications/trunk/watchlist/src/main/resources/XWiki
by Vincent Massol 19 Jan '11

19 Jan '11

On Jan 19, 2011, at 6:13 PM, mflorea (SVN) wrote: > Author: mflorea > Date: 2011-01-19 18:13:30 +0100 (Wed, 19 Jan 2011) > New Revision: 34008 > > Modified: > platform/xwiki-applications/trunk/watchlist/src/main/resources/XWiki/WatchListMessage.xml > Log: > XPWATCHLIST-122: The HTML part of the watchlist notification mail is not rendered under velocity 1.7 > * Escape quotes using an extra variable instead of "" in order to be backwards compatible. > > > Modified: platform/xwiki-applications/trunk/watchlist/src/main/resources/XWiki/WatchListMessage.xml > =================================================================== > --- platform/xwiki-applications/trunk/watchlist/src/main/resources/XWiki/WatchListMessage.xml 2011-01-19 17:02:04 UTC (rev 34007) > +++ platform/xwiki-applications/trunk/watchlist/src/main/resources/XWiki/WatchListMessage.xml 2011-01-19 17:13:30 UTC (rev 34008) > @@ -292,11 +292,12 @@ > #set($result = $result.replaceAll("${prefix}propDiffNewValue", "$propDiffStyle background:#EDFFED;")) > #set($result = $result.replaceAll("${prefix}propDiff", "$propDiffStyle")) > #set($suffix = "_WATCHLIST_IMG_PLACEHOLDER") > + #set($q = '"') If I was a PITA I'd say this should be explained since the next person who sees this will think Marius did a bad job and could have used "" instead (native synax) ;) -Vincent > #foreach($totransform in ["attach", "object", "class", "metadata"]) > - #set($result = $result.replaceAll("${totransform}${suffix}", "<img src=""cid:${totransform}.gif"" style=""${iconStyle}"" ${iconAttrs}></img>")) > + #set($result = $result.replaceAll("${totransform}${suffix}", "<img src=${q}cid:${totransform}.gif${q} style=${q}${iconStyle}${q} ${iconAttrs}></img>")) > #end > #foreach($totransform in ["boolean", "date", "dblist", "dbtreelist", "groups", "levels", "number", "password", "staticlist", "string", "textarea", "users"]) > - #set($result = $result.replaceAll("${totransform}${suffix}", "<img src=""cid:${totransform}.png"" style=""${iconStyle}"" ${iconAttrs}></img>")) > + #set($result = $result.replaceAll("${totransform}${suffix}", "<img src=${q}cid:${totransform}.png${q} style=${q}${iconStyle}${q} ${iconAttrs}></img>")) > #end > $result > #end

2 1

[xwiki-devs] XE 3.0 roadmap status for 3.0M1 and commitments for 3.0M2 and later
by Vincent Massol 19 Jan '11

19 Jan '11

Hi devs, XE 3.0M1 is around the corner (planned for the 17th of Jan). It would be good to know where we stand. Could everyone working for 3.0M1 please report their status in this thread? The planned roadmap was: - Extension Manager - Thomas Mortagne - App within minute - Investigation - Thibaut (with?) - Improved page loading - Investigation - By whom? - Use status - whom? - Right UI - Sergiu? - Portlet - Marius - Multipage export - whom? - Dashboard/Gadget - Anca - Admin/Profile UI improvements - Sergiu - Attachment Storage - Caleb (+ Sergiu to help review it) - Spotlight like search - JV & me - IE6 support drop - Investigation (Greg + Ciprian ?) - Icon theme editor - Investigation (Greg + Caty ?) - LDAP admin section - Investigation (Greg + Thomas ?) - XEM HomePage & Workspace - Investigation (Greg + Fabio + Caty ?) - Reader macro vs XWiki Watch - Investigation - WYSIWYG working on Chrome/Safari (webkit) - Marius Please comment inline for what you've been working on and if you've been working on additional stuff for 3.0M1 please add it in the end. Also if you volunteer to work on something for 3.0M2 or later please let us know in this thread too. Thanks a lot -Vincent

9 10

Re: [xwiki-devs] [myxwiki] new wiki request
by Vincent Massol 19 Jan '11

19 Jan '11

Hi Doug, On Nov 24, 2010, at 1:27 AM, Doug Skuce wrote: > Hello! > > I am a retired IT prof (Phd 1977) and love trying to still do useful things. > > > My idea is to create a wiki in which anyone can enter and comment on problems, mainly laws, at federal, state, or municipal levels. Eg we need to spend more money on police, or garbage collection sucks. > > > I am searching for a suitable wiki and your product seems great except for cost. This wiki could have 100s of thousands of users if used nationwide. Of course they could be separate but that is less desirable. You could use myxwiki.org to validate your concept but if it grows to lots of users you should contact XWiki SAS (http://xwiki.com) to ask for a quote to support all the users you have in mind. If you're interested to test myxwiki.org please follow the instructions on http://myxwiki.org/xwiki/bin/view/Main/WebHome Thanks -Vincent > I successful how would scale to thousands of users? > > > Let me know your thoughts. > > > Thanks > > > Doug Skuce

1 0

[xwiki-devs] [Proposal] Group manager (User with edit rights on group's page)
by Eduard Moraru 18 Jan '11

18 Jan '11

Hi devs, I`ve just made a few modifications (locally) to the group sheet and to the livetable macro to allow users with edit rights on a group's page to edit the group, acting like a "group manager", without having to require wiki-level admin rights. I thought this would be a nice addition to XE so here is the jira issue (with patch included). WDYT? Thanks, Eduard

3 3

[xwiki-devs] Crypto module test failure
by Vincent Massol 14 Jan '11

14 Jan '11

Hi devs, This is not the first I notice that one of the crypto module test is failing on my machine when building core. Here's what I got this time: Tests run: 14, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.106 sec <<< FAILURE! initializationProcessorTimeTest(org.xwiki.crypto.passwd.ScryptMemoryHardKeyDerivationFunctionTest) Time elapsed: 1.501 sec <<< FAILURE! java.lang.AssertionError: password hashing took 1437 and target time was 500 My machine is pretty powerful so it shouldn't be an issue either with memory or cpu. Any idea on how to fix this? Thanks -Vincent

1 0

[xwiki-devs] [Idea] New default color theme for the 3.0 cycle
by Jerome Velociter 14 Jan '11

14 Jan '11

Hello friends, What about we create and set default a new color theme for XE, in the 3.0 cycle ? This is a cheap way for us to refresh the look and to differentiate 3.x visually ? We could aslo have new additional themes, besides the default one. Jérôme.

8 16

[xwiki-devs] [Idea] Compatibility file for deprecated styles
by Jerome Velociter 13 Jan '11

13 Jan '11

Hello devs, I've just hit an issue where my application relies on CSS styles definitions that are being dropped between 2.7 and 3.0, namely all the dashboardXXX classes, abandoned in favor of the new dashboard macro styles. While I reckon those CSS classes were never explicitly defined as being APIs developers should rely on, I think we should offer better backward compatibility for those who did rely on them, just like we do with JavaScript code (see http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackwar… ) What we could do is introduce a compatibility.css file holding styles for such deprecated classes, and decide if we want it or not included by default (The JavaScript compatibility.js file is included by default, for example, although the rules states that XE releases should work just the same without it, of course). WDYT ? Jérôme.

3 3

[xwiki-devs] [Proposal] Removing Deprecated methods in XE 3.0+
by Vincent Massol 13 Jan '11

13 Jan '11

Hi devs, I think the start of the XE 3.x cycle is a good time to remove some deprecated methods/classes. We have a deprecation strategy defined already: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HDepreca… " Our rule is to keep @deprecated methods/classes for 2 final releases after the version where they were first added has been released as final. For example if a method is deprecated in, say XE 1.3M2 then the method will be removed in 1.6M1 or after. Of course any major new release can deprecate anything. For example a XWiki 2.0 release is allowed to break backward compatibility (obviously we need to be careful to offer a migration path for users of previous major versions). " So 2 final releases mean that deprecations introduced in 2.5.x or before can theoretically be removed for XE 3.0 final. However, IMO we shouldn't remove deprecated methods/classes that are public for scrips since this will break xwiki users. Are we ok to do that? Personally I'm fine and I'd like to add this caveat to the best practice if we agree. Thanks -Vincent

5 9