- 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 23 Apr '14

23 Apr '14

---------- 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

1 0

[xwiki-users] Fwd: Re[4]: SearchSuggest parameters in a new syntax gives different behaviour
by Marius Dumitru Florea 23 Apr '14

23 Apr '14

---------- 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

1 0

[xwiki-users] Fwd: Re[2]: SearchSuggest parameters in a new syntax gives different behaviour
by Marius Dumitru Florea 23 Apr '14

23 Apr '14

---------- 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

1 0

[xwiki-users] Fwd: Re[2]: SearchSuggest parameters in a new syntax gives different behaviour
by Marius Dumitru Florea 23 Apr '14

23 Apr '14

---------- 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

1 0

[xwiki-users] PDF export - customizing table of content
by Nicolas Sanitas 23 Apr '14

23 Apr '14

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 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

2 3

[xwiki-users] Just Map It!
by Danilo Amaral de Oliveira 23 Apr '14

23 Apr '14

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.

1 0

[xwiki-users] [ANN] XWiki 6.0 Release Candidate 1 released
by Thomas Mortagne 23 Apr '14

23 Apr '14

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

3 2

[xwiki-users] newsletter extension doesn't work
by Pascal BASTIEN 22 Apr '14

22 Apr '14

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

1 0

[xwiki-users] MyXWiki.org upgrade to XWiki 5.4.4
by Guillaume Fenollar 22 Apr '14

22 Apr '14

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

1 0

[xwiki-users] Menu Application rendering content
by Jeremie BOUSQUET 22 Apr '14

22 Apr '14

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

3 5