- xwiki-users@xwiki.org - lists.xwiki.org

[xwiki-users] Fwd: Re[4]: SearchSuggest parameters in a new syntax gives different behaviour

by Marius Dumitru Florea

---------- Forwarded message ---------- From: Marius Dumitru Florea <mariusdumitru.florea(a)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_mamburu(a)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_mamburu(a)mail.ru> wrote: > Hi, Marius! > > See below. > > > Thu, 3 Apr 2014 18:03:50 +0300 от Marius Dumitru Florea > <mariusdumitru.florea(a)xwiki.com>: > > On Wed, Apr 2, 2014 at 2:03 PM, Dmitry Bakbardin <haru_mamburu(a)mail.ru> > wrote: >> Hi, Marius! >> >> See below. >> >> >> Wed, 2 Apr 2014 10:41:32 +0300 от Marius Dumitru Florea >> <mariusdumitru.florea(a)xwiki.com>: >> >> On Wed, Apr 2, 2014 at 9:53 AM, Marius Dumitru Florea >> <mariusdumitru.florea(a)xwiki.com> wrote: >>> Hi Dmitry, >>> >>> On Mon, Mar 31, 2014 at 5:33 AM, Dmitry Bakbardin <haru_mamburu(a)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(a)xwiki.org >>>> http://lists.xwiki.org/mailman/listinfo/users >> >> >> >> Kind regards, >> >> Dmitry > > > > Kind regards, > > Dmitry

11 years, 8 months

1
0
0 0

[xwiki-users] Fwd: Re[4]: SearchSuggest parameters in a new syntax gives different behaviour

by Marius Dumitru Florea

---------- Forwarded message ---------- From: Dmitry Bakbardin <haru_mamburu(a)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.florea(a)xwiki.com> Hi, Marius! See below. Thu, 3 Apr 2014 18:03:50 +0300 от Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>: On Wed, Apr 2, 2014 at 2:03 PM, Dmitry Bakbardin <haru_mamburu(a)mail.ru> wrote: > Hi, Marius! > > See below. > > > Wed, 2 Apr 2014 10:41:32 +0300 от Marius Dumitru Florea > <mariusdumitru.florea(a)xwiki.com>: > > On Wed, Apr 2, 2014 at 9:53 AM, Marius Dumitru Florea > <mariusdumitru.florea(a)xwiki.com> wrote: >> Hi Dmitry, >> >> On Mon, Mar 31, 2014 at 5:33 AM, Dmitry Bakbardin <haru_mamburu(a)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(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/users > > > > Kind regards, > > Dmitry Kind regards, Dmitry

11 years, 8 months

1
0
0 0

[xwiki-users] Fwd: Re[2]: SearchSuggest parameters in a new syntax gives different behaviour

by Marius Dumitru Florea

---------- Forwarded message ---------- From: Marius Dumitru Florea <mariusdumitru.florea(a)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_mamburu(a)mail.ru> On Wed, Apr 2, 2014 at 2:03 PM, Dmitry Bakbardin <haru_mamburu(a)mail.ru> wrote: > Hi, Marius! > > See below. > > > Wed, 2 Apr 2014 10:41:32 +0300 от Marius Dumitru Florea > <mariusdumitru.florea(a)xwiki.com>: > > On Wed, Apr 2, 2014 at 9:53 AM, Marius Dumitru Florea > <mariusdumitru.florea(a)xwiki.com> wrote: >> Hi Dmitry, >> >> On Mon, Mar 31, 2014 at 5:33 AM, Dmitry Bakbardin <haru_mamburu(a)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(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/users > > > > Kind regards, > > Dmitry

11 years, 8 months

1
0
0 0

[xwiki-users] Fwd: Re[2]: SearchSuggest parameters in a new syntax gives different behaviour

by Marius Dumitru Florea

---------- Forwarded message ---------- From: Dmitry Bakbardin <haru_mamburu(a)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.florea(a)xwiki.com> Hi, Marius! See below. Wed, 2 Apr 2014 10:41:32 +0300 от Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>: On Wed, Apr 2, 2014 at 9:53 AM, Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> wrote: > Hi Dmitry, > > On Mon, Mar 31, 2014 at 5:33 AM, Dmitry Bakbardin <haru_mamburu(a)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(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users Kind regards, Dmitry

11 years, 8 months

1
0
0 0

[xwiki-users] PDF export - customizing table of content

by Nicolas Sanitas

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 , 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 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Thread.java:744) Caused by: com.xpn.xwiki.XWikiException: Error number 12002 in 12: Exception while exporting pdf at com.xpn.xwiki.pdf.impl.PdfExportImpl.createException(PdfExportImpl.java:569) at com.xpn.xwiki.pdf.impl.PdfExportImpl.renderXSLFO(PdfExportImpl.java:343) at com.xpn.xwiki.pdf.impl.PdfExportImpl.exportXHTML(PdfExportImpl.java:271) at com.xpn.xwiki.pdf.impl.PdfExportImpl.exportHtml(PdfExportImpl.java:224) at com.xpn.xwiki.pdf.impl.PdfExportImpl.export(PdfExportImpl.java:210) at com.xpn.xwiki.web.ExportAction.export(ExportAction.java:223) at com.xpn.xwiki.web.ExportAction.render(ExportAction.java:79) ... 35 more Caused by: javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: "{http://www.w3.org/1999/XSL/Format}block" is not a valid child of "fo:root"! (See position 1:1604) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:502) at com.xpn.xwiki.pdf.impl.PdfExportImpl.renderXSLFO(PdfExportImpl.java:327) ... 40 more Caused by: org.apache.fop.fo.ValidationException: "{http://www.w3.org/1999/XSL/Format}block" is not a valid child of "fo:root"! (See position 1:1604) at org.apache.fop.events.ValidationExceptionFactory.createException(ValidationExceptionFactory.java:38) at org.apache.fop.events.EventExceptionManager.throwException(EventExceptionManager.java:54) at org.apache.fop.events.DefaultEventBroadcaster$1.invoke(DefaultEventBroadcaster.java:175) at com.sun.proxy.$Proxy60.invalidChild(Unknown Source) at org.apache.fop.fo.FONode.invalidChildError(FONode.java:534) at org.apache.fop.fo.FONode.invalidChildError(FONode.java:517) at org.apache.fop.fo.pagination.Root.validateChildNode(Root.java:133) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:267) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:171) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1073) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:485) ... 41 more

11 years, 8 months

2
3
0 0

[xwiki-users] Just Map It!

by Danilo Amaral de Oliveira

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.oliveira(a)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.

11 years, 8 months

1
0
0 0

[xwiki-users] [ANN] XWiki 6.0 Release Candidate 1 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 6.0 Release Candidate 1. First and hopefully last release candidate before 6.0 final. This release contain mostly improvements on Distribution Wyzard and new experimental Flamingo skin. 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/ReleaseNotesXWiki60RC1 Thanks -The XWiki dev team

11 years, 8 months

3
2
0 0

[xwiki-users] newsletter extension doesn't work

by Pascal BASTIEN

Hello I tested newsletter extension 1.0.1 on xwiki 5.4.2 and 6.0RC1. http://extensions.xwiki.org/xwiki/bin/view/Extension/Newsletter+Application I followed the instruction, create instance but the scheduler doesn't send mail at users... (My user subscribe at my newsletter and xwiki.mailsender.sendHtmlMessage work well) On Xwiki 5.4.2 the scheduler doesn't lauch my test job but on 6.0RC1, the scheduler work well with this test job. Then, I copy/paste newsletter job code on another page (between {{groovy}}{{/groovy}} and I obtain a lot of errors: <<Failed to execute the [groovy] macro org.xwiki.rendering.macro.MacroExecutionException: Failed to evaluate Script Macro for content [ etc...>> Any ideas of this problem? thxs Pascal B

11 years, 8 months

1
0
0 0

[xwiki-users] MyXWiki.org upgrade to XWiki 5.4.4

by Guillaume Fenollar

Hello all, I'll perform an XWiki upgrade of myxwiki.org farm from 5.2 to 5.4.4, to prevent it from crashing again. It'll start today at 12:30 CEST (GMT+2) and shouldn't take more than two hours. Thank you for your understanding. Guillaume

11 years, 8 months

1
0
0 0

[xwiki-users] Menu Application rendering content

by Jeremie BOUSQUET

Hello, I used the Menu Application [1] to define a horizontal menu, after page header, and it's very nice and very user-friendly. I wonder if it could (easily) be feasible, to have the content ("Menu Structure") of the menu rendered ? My point would be to put some velocity scripting in it, to achieve more dynamic menus (display parts depending on user rights, generate some lists of items, etc). A bit like the jsx/ssx extensions do. I had a look but I didn't find where the "magic" operates :) Thanks, Jeremie [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Menu+Application

11 years, 8 months

3
5
0 0

[xwiki-users] help on sample of using RestFul API to create new page in a xwiki

by Zhihua Zheng

Could anyone can share a exmaple of how to using httpClient 4.3 to put a new page int to a xwiki. I've tried could of times, but failed. All the examples are not with httpClient 4.3. I got error like 401, not authenticated, or 500,HTTP/1.1 500 Internal Server Error <html> <head> <title>Status page</title> </head> <body style="font-family: sans-serif;"> Internal Server Error The server encountered an unexpected condition which prevented it from fulfilling the request You can get technical details <a href=" http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.1">here</a> . Please continue your visit at our <a href="/">home page</a>. </body> </html> Here is my code: package org.cfgr.xwiki; import java.beans.Encoder; import java.io.IOException; import java.io.InputStream; import java.io.StringWriter; import java.net.URLEncoder; import javax.xml.bind.JAXBContext; import javax.xml.bind.JAXBElement; import javax.xml.bind.JAXBException; import javax.xml.bind.Marshaller; import javax.xml.bind.Unmarshaller; import org.apache.commons.codec. EncoderException; import org.apache.commons.codec.binary.Base64; import org.apache.http.HttpEntity; import org.apache.http.auth.AuthSchemeProvider; import org.apache.http.auth.AuthScope; import org.apache.http.auth.Credentials; import org.apache.http.auth.UsernamePasswordCredentials; import org.apache.http.client.ClientProtocolException; import org.apache.http.client.CredentialsProvider; import org.apache.http.client.methods.CloseableHttpResponse; import org.apache.http.client.methods.HttpGet; import org.apache.http.client.methods.HttpPost; import org.apache.http.client.methods.HttpPut; import org.apache.http.client.protocol.HttpClientContext; import org.apache.http.config.Lookup; import org.apache.http.entity.StringEntity; import org.apache.http.impl.client.BasicCredentialsProvider; import org.apache.http.impl.client.CloseableHttpClient; import org.apache.http.impl.client.HttpClients; import xwiki.rest.model.jaxb.ObjectFactory; import xwiki.rest.model.jaxb.Page; import xwiki.rest.model.jaxb.PageSummary; import xwiki.rest.model.jaxb.Pages; public class Importer { public static CloseableHttpClient getClient(String user, String pass){ Credentials defaultcreds = new UsernamePasswordCredentials(user, pass); CredentialsProvider credsProvider = new BasicCredentialsProvider(); credsProvider.setCredentials( new AuthScope("www.chinafgr.com", 8000), new UsernamePasswordCredentials(user, pass)); CloseableHttpClient httpClient = HttpClients.custom() .setDefaultCredentialsProvider(credsProvider) .build(); return httpClient; } public static HttpClientContext createContext(String user, String pass){ CredentialsProvider credsProvider = new BasicCredentialsProvider(); credsProvider.setCredentials( new AuthScope("www.chinafgr.com", 8000), new UsernamePasswordCredentials(user, pass)); HttpClientContext context = HttpClientContext.create(); context.setCredentialsProvider(credsProvider); // context.setAuthSchemeRegistry(authRegistry); // context.setAuthCache(authCache); return context; } // public Space putPage(CloseableHttpClient httpClient, String wiki, String space, Page page){ // // JAXBContext context; // try { // context = JAXBContext.newInstance("org"); // Unmarshaller unmarshaller = context.createUnmarshaller(); // Marshaller marshaller = context.createMarshaller(); // String name = page.getName(); // name = URLEncoder.encode(name, "UTF-8"); // page.setName(name); // page.setXwikiRelativeUrl("http://www.xwiki.org/rel/page"); // HttpPut putMethod = new HttpPut(" http://2.2.2.2:8080/xwiki/rest/wikis/"+ wiki +"/spaces/" + space + "/pages/" + page.getName() ); // putMethod.addHeader("Accept", "application/xml"); // putMethod.addHeader("Accept-Ranges", "bytes"); // Page p = new Page(); // p.setContent(page.getContent()); // p.setTitle(page.getTitle()); // p.setParent(page.getParent()); // JAXBElement<Page> jbe = new ObjectFactory().createPage(p); // StringWriter writer = new StringWriter(); // // marshaller.marshal(jbe, writer); // Fill the StringWriter with the page xml // // System.out.println("WRITER = [[[[" + writer + "]]]]"); // // putMethod.setRequestEntity(new StringRequestEntity(writer.toString(), // "application/xml", "UTF-8")); // // httpClient.execute(putMethod); // JAXBElement obj = (JAXBElement) unmarshaller.unmarshal(putMethod.getResponseBodyAsStream()); // System.out.println("Return is " + obj.getValue()); // } public static void main(String[] args) { CloseableHttpClient httpclient = getClient("admin","admin"); JAXBContext context; try { context = JAXBContext.newInstance("xwiki.rest.model.jaxb"); Unmarshaller unmarshaller = context.createUnmarshaller(); HttpGet getMethod = new HttpGet(" http://www.chinafgr.com:8000/xwiki/rest/wikis/xwiki/spaces/AppTest/pages/We… "); getMethod.addHeader("Accept", "application/xml"); CloseableHttpResponse response = httpclient.execute(getMethod); try { System.out.println("----------------------------------------"); System.out.println(response.getStatusLine()); // Get hold of the response entity HttpEntity entity = response.getEntity(); // If the response does not enclose an entity, there is no need // to bother about connection release if (entity != null) { InputStream instream = entity.getContent(); JAXBElement o = (JAXBElement) unmarshaller.unmarshal(instream); Page page = (Page) o.getValue(); Marshaller marshaller = context.createMarshaller(); // String name = page.getName(); // name = URLEncoder.encode(name, "UTF-8"); // page.setName(name); // page.setXwikiRelativeUrl(" http://www.xwiki.org/rel/page"); HttpPut putMethod = new HttpPut(" http://www.chinafgr.com:8000/xwiki/rest/wikis/xwiki/spaces/wiki/pages/" + "NewPage" ); putMethod.addHeader("Content-Type", "application/xml"); putMethod.addHeader("Accept", "application/xml"); putMethod.addHeader("Authorization", "Basic " + new Base64().encode("Admin:admin".getBytes())); Page p = new Page(); // p.setContent(page.getContent()); // p.setTitle(page.getTitle()); p.setContent("Hello the world"); p.setTitle("ThePAGE"); p.setSyntax("xwiki/2.0"); p.setParent(page.getParent()); JAXBElement<Page> jbe = new ObjectFactory().createPage(p); StringWriter writer = new StringWriter(); marshaller.marshal(jbe, writer); // Fill the StringWriter with the page xml System.out.println("WRITER = [[[[" + writer + "]]]]"); putMethod.setEntity(new StringEntity(writer.toString(), "application/xml", "UTF-8")); response = httpclient.execute(putMethod); System.out.println("----------------------------------------"); System.out.println(response.getStatusLine()); // JAXBElement obj = (JAXBElement) unmarshaller.unmarshal(response.getEntity().getContent()); //System.out.println("Return is " + obj.getValue()); for(;;){ int c=response.getEntity().getContent().read(); if(c<0) break; System.out.print((char)c); } System.out.println(); // Pages page = (Pages)unmarshaller.unmarshal(instream); // for(PageSummary ps:page.getPageSummary()) // System.out.println(ps.getName()); } } finally { response.close(); } } catch (JAXBException e) { e.printStackTrace(); } catch (ClientProtocolException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } } }

11 years, 8 months

2
2
0 0

[xwiki-users] Dynamically create space and add rights and members

by Daniel Ebanja

Hi Developers, i have been trying this the whole time already and decided to ask for help. I want to create a space, a group and add a member to the group. The space should only be viewed by this group. Here is my code till now. The Space is created, the group too and the user login in is added to the group. I can't figure how to assign the rights. The CODE: protected void addUserToGroup(String xwikiname, XWikiContext context) throws XWikiException{ // // Create a group and add the user to the newly created group. BaseClass groupClass = context.getWiki().getGroupClass(context); // Get document representing group DocumentReference groupDocumentReference = new DocumentReference( context.getDatabase(), "myspace", "Testgroup"); XWikiDocument groupDoc = context.getWiki().getDocument( groupDocumentReference, context); BaseClass rightsClass = context.getWiki().getRightsClass(context); if (groupDoc.isNew()) { log.error("Creating Test group"); synchronized (groupDoc) { // Add a member object to document BaseObject memberObj = groupDoc.newXObject( groupClass.getDocumentReference(), context); memberObj.setStringValue("member", xwikiname); BaseObject rights= groupDoc.newXObject(rightsClass.getDocumentReference(),context); rights.setStringValue("groups", "Testgroup"); rights.setStringValue("levels","view"); rights.setStringValue("levels", "edit"); rights.setStringValue("users", ""); rights.setIntValue("allow",1); //groupDoc.getObject("XWiki.XWikiGlobalRights"); groupDoc.setSyntax(Syntax.XWIKI_2_1); groupDoc.setContent("{{include document='XWiki.XWikiGroupSheet' /}}"); // Save modifications context.getWiki().saveDocument(groupDoc, context); } log.error("Added user"+ xwikiname +"to Testgroup"); } } Thanks for any help.

11 years, 8 months

2
3
0 0

[xwiki-users] Stéphane LASSIRE est en congés

by Stéphane LASSIRE

Je serai absent(e) à partir du 21/04/2014 de retour le 28/04/2014. je suis en congés. Je répondrai à vos messages dès mon retour. En cas de problème technique lié aux progiciels du CESAP, veuillez contacter SYNOX au 05 67 34 66 56. Merci

11 years, 8 months

1
0
0 0

[xwiki-users] Request for myxwiki support

by Stefan Taferner

Hello all, Could a kind admin please have a look at selfbus.myxwiki.org? The wiki again takes 15-20 seconds to show a page. It is not as bad as it was when the database migration was running, but it is still barely usable. The other strange thing is that every time an admin logs in the upgrade wizard starts. The upgrade finishes without errors or anything to migrate. Next time it shows up again. This is not such a problem as one can choose to not show the wizard. I only wanted to report the issue - maybe it's of interest for the xwiki developers why this happens. Thanks in advance and have a nice easter weekend, Stefan

11 years, 8 months

2
2
0 0

[xwiki-users] Migrating from HSQLDB to MySQL?

by max_allan

Hello, I can only find one suggestion about migrating between databases, it's from 2006 that refers to an export tool that only works in Firefox. Is there a better way yet? I've got quite a lot of content and users and more importantly than the volume of data I'd like to retain "ownership" metadata and history etc.. But then read a bit about it and thought "Do I need to migrate". I'm assuming if the wiki is not being accessed then a simple filesystem backup will be consistent and recoverable? Should there be any extra indexes or anything else to do for performance tweaks? Would MySQL give me any advantage over HSQLDB? (I'm on 5.0.3 and want to update to 5.4.4 soon.) I distrust a database if I haven't got a whole pile of command line tools I can poke at it with... Max -- View this message in context: http://xwiki.475771.n2.nabble.com/Migrating-from-HSQLDB-to-MySQL-tp7590158.… Sent from the XWiki- Users mailing list archive at Nabble.com.

11 years, 8 months

2
1
0 0

[xwiki-users] securing xwiki MySQL user a little

by Martin Hamant

Hi, It is mentioned in the documentation "Give all privileges to the xwiki user for accessing and creating databases" - because the user to be able to create additional databases for sub-wikis ; but isn't it a little pushy to give *all* the privileges (Grant, reload...) to the xwiki user ? How could I secure the xwiki mysql user account a little more ?

11 years, 8 months

3
5
0 0

[xwiki-users] File Manager Application bug

by Belkhiria Hamza Yazid

Hi, After installing latest version, a new space was created named File manager Application When i click on it I am getting a strange page title, is it supposed to be like this ? $services.localization.render('platform.appwithinminutes.appHomePageTitle', $services.localization.render("filemanager.appname")) Thanks, -- *BHY*

11 years, 8 months

2
1
0 0

[xwiki-users] myxwiki wiki very slow

by Stefan Taferner

Hello all, Could a kind admin please have a look at selfbus.myxwiki.org? The wiki takes several seconds (rather minutes) to show a page. Thanks in advance, Stefan

11 years, 8 months

2
3
0 0

[xwiki-users] [BUG] Do the attachments hustle

by Hamster

Can someone please reproduce these steps? First prepare 2 documents for upload. Let's say 2 MSWord documents, A.doc and B.doc. 1) Create a new page, enter some text 2) Upload A.doc 3) Remove A.doc 4) Upload B.doc 5) Activate the version where you uploaded A.doc (should be version 2.1) 6) Delete the latest version of the page (this *should* take you back to version 4.1 where you uploaded B.doc) Examine the attachments page: It will show A.doc and B.doc (which in my opinion is strange, because I would expect to only find B.doc). Try to open A.doc (this is possible), now try to open B.doc (this is NOT possible). -- View this message in context: http://xwiki.475771.n2.nabble.com/BUG-Do-the-attachments-hustle-tp7589936.h… Sent from the XWiki- Users mailing list archive at Nabble.com.

11 years, 8 months

2
7
0 0

[xwiki-users] Immediate Children not working

by Belkhiria Hamza Yazid

Hi I just copied the code in here http://extensions.xwiki.org/xwiki/bin/view/Extension/Immediate+Children+Pag… into a new navigation panel, it is not showing anything i have the same problem with the Backlinks panel any ideas ? -- *BHY*

11 years, 8 months

3
9
0 0

[xwiki-users] List Children Of Current Document

by Belkhiria Hamza Yazid

Good morning, This snippet is awesome I am asking if there is a way to make it show only the 10 first results (alphabetic for example or just any limited set) and add a link "show full list" that would redirect you to another page with the classic snippet with complete list Does that make any sense ? Best Regards, -- *BHY*

11 years, 8 months

2
4
0 0

[xwiki-users] Activity stream app: failed to execute [velocity] macro

by tduchateau

Hi, I already looked at similar topics but none of them allowed me to solve the issue. I'm having the bellowing issue in the http://my.domain/xwiki/bin/view/Main/WebHome page, i.e. where the activity stream is displayed by default. I'm running the XWIKI ENTERPRISE 5.2.4 WAR inside a Tomcat 7.0.47 container and behind an Apache HTTP server acting as a reverse proxy. OS: CentOS 6.4 Any help would be appreciated. Let me know if you need more information. Regards, Thibault -- View this message in context: http://xwiki.475771.n2.nabble.com/Activity-stream-app-failed-to-execute-vel… Sent from the XWiki- Users mailing list archive at Nabble.com.

11 years, 8 months

2
9
0 0

[xwiki-users] Few problems upgrading from 4.X to 5.4

by gjordis

I recently upgraded our wiki to 5.4 from 4.X installation. I used the same database and ran the migration process. All the pages work fine, but i was left with some issues I was hoping to get some help with. 1. Document tree no longer works. I get a 404 while getting /spaces?r=somenumber and wiki shows error : Server returned TRANSPORT_ERROR with no error message. 2. I cannot modify panels correctly with panel wizard: If I add a new widget to the panel, others may disappear. Or when I add a new widget, 3 widgets may appear, the same 3 every time. 3. Cannot update/uninstall extensions All the extensions I had in the old wiki are shown as installed, but when I try to uninstall them, I get an error saying that they are not installed. So if anyone has come accross any of these issues and has found a fix/workaround for it, I would be grateful to hear of it. -- View this message in context: http://xwiki.475771.n2.nabble.com/Few-problems-upgrading-from-4-X-to-5-4-tp… Sent from the XWiki- Users mailing list archive at Nabble.com.

11 years, 8 months

3
12
0 0

[xwiki-users] [ANN] XWiki 5.4.4 released

by Guillaume "Louis-Marie" Delhumeau

The XWiki development team is proud to announce the availability of XWiki 5.4.4. This is a bugfix release, with some improvements in the wiki creation. 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/ReleaseNotesXWiki544 Thanks -The XWiki dev team

11 years, 8 months

1
0
0 0

[xwiki-users] PDF Viewer Macro for Multiple files in a page

by Belkhiria Hamza Yazid

Hi, Is there a way to use this macro to choose/browse between multiple PDF attachments to a page ? Thanks -- *BHY*

11 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-users