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

[xwiki-users] PDF Macro unable to view pdf fullscreen unless uploaded by user with programming rights
by Faizel Dakri 06 May '14

06 May '14

New Xwiki user here and first time post. I am very impressed with the XWiki platform. We are using it for our company intranet and it has been able to handle just about everything that I've wanted and without too much pain. A bit of a learning curve, but I think I have a much better grasp of it now. That said, I have a strange issue that I've been able to confirm on two different instances of XWiki (both 5.4.4 and 5.4.3). I am using the PDF Embed Object macro to display PDF attachments inline, however the ability to view those PDFs full screen in the browser is hampered (I have users on IE 9, so the newer pdf.js based viewers won't work for me). Here's what I'm seeing: I have a test user that has edit rights on a page. They can create a page, edit it and upload an attachment to the page. They use the pdf embed object macro like so: {{pdf filename="somefile.pdf" /}} This macro uses the <object> tag to display the PDF inline, however the "VIEW THIS PDF FULL SCREEN" button is just a hyperlink like so: <a href="/xwiki/bin/download/MySpace/MyPage/somefile.pdf">View this PDF full screen</a> The PDF is displayed inline just fine with the object tag, however the button to view the pdf fullscreen doesn't seem to work properly if the user that uploaded the attachment didn't have programming rights when the file was uploaded. When that same test user views the page and clicks the "VIEW THIS PDF FULL SCREEN" button, the file is actually downloaded rather than viewed in the browser. My guess is that something in the server is setting the content-disposition differently based on the rights? If I give that user programming rights after they've uploaded the file, they still cannot view the file inline (the file is still downloaded rather than viewed inline). However, if that user now tries to upload the same file again (now that they have programming rights), then the button will properly show the full screen PDF inline. Has anyone seen this behavior or know of a workaround? Thanks for any advice or pointers! Here's my setup: XWiki 5.4.4 (affects 5.4.3 as well) Mac OS X 10.9.2 Apache 2.2.26 Tomcat 7.0.52 (with mod_jk connector) PostgreSQL 9.3 F -- Faizel Dakri listfez(a)dakri.com

2 2

Re: [xwiki-users] Java exception on startup relating to hibernate
by vincent＠massol.net 06 May '14

06 May '14

Glad it fixed it! -Vincent PS: Next time please reply to the list so that others know your problem is fixed :) On 6 May 2014 at 15:08:06, mctozzy(a)gmail.com (mctozzy(a)gmail.com) wrote: Thanks Vincent that fixed it (or should I say worked around it). MT On 6/05/2014 10:24 PM, vincent(a)massol.net wrote: Hi, Actually this warning message is pretty poor. I’ve updated the sources with this new message: "Could not find a QueryExecutor with hint [{}] which is the hint for the storage engine, defined in your XWiki configuration under the [xwiki.store.main.hint] property. The default QueryExecutor will be used instead. Reason: [Can't find descriptor for the component [role = [interface org.xwiki.query.QueryExecutor] hint = [hibernate]]]" I hope it makes it slighty easier to understand… ;) So it seems we have a bug in our code. To work around it and till we fix it, I’d suggest you comment out the “xwiki.store.main.hint” property in your xwiki.cfg file and it should work fine. Thanks -Vincent On 6 May 2014 at 14:05:52, mctozzy(a)gmail.com (mctozzy@gmail.com(mailto:mctozzy@gmail.com)) wrote: > Why am I getting this warning? Things seem to be working ok otherwise.... > > 2014-05-06 11:58:05,333 [http://localhost:8080/bin/view/Main/] WARN > onfiguredQueryExecutorProvider - Could not find a QueryExecutor with > hint hibernate which is the hint for the storage engine. the default > QueryExecutor will not be used instead. > org.xwiki.component.manager.ComponentLookupException: Can't find > descriptor for the component [role = [interface > org.xwiki.query.QueryExecutor] hint = [hibernate]]

1 0

[xwiki-users] ProxyPass to xwiki / name based vhost wikis
by Martin Hamant 06 May '14

06 May '14

Hi, I'm trying to set up an apache virtualhost with transparent proxy to a wiki of an xwiki farm (which farm resides on a local tomcat container). The main requirement here is I want the xwiki webapp path NEVER to appear anywhere in the URL - this is the point why I am using name based virtualhost. http://projtest.sub.domain.com should be the home page of the wiki that is available within the /xwikiproj context of the container, so when requesting http://projtest.sub.domain.com , I want the WebHome page displayed with the URLhttp://projtest.sub.domain.com/bin/view/Main/WebHome in the browser. With the configuration below, I get redirected to http://projtest.sub.domain.com/xwikiproj/bin/view/Main/WebHome. However I see that xwiki homepage logo link (upper left corner) is formed correctly to http://projtest.sub.domain.com/bin/view/Main/WebHome and I can get back to Home by clicking that link. I've set xwiki.cfg like follow: xwiki.virtual.usepath=0 xwiki.webapppath=/ <VirtualHost *> ServerName projtest.sub.domain.com ProxyPreserveHost on ProxyPassReverseCookiePath /xwikiproj / ProxyPass / http://localhost:8080/xwikiproj/ retry=5 ProxyPassReverse / http://localhost:8080/xwikiproj/ </VirtualHost> Going a little deeper, I see that http://projtest.sub.domain.com/ returns a 302 with location header set to 'h|ttp://projtest.projects.ow2.org/xwikiproj/bin/view/Main/'| so I guess xwiki somehow adding "xwikiproj" to the 'Location' header but I don't understand why and how I can handle it ! Any idea ? Thanks ! Martin

2 2

[xwiki-users] Java exception on startup relating to hibernate
by mctozzy＠gmail.com 06 May '14

06 May '14

Why am I getting this warning? Things seem to be working ok otherwise.... 2014-05-06 11:58:05,333 [http://localhost:8080/bin/view/Main/] WARN onfiguredQueryExecutorProvider - Could not find a QueryExecutor with hint hibernate which is the hint for the storage engine. the default QueryExecutor will not be used instead. org.xwiki.component.manager.ComponentLookupException: Can't find descriptor for the component [role = [interface org.xwiki.query.QueryExecutor] hint = [hibernate]]

2 1

[xwiki-users] Newbie question [5.4.4]: Skinning the top menu bar on subwikis
by mctozzy＠gmail.com 06 May '14

06 May '14

For some reason, the appearance of the top menu bar is different for a subwiki than the main wiki. What is controlling this? I'd like the appearance of the way it is in the main wiki to be reflected in the subwikis too. MT

2 1

[xwiki-users] Fwd: Re: Solr search suggestion auto-complete
by Dmitry Bakbardin 05 May '14

05 May '14

Hi, Michael! Your are welcome! Hi, Marius! As for this: "But should the general look&feel be persistent across different search engines? Just a suggestion, but this would also make a real neat option for the search, sth. like "search while tying", for example." Marius, as a proposal: in the UI, Search Suggest section search options could be added. E.g. - exact match search: __INPUT__ - prefix search: __INPUT__* - prefix and suffix search: *__INPUT__* - turn SuggestSearch off Is it worth doing? -------- Пересылаемое сообщение -------- От кого: Michael Bußler <michael.bussler(a)googlemail.com> Кому: Dmitry Bakbardin <haru_mamburu(a)mail.ru> Дата: Sat, 3 May 2014 15:39:38 +0200 Тема: Re: [xwiki-users] Solr search suggestion auto-complete Thank you, that's exactly what I was looking for! About the default behaviour, its the first time I use solr, so I don't know much about its history. But should the general look&feel be persistent across different search engines? Just a suggestion, but this would also make a real neat option for the search, sth. like "search while tying", for example. Anyway, thank you so much for the quick response and keep the good work!! Michael Am 02.05.2014 16:48 schrieb "Dmitry Bakbardin" < haru_mamburu(a)mail.ru >: > Hi, Michael! > >The same problem I had. It could be fixed as following: > >Edit Xwiki.SearchSuggest directly in Object Editor and add one more string to each search configuration where you need prefix search: >q=__INPUT__* > >E.g. for Blog it would look like this >q=__INPUT__* >fq=type:DOCUMENT >fq=class:Blog.BlogPostClass >qf=object.Blog.BlogPostClass > >Or you can do the same via UI from Search Suggest section in XWikiPreferences: http://yourdomain.com/admin/XWiki/XWikiPreferences?editor=globaladmin&secti… > >To make it running, I had to stop and start SolrSuggest (or restart XWiki). Hope it helps. > >Marius, looks like, we have one more vote for keeping old behavior in default Solr Suggest settings. > > > >Fri, 2 May 2014 10:05:31 +0200 от Michael Bußler < michael.bussler(a)googlemail.com >: >>Hi there, >> >>I've just moved my wiki to a different Server and upgraded there to XWiki >>Enterprise 5.4.4. I've also switched to solr search engine. It's really >>awesome work you did there, and I definitively want to use Solr search >>because to the much better results page. :) >> >>But regrettably, I've got an issue with the search suggestion feature to >>report: Before upgrading, I used Lucene, which gives me this really nice >>feature of searching and making suggestions while I'm typing into the >>search-box on the upper right. This doesn't happen anymore with solr >>search, as suggestions are only made, if there is a 100% match with the >>query somewhere in the doc or attachment. >> >>It may be because of how the suggestion feature creates queries: With >>lucene, the input is always extended by an asterik, like __INPUT__*. So, >>I've tried to add an asterik to my incomplete search query for Solr-search, >>and it gives me exactly, what I want, except that I have to insert the '*' >>always by hand at the end. Then, I've tried to add the asterik somewhere in >>the Solr search suggestion query in XWikiPreferences, but didn't manage to >>get it right. >> >>Do you have an idea, or maybe know, how I can get back the old behaviour >>with lucene search? >> >>You can also visit the wikis and try for yourself: >>Old page with Lucene-Search: http://www2.wikiderm.de >>New page with Solr-Search: http://www.wikiderm.de >> >>For example, try to search for "atop" and see whats happening.. >> >>Best regards, >>Michael >>_______________________________________________ >>users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users > > >Kind regards, > >Dmitry >_______________________________________________ >users mailing list >users(a)xwiki.org >http://lists.xwiki.org/mailman/listinfo/users ---------------------------------------------------------------------- Kind regards, Dmitry

2 2

[xwiki-users] Office Importer & LibreOffice 4.x : images are not correctly imported
by Alexandre FLAMENT 05 May '14

05 May '14

Hi, Using Tomcat 7 LibreOffice 4.2 (also tested with 4.1) XWiki 5.4.4 (Libreoffice externally managed) When I import a Word document, the images are not correctly imported (the URLs seem to be a reference encoded in base64, but there is no attached document) Using OpenOffice 3.4.4, it works. Is there something to configure in LibreOffice 4.x ? -- Alexandre

2 3

Re: [xwiki-users] Using XWiki without dynamic extension manager features
by Ludovic Dubost 05 May '14

05 May '14

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 <sammccall(a)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(a)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

6 13

[xwiki-users] Solr search suggestion auto-complete
by Michael Bußler 05 May '14

05 May '14

Hi there, I've just moved my wiki to a different Server and upgraded there to XWiki Enterprise 5.4.4. I've also switched to solr search engine. It's really awesome work you did there, and I definitively want to use Solr search because to the much better results page. :) But regrettably, I've got an issue with the search suggestion feature to report: Before upgrading, I used Lucene, which gives me this really nice feature of searching and making suggestions while I'm typing into the search-box on the upper right. This doesn't happen anymore with solr search, as suggestions are only made, if there is a 100% match with the query somewhere in the doc or attachment. It may be because of how the suggestion feature creates queries: With lucene, the input is always extended by an asterik, like __INPUT__*. So, I've tried to add an asterik to my incomplete search query for Solr-search, and it gives me exactly, what I want, except that I have to insert the '*' always by hand at the end. Then, I've tried to add the asterik somewhere in the Solr search suggestion query in XWikiPreferences, but didn't manage to get it right. Do you have an idea, or maybe know, how I can get back the old behaviour with lucene search? You can also visit the wikis and try for yourself: Old page with Lucene-Search: http://www2.wikiderm.de New page with Solr-Search: http://www.wikiderm.de For example, try to search for "atop" and see whats happening.. Best regards, Michael

3 2

[xwiki-users] Collapsed panels without java-script
by Gerritjan Koekkoek 03 May '14

03 May '14

As you know some internet people do not use javascript. The most important of all are the search-engines. Now we have modified the default behavior of panels If panel is of type navigation it will load with the following div <div class="panel collapsed MoreAboutCdls Navigation"> ... </div> Other wise it will load as <div class="panel expanded Diaporama Information"> ... </div> The result is that navigation panels that contain mostly links to other parts of the site show only the titlebar, when user clicks on that it expands and reveals the navigation links; we believe this reduces screen clutter. My question is two: 1) When java script is turned of there is no way a user can see the links. What would be the effect on search engines, will they see the links? I see the html with the links when I use html-source code, it is just hidden by the CSS! 2) Disabled people that are deaf or blind often use browsers without javascript. How could I have achieved the same with some changes. I would prefer the panel to load 'expanded' then with javascript that would set all panels of type Navigation to collapsed after the page load. But allow the user to click on the header and set it to expanded. Gerritjan

2 1