Re: [xwiki-users] [ANN] XWiki 6.0 Release Candidate 1 released
Just some feedback: I tried to run the ZIP version, but when I launch start_xwiki.bat, a windows cmd screen flashes and nothing happens. With a bit of excellent timing hitting the Print Scrn button, I was able to capture the cmd screen :-) It displays: C:\Program Files (x86)\Java\jr7\bin\java.exe is not recognized as an internal or external command, operable program or batch file. Which is true, as I havn't installed Java7 :-) It would be nice if the windows cmd would not close, so a user could read the actual error message! Thanks -- View this message in context: http://xwiki.475771.n2.nabble.com/ANN-XWiki-6-0-Release-Candidate-1-released-tp7590134p7590198.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] [ANN] XWiki 6.0 Release Candidate 1 released
On 23 Apr 2014 at 11:24:35, Hamster (teun...@hotmail.com(mailto:teun...@hotmail.com)) wrote: Just some feedback: I tried to run the ZIP version, but when I launch start_xwiki.bat, a windows cmd screen flashes and nothing happens. With a bit of excellent timing hitting the Print Scrn button, I was able to capture the cmd screen :-) It displays: C:\Program Files (x86)\Java\jr7\bin\java.exe is not recognized as an internal or external command, operable program or batch file. Which is true, as I havn't installed Java7 :-) It would be nice if the windows cmd would not close, so a user could read the actual error message! I’ve been wanting to do that for a long time and I’ve now implemented it with http://jira.xwiki.org/browse/XWIKI-10266 Hope you’ll like it! Thanks -Vincent ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Just Map It!
Good Morning, Anyone is using the extension Just Map It? I have checked the site and it apparently is offline! Thank you Danilo Grupo Energisa Danilo Oliveira Analista Suporte Aplicacao TI - DPTO CORP. DE INFRAESTR. TI e-mail: danilo.olive...@energisa.com.br | tel: (32) 3429-6342 | cel: (32) 8452-9478 Esta mensagem contém informação confidencial. Se você a recebeu por engano, não divulgue ou copie seu conteúdo. Por favor, avise ao remetente imediatamente e apague-a do computador. Privileged and confidential. If this message has been received by mistake, do not disclose or copy its contents. Please notify sender and delete immediately. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Turn off comments on one page only?
This works fine for me:
{{velocity}}
#set ($showcomments = false)
{{/velocity}}
(on the wiki page where you want to hide the comments tab)
Hope this helps,
Marius
On Tue, Apr 22, 2014 at 11:24 AM, Jeremie BOUSQUET
jeremie.bousq...@gmail.com wrote:
Hello,
This is described here:
http://platform.xwiki.org/xwiki/bin/view/DevGuide/Scripting#HControllingWhichSectionstoDisplay
But I must say that I couldn't have it work (in xwiki 5.4.3 at least).
From xwikivars.vm, it seems to me that you can only deactivate comments at
minimum at level of a space.
Alternatively you could update your xwikivars.vm to deactivate comments
after testing for a specific page name.
BR,
Jeremie
2014-04-21 18:55 GMT+02:00 Patrick Masson mas...@opensource.org:
I was wondering if it was possible to turn off comments on a single wiki
page?
I found information for disabling comments across the wiki...
* http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration
* http://www.xwiki.org/xwiki/bin/view/FAQ/Howtodisablecommentsandattachm
ents
and the same question from someone else (but with no response yet)...
* http://www.xwiki.org/xwiki/bin/view/FAQ/Howcancommentsbedisabledforasi
nglepage
Thanks,
Patrick
--
||| | ||||| |||| |||
Patrick Masson
General Manager, Director Secretary to the Board
Open Source Initiative
855 El Camino Real, Ste 13A, #270
Palo Alto, CA 94301
United States
Skype: massonpj
sip: mas...@getonsip.com https://www.getonsip.com/
call?a=mas...@getonsip.com
Ph: (970) 4MASSON
Em: mas...@opensource.org mailto:mas...@opensource.org
Ws: www.opensource.org http://www.opensource.org
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] PDF export - customizing table of content
Thank you Marius.
But I think I am misunderstood (perhaps I’ve not well described my problem !):
in fact I only want to change the CSS for the table of content of my PDF.
Could you help?!
Thanks
Le 2 avr. 2014 à 10:02, Marius Dumitru Florea mariusdumitru.flo...@xwiki.com
a écrit :
The table of contents for the PDF export is generated here
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-oldcore/src/main/resources/xhtml2fo.xsl#L867
. You should get this file from the xwiki-platform-legacy-oldcore jar
that you have in the XWiki WAR (WEB-INF/lib). You can edit it and put
is to WEB-INF/classes.
Hope this helps,
Marius
On Tue, Apr 1, 2014 at 11:09 AM, Nicolas Sanitas
nicolas.sani...@intech.lu wrote:
Hi all,
up!
Is there anybody who has already changed the way the table of contents is
displayed when exporting in PDF?
Thanks,
Nicolas
Le 28 mars 2014 à 14:22, Nicolas Sanitas nicolas.sani...@intech.lu a écrit
:
Hi all,
I have followed information given here
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration in order
to customize my PDF export (via its CSS).
I succeeded in doing all I wanted, except concerning the table of content:
I can't customize it because I don't know which component is used to
display it (neither p, nor ul...).
Could you help me please? I would change the font used to display it.
For information I've tried to setup the font-family defined for the whole
document with
body { font-family: 'Helvetica Neue LT Com'; }
but it crashes at PDF generation time (please see below).
Thanks by advance!
Nicolas
Error number 11015 in 11: Exception while exporting
com.xpn.xwiki.XWikiException: Error number 11015 in 11: Exception while
exporting
at com.xpn.xwiki.web.ExportAction.render(ExportAction.java:82)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:294)
at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:129)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:425)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:228)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:121)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:126)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:66)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.xwiki.container.servlet.filters.internal.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:208)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.xwiki.container.servlet.filters.internal.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:111)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at
Re: [xwiki-users] Turn off comments on one page only?
Note that I’ve fixed the doc.
Thanks!
-Vincent
On 23 Apr 2014 at 14:19:12, Marius Dumitru Florea
(mariusdumitru.flo...@xwiki.com(mailto:mariusdumitru.flo...@xwiki.com)) wrote:
This works fine for me:
{{velocity}}
#set ($showcomments = false)
{{/velocity}}
(on the wiki page where you want to hide the comments tab)
Hope this helps,
Marius
On Tue, Apr 22, 2014 at 11:24 AM, Jeremie BOUSQUET
wrote:
Hello,
This is described here:
http://platform.xwiki.org/xwiki/bin/view/DevGuide/Scripting#HControllingWhichSectionstoDisplay
But I must say that I couldn't have it work (in xwiki 5.4.3 at least).
From xwikivars.vm, it seems to me that you can only deactivate comments at
minimum at level of a space.
Alternatively you could update your xwikivars.vm to deactivate comments
after testing for a specific page name.
BR,
Jeremie
2014-04-21 18:55 GMT+02:00 Patrick Masson :
I was wondering if it was possible to turn off comments on a single wiki
page?
I found information for disabling comments across the wiki...
* http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration
* http://www.xwiki.org/xwiki/bin/view/FAQ/Howtodisablecommentsandattachm
ents
and the same question from someone else (but with no response yet)...
* http://www.xwiki.org/xwiki/bin/view/FAQ/Howcancommentsbedisabledforasi
nglepage
Thanks,
Patrick
--
|| | | || || | ||| | |||
Patrick Masson
General Manager, Director Secretary to the Board
Open Source Initiative
855 El Camino Real, Ste 13A, #270
Palo Alto, CA 94301
United States
Skype: massonpj
sip: mas...@getonsip.com call?a=mas...@getonsip.com
Ph: (970) 4MASSON
Em: mas...@opensource.org
Ws: www.opensource.org
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Fwd: Re[2]: SearchSuggest parameters in a new syntax gives different behaviour
-- Forwarded message -- From: Dmitry Bakbardin haru_mamb...@mail.ru Date: Wed, Apr 2, 2014 at 2:03 PM Subject: Re[2]: [xwiki-users] SearchSuggest parameters in a new syntax gives different behaviour To: Marius Dumitru Florea mariusdumitru.flo...@xwiki.com Hi, Marius! See below. Wed, 2 Apr 2014 10:41:32 +0300 от Marius Dumitru Florea mariusdumitru.flo...@xwiki.com: On Wed, Apr 2, 2014 at 9:53 AM, Marius Dumitru Florea mariusdumitru.flo...@xwiki.com wrote: Hi Dmitry, On Mon, Mar 31, 2014 at 5:33 AM, Dmitry Bakbardin haru_mamb...@mail.ru wrote: Hi, all! 5.2 - 5.4.3 Upgrade Xwiki.SearchSuggest objects were changed It was: type:OBJECT AND (class:XWiki.BlogPostClass) AND objcontent:(__INPUT__*) It is: fq=type:DOCUMENT fq=class:Blog.BlogPostClass qf=object.Blog.BlogPostClass The main difference: - it was __INPUT__* query string and - (as far as I understood) it is __INPUT__ if parameter q is omitted The result is Solr Suggest changes it's behaviour and gives only exact results. To make Search Suggest running as it was, we have to add: q=__INPUT__* Is it done by puprpose or it is a bug and I have to jira it? On purpose. I did it as part of http://jira.xwiki.org/browse/XWIKI-10051 (check the documentation links). The reason I dropped the * (star) is because: (1) Prefix matching is costly If Search Suggest is too costly, we can turn it off completely :) (2) The search suggest is not a filter (in the sense that you have a list of item and you type some text and it filters the items starting with that text). Search is more complex. The search text is analysed, stop words are removed, etc. (3) It was a fake prefix matching, because if you typed more words, only the last word was matched as prefix (not the entire text). All the other were analysed. IMHO, suggest means we prefer suggest more than exact search results. What I mean, that all languages wich have declensioin are too sensitive to the __INPUT__* search. Usual use case for such a search is: you enter root of the word and get back suggest of ALL forms of the word. Even in English, which is much less declensionable, singular and plural is the case. E.g. wiki input will give only exact much and won't show wikis. Thus, it makes Solr Sugges much less relevant. As you said, you can get back the previous behaviour using q=__INPUT__* Yes, it was the firs I did, 'cause nearly to all my search strings Solr gave me no results. It wasn't so severe before the upgrade. :) IMHO, it's better to leave __INPUT__* in default settings and amend documentation with performance/relevancy issues tricks for Solr Suggest tuning. * would be useful for most use cases, and would make Suggest effective, especially for new users who start playing with XWike. I do agree, that in the high load projects it could be essential to tweak default behaviour or turn it off at all. Let me know what yo think, Marius Kind regards, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users Kind regards, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Fwd: Re[2]: SearchSuggest parameters in a new syntax gives different behaviour
-- Forwarded message -- From: Marius Dumitru Florea mariusdumitru.flo...@xwiki.com Date: Thu, Apr 3, 2014 at 6:03 PM Subject: Re: Re[2]: [xwiki-users] SearchSuggest parameters in a new syntax gives different behaviour To: Dmitry Bakbardin haru_mamb...@mail.ru On Wed, Apr 2, 2014 at 2:03 PM, Dmitry Bakbardin haru_mamb...@mail.ru wrote: Hi, Marius! See below. Wed, 2 Apr 2014 10:41:32 +0300 от Marius Dumitru Florea mariusdumitru.flo...@xwiki.com: On Wed, Apr 2, 2014 at 9:53 AM, Marius Dumitru Florea mariusdumitru.flo...@xwiki.com wrote: Hi Dmitry, On Mon, Mar 31, 2014 at 5:33 AM, Dmitry Bakbardin haru_mamb...@mail.ru wrote: Hi, all! 5.2 - 5.4.3 Upgrade Xwiki.SearchSuggest objects were changed It was: type:OBJECT AND (class:XWiki.BlogPostClass) AND objcontent:(__INPUT__*) It is: fq=type:DOCUMENT fq=class:Blog.BlogPostClass qf=object.Blog.BlogPostClass The main difference: - it was __INPUT__* query string and - (as far as I understood) it is __INPUT__ if parameter q is omitted The result is Solr Suggest changes it's behaviour and gives only exact results. To make Search Suggest running as it was, we have to add: q=__INPUT__* Is it done by puprpose or it is a bug and I have to jira it? On purpose. I did it as part of http://jira.xwiki.org/browse/XWIKI-10051 (check the documentation links). The reason I dropped the * (star) is because: (1) Prefix matching is costly If Search Suggest is too costly, we can turn it off completely :) Not if there is a way to improve it. My idea was to offer by default something that performs well, but I agree that it could also be seen as an optimization. (2) The search suggest is not a filter (in the sense that you have a list of item and you type some text and it filters the items starting with that text). Search is more complex. The search text is analysed, stop words are removed, etc. (3) It was a fake prefix matching, because if you typed more words, only the last word was matched as prefix (not the entire text). All the other were analysed. IMHO, suggest means we prefer suggest more than exact search results. What I mean, that all languages wich have declensioin are too sensitive to the __INPUT__* search. Usual use case for such a search is: you enter root of the word and get back suggest of ALL forms of the word. Even in English, which is much less declensionable, singular and plural is the case. E.g. wiki input will give only exact much and won't show wikis. Thus, it makes Solr Sugges much less relevant. typing wiki (without the quotes) definitely matches wikis if the document (default) language is English. That is not the problem. The problem is if you type wik. As you said, you can get back the previous behaviour using q=__INPUT__* Yes, it was the firs I did, 'cause nearly to all my search strings Solr gave me no results. It wasn't so severe before the upgrade. :) IMHO, it's better to leave __INPUT__* in default settings and amend documentation with performance/relevancy issues tricks for Solr Suggest tuning. * would be useful for most use cases, and would make Suggest effective, especially for new users who start playing with XWike. I do agree, that in the high load projects it could be essential to tweak default behaviour or turn it off at all. I'd like to hear what others think about this. Do simple users expect the search suggest to perform a prefix match or a standard match? In other words, when a user types in the search suggest, does he type the whole word or just a few letters (a prefix)? Again, note that the previous behaviour was applying prefix matching only for the last word in the search query, not for all of the words in the query. Thanks, Marius Let me know what yo think, Marius Kind regards, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users Kind regards, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Fwd: Re[4]: SearchSuggest parameters in a new syntax gives different behaviour
-- Forwarded message -- From: Dmitry Bakbardin haru_mamb...@mail.ru Date: Fri, Apr 4, 2014 at 2:19 AM Subject: Re[4]: [xwiki-users] SearchSuggest parameters in a new syntax gives different behaviour To: Marius Dumitru Florea mariusdumitru.flo...@xwiki.com Hi, Marius! See below. Thu, 3 Apr 2014 18:03:50 +0300 от Marius Dumitru Florea mariusdumitru.flo...@xwiki.com: On Wed, Apr 2, 2014 at 2:03 PM, Dmitry Bakbardin haru_mamb...@mail.ru wrote: Hi, Marius! See below. Wed, 2 Apr 2014 10:41:32 +0300 от Marius Dumitru Florea mariusdumitru.flo...@xwiki.com: On Wed, Apr 2, 2014 at 9:53 AM, Marius Dumitru Florea mariusdumitru.flo...@xwiki.com wrote: Hi Dmitry, On Mon, Mar 31, 2014 at 5:33 AM, Dmitry Bakbardin haru_mamb...@mail.ru wrote: Hi, all! 5.2 - 5.4.3 Upgrade Xwiki.SearchSuggest objects were changed It was: type:OBJECT AND (class:XWiki.BlogPostClass) AND objcontent:(__INPUT__*) It is: fq=type:DOCUMENT fq=class:Blog.BlogPostClass qf=object.Blog.BlogPostClass The main difference: - it was __INPUT__* query string and - (as far as I understood) it is __INPUT__ if parameter q is omitted The result is Solr Suggest changes it's behaviour and gives only exact results. To make Search Suggest running as it was, we have to add: q=__INPUT__* Is it done by puprpose or it is a bug and I have to jira it? On purpose. I did it as part of http://jira.xwiki.org/browse/XWIKI-10051 (check the documentation links). The reason I dropped the * (star) is because: (1) Prefix matching is costly If Search Suggest is too costly, we can turn it off completely :) Not if there is a way to improve it. My idea was to offer by default something that performs well, but I agree that it could also be seen as an optimization. (2) The search suggest is not a filter (in the sense that you have a list of item and you type some text and it filters the items starting with that text). Search is more complex. The search text is analysed, stop words are removed, etc. (3) It was a fake prefix matching, because if you typed more words, only the last word was matched as prefix (not the entire text). All the other were analysed. IMHO, suggest means we prefer suggest more than exact search results. What I mean, that all languages wich have declensioin are too sensitive to the __INPUT__* search. Usual use case for such a search is: you enter root of the word and get back suggest of ALL forms of the word. Even in English, which is much less declensionable, singular and plural is the case. E.g. wiki input will give only exact much and won't show wikis. Thus, it makes Solr Sugges much less relevant. typing wiki (without the quotes) definitely matches wikis if the document (default) language is English. That is not the problem. The problem is if you type wik. In my use case: - Default language is Russian - Search needed for comments I didn't find any other solution, besides __INPUT__* search. As you said, you can get back the previous behaviour using q=__INPUT__* Yes, it was the firs I did, 'cause nearly to all my search strings Solr gave me no results. It wasn't so severe before the upgrade. :) IMHO, it's better to leave __INPUT__* in default settings and amend documentation with performance/relevancy issues tricks for Solr Suggest tuning. * would be useful for most use cases, and would make Suggest effective, especially for new users who start playing with XWiki. I do agree, that in the high load projects it could be essential to tweak default behaviour or turn it off at all. I'd like to hear what others think about this. Do simple users expect the search suggest to perform a prefix match or a standard match? In other words, when a user types in the search suggest, does he type the whole word or just a few letters (a prefix)? Prefix is more flexible from search point of view. But, sure it would be interesting to carry out a survey. Again, note that the previous behaviour was applying prefix matching only for the last word in the search query, not for all of the words in the query. IMHO, for Search - yes all words are essential, for suggest, most probably prefix. It is my way of searching. :) Thanks, Marius Let me know what yo think, Marius Kind regards, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users Kind regards, Dmitry Kind regards, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Fwd: Re[4]: SearchSuggest parameters in a new syntax gives different behaviour
Hi, Marius, For search suggest - prefix matching by default. Wed, 23 Apr 2014 19:26:04 +0300 от Marius Dumitru Florea mariusdumitru.flo...@xwiki.com: -- Forwarded message -- From: Marius Dumitru Florea mariusdumitru.flo...@xwiki.com Date: Wed, Apr 23, 2014 at 7:23 PM Subject: Re: Re[4]: [xwiki-users] SearchSuggest parameters in a new syntax gives different behaviour To: Dmitry Bakbardin haru_mamb...@mail.ru No other opinions on this? What do you prefer for search suggest (live search)? prefix matching or full text analysis? Thanks, Marius On Fri, Apr 4, 2014 at 2:19 AM, Dmitry Bakbardin haru_mamb...@mail.ru wrote: Hi, Marius! See below. Thu, 3 Apr 2014 18:03:50 +0300 от Marius Dumitru Florea mariusdumitru.flo...@xwiki.com : On Wed, Apr 2, 2014 at 2:03 PM, Dmitry Bakbardin haru_mamb...@mail.ru wrote: Hi, Marius! See below. Wed, 2 Apr 2014 10:41:32 +0300 от Marius Dumitru Florea mariusdumitru.flo...@xwiki.com : On Wed, Apr 2, 2014 at 9:53 AM, Marius Dumitru Florea mariusdumitru.flo...@xwiki.com wrote: Hi Dmitry, On Mon, Mar 31, 2014 at 5:33 AM, Dmitry Bakbardin haru_mamb...@mail.ru wrote: Hi, all! 5.2 - 5.4.3 Upgrade Xwiki.SearchSuggest objects were changed It was: type:OBJECT AND (class:XWiki.BlogPostClass) AND objcontent:(__INPUT__*) It is: fq=type:DOCUMENT fq=class:Blog.BlogPostClass qf=object.Blog.BlogPostClass The main difference: - it was __INPUT__* query string and - (as far as I understood) it is __INPUT__ if parameter q is omitted The result is Solr Suggest changes it's behaviour and gives only exact results. To make Search Suggest running as it was, we have to add: q=__INPUT__* Is it done by puprpose or it is a bug and I have to jira it? On purpose. I did it as part of http://jira.xwiki.org/browse/XWIKI-10051 (check the documentation links). The reason I dropped the * (star) is because: (1) Prefix matching is costly If Search Suggest is too costly, we can turn it off completely :) Not if there is a way to improve it. My idea was to offer by default something that performs well, but I agree that it could also be seen as an optimization. (2) The search suggest is not a filter (in the sense that you have a list of item and you type some text and it filters the items starting with that text). Search is more complex. The search text is analysed, stop words are removed, etc. (3) It was a fake prefix matching, because if you typed more words, only the last word was matched as prefix (not the entire text). All the other were analysed. IMHO, suggest means we prefer suggest more than exact search results. What I mean, that all languages wich have declensioin are too sensitive to the __INPUT__* search. Usual use case for such a search is: you enter root of the word and get back suggest of ALL forms of the word. Even in English, which is much less declensionable, singular and plural is the case. E.g. wiki input will give only exact much and won't show wikis. Thus, it makes Solr Sugges much less relevant. typing wiki (without the quotes) definitely matches wikis if the document (default) language is English. That is not the problem. The problem is if you type wik. In my use case: - Default language is Russian - Search needed for comments I didn't find any other solution, besides __INPUT__* search. As you said, you can get back the previous behaviour using q=__INPUT__* Yes, it was the firs I did, 'cause nearly to all my search strings Solr gave me no results. It wasn't so severe before the upgrade. :) IMHO, it's better to leave __INPUT__* in default settings and amend documentation with performance/relevancy issues tricks for Solr Suggest tuning. * would be useful for most use cases, and would make Suggest effective, especially for new users who start playing with XWiki. I do agree, that in the high load projects it could be essential to tweak default behaviour or turn it off at all. I'd like to hear what others think about this. Do simple users expect the search suggest to perform a prefix match or a standard match? In other words, when a user types in the search suggest, does he type the whole word or just a few letters (a prefix)? Prefix is more flexible from search point of view. But, sure it would be interesting to carry out a survey. Again, note that the previous behaviour was applying prefix matching only for the last word in the search query, not for all of the words in the query. IMHO, for Search - yes all words are essential, for suggest, most probably prefix. It is my way of searching. :) Thanks, Marius Let me know what yo think, Marius Kind regards, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users Kind regards, Dmitry Kind regards, Dmitry ___ users mailing
[xwiki-users] Fwd: Re[4]: SearchSuggest parameters in a new syntax gives different behaviour
-- Forwarded message -- From: Marius Dumitru Florea mariusdumitru.flo...@xwiki.com Date: Wed, Apr 23, 2014 at 7:23 PM Subject: Re: Re[4]: [xwiki-users] SearchSuggest parameters in a new syntax gives different behaviour To: Dmitry Bakbardin haru_mamb...@mail.ru No other opinions on this? What do you prefer for search suggest (live search)? prefix matching or full text analysis? Thanks, Marius On Fri, Apr 4, 2014 at 2:19 AM, Dmitry Bakbardin haru_mamb...@mail.ru wrote: Hi, Marius! See below. Thu, 3 Apr 2014 18:03:50 +0300 от Marius Dumitru Florea mariusdumitru.flo...@xwiki.com: On Wed, Apr 2, 2014 at 2:03 PM, Dmitry Bakbardin haru_mamb...@mail.ru wrote: Hi, Marius! See below. Wed, 2 Apr 2014 10:41:32 +0300 от Marius Dumitru Florea mariusdumitru.flo...@xwiki.com: On Wed, Apr 2, 2014 at 9:53 AM, Marius Dumitru Florea mariusdumitru.flo...@xwiki.com wrote: Hi Dmitry, On Mon, Mar 31, 2014 at 5:33 AM, Dmitry Bakbardin haru_mamb...@mail.ru wrote: Hi, all! 5.2 - 5.4.3 Upgrade Xwiki.SearchSuggest objects were changed It was: type:OBJECT AND (class:XWiki.BlogPostClass) AND objcontent:(__INPUT__*) It is: fq=type:DOCUMENT fq=class:Blog.BlogPostClass qf=object.Blog.BlogPostClass The main difference: - it was __INPUT__* query string and - (as far as I understood) it is __INPUT__ if parameter q is omitted The result is Solr Suggest changes it's behaviour and gives only exact results. To make Search Suggest running as it was, we have to add: q=__INPUT__* Is it done by puprpose or it is a bug and I have to jira it? On purpose. I did it as part of http://jira.xwiki.org/browse/XWIKI-10051 (check the documentation links). The reason I dropped the * (star) is because: (1) Prefix matching is costly If Search Suggest is too costly, we can turn it off completely :) Not if there is a way to improve it. My idea was to offer by default something that performs well, but I agree that it could also be seen as an optimization. (2) The search suggest is not a filter (in the sense that you have a list of item and you type some text and it filters the items starting with that text). Search is more complex. The search text is analysed, stop words are removed, etc. (3) It was a fake prefix matching, because if you typed more words, only the last word was matched as prefix (not the entire text). All the other were analysed. IMHO, suggest means we prefer suggest more than exact search results. What I mean, that all languages wich have declensioin are too sensitive to the __INPUT__* search. Usual use case for such a search is: you enter root of the word and get back suggest of ALL forms of the word. Even in English, which is much less declensionable, singular and plural is the case. E.g. wiki input will give only exact much and won't show wikis. Thus, it makes Solr Sugges much less relevant. typing wiki (without the quotes) definitely matches wikis if the document (default) language is English. That is not the problem. The problem is if you type wik. In my use case: - Default language is Russian - Search needed for comments I didn't find any other solution, besides __INPUT__* search. As you said, you can get back the previous behaviour using q=__INPUT__* Yes, it was the firs I did, 'cause nearly to all my search strings Solr gave me no results. It wasn't so severe before the upgrade. :) IMHO, it's better to leave __INPUT__* in default settings and amend documentation with performance/relevancy issues tricks for Solr Suggest tuning. * would be useful for most use cases, and would make Suggest effective, especially for new users who start playing with XWiki. I do agree, that in the high load projects it could be essential to tweak default behaviour or turn it off at all. I'd like to hear what others think about this. Do simple users expect the search suggest to perform a prefix match or a standard match? In other words, when a user types in the search suggest, does he type the whole word or just a few letters (a prefix)? Prefix is more flexible from search point of view. But, sure it would be interesting to carry out a survey. Again, note that the previous behaviour was applying prefix matching only for the last word in the search query, not for all of the words in the query. IMHO, for Search - yes all words are essential, for suggest, most probably prefix. It is my way of searching. :) Thanks, Marius Let me know what yo think, Marius Kind regards, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users Kind regards, Dmitry Kind regards, Dmitry ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Using XWiki without dynamic extension manager features
Hi Sam, Once XWiki's properly installed with the default content in your main wiki, you can deactivate the extension manager and distribution wizard in WEB-INF/xwiki.properties. XWiki will still function with the exception of being able to install extensions. Ludovic 2014-04-23 19:22 GMT+02:00 Sam McCall sammcc...@google.com: Hi xwiki-users, When I start up XWiki, it appears to fetch java packages from the a maven repository (nexus.xwiki.org). This happens without installing any extensions etc. Is this expected? Is there a way to install and configure XWiki such that a static codebase is used, and packages are never fetched? I only need a pretty simple set of functionality: - Basic page editing - Storage using a JDBC driver - Rendering support for a few markups, e.g. markdown - Authorization using a custom backend Cheers, Sam ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Using XWiki without dynamic extension manager features
No it does not fetch any extension. It just try to get more informations about jar it could find in the classpath from the extension reposirories. You can simply tell it it does not have any repository in xwiki.properties if you really want it to do do those requests. On Wed, Apr 23, 2014 at 7:51 PM, Ludovic Dubost ludo...@xwiki.com wrote: Hi Sam, Once XWiki's properly installed with the default content in your main wiki, you can deactivate the extension manager and distribution wizard in WEB-INF/xwiki.properties. XWiki will still function with the exception of being able to install extensions. Ludovic 2014-04-23 19:22 GMT+02:00 Sam McCall sammcc...@google.com: Hi xwiki-users, When I start up XWiki, it appears to fetch java packages from the a maven repository (nexus.xwiki.org). This happens without installing any extensions etc. Is this expected? Is there a way to install and configure XWiki such that a static codebase is used, and packages are never fetched? I only need a pretty simple set of functionality: - Basic page editing - Storage using a JDBC driver - Rendering support for a few markups, e.g. markdown - Authorization using a custom backend Cheers, Sam ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- Thomas Mortagne ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
