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
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]]
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]]
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
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§i…
>
>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
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
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
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
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