FAQ Search giving no results

It seems that the FAQ Search is not functionning : it gives no results even if the word I type exists in several FAQs of the space.

In fact, it seems to me it was functionning, then I made what was proposed on the dedicated page ( https://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ%20Application ) to create a multiple FAQ : (1) Editing that space’s WebHome page and adding an Object of type FAQCode.FAQHomeClass and then (2) Copy the search page FAQ.FAQSearch to that space.
But I was not satisfied to still have a FAQ space in FAQ.WebHome so I deleted the page and the search page. I don’t know if it can explain. Now I recreated back these pages, but it does not make the searck work better.

Do you have ideas ? I can try and reinstall the FAQ extension, but I fear to loose all my FAQs (77 in a space and 50 more in another space)

I must add that I just tried to create a FAQ in the FAQ.WebHome , and the search works there ! So it’s only in the other FAQ spaces that it is not working properly.
Also, I suspected that it could be a problem with my space name with a " " (a space) included, I created a new FAQ space with no " " in its name, and the search is not working either.

Hi gumn, By default the FAQ application seems to search only in a specific space (see declaration "space_exact:$doc.space" in page FAQCode.FAQSearch). Removing this search criteria should let you search for FAQs in any space. Let us know how it goes?


Dear slauriere,
That’s interesting, but:

  • when I try to comment the line with ## before, it breaks the macro.
  • I’d like to search not in any space but in the space where the search is located (several - in fact 2 for the moment - in this wiki)

Please tell me more about this !

You could give a try to the following criteria for searching across several specific spaces:

 'space_exact:space1 OR space_exact:space2'


Hello all,

having solved this in the past, I know that there is a problem with the search form displayed on the homepage of your FAQ spaces: it always points to the FAQ.FAQSearch page instead of the search page that you just copied in your new FAQ space.
So, do the following (I will need to contribute this in the application at some point):

  • undo the changes on the search conditions in FAQSearch, the script is fine as is
  • go to FAQCode.FAQHomeSheet , edit in wiki mode
  • approx at line 33, you’ll find somethng like this:
    <form action="$xwiki.getURL('FAQ.FAQSearch')" class="xformInline">
  • replace this line with
    #set($searchDocumentRef = $services.model.createDocumentReference('FAQSearch', $doc.documentReference.parent))
    <form action="$xwiki.getURL($searchDocumentRef)" class="xformInline">

This should make the search form on the homepage of the your new FAQ spaces point to the good search page that searches in the right space.



Thanks @lucaa , however the code is already set as you proposed !

In this case the best would be to describe the exact problem you have, with the steps you’re taking and the things you see on the screen, with screenshots - you can black the areas of the screen that contain sensitive content.
I made a couple of assumptions in my answer, in order to be able to help we need to confirm or infirm those assumptions.

Please include the URLs in the screenshots.

If I understand correctly, you do see a correct search UI, it’s just that you have 0 results in that UI instead of the pages you expect to find, right?

Note that the search behaviour can also depend a lot on the language settings of the wiki and of those pages, which impact how they’re indexed and how they’re found. If you’re making a global wiki search (using the UI from the top navigation bar), are those pages found or they’re not found in that case either?

It’s exactly as you guessed : I launch the search and get 0 results - may I be in the specific FAQ space or in the global FAQ search. The global wiki search is working properly in contrast.
Our wiki is set in French ! It may explain things.
Do you still need screenshots ?
Many thanks !!

The fact that you can find them in the global search indicates that it’s probably not a language issue (or at least one that can be handled, since it works for the global search).

Even more, yes :slight_smile:

Thank you so much!
Do you know this fix will rewrited after update xwiki?

Ok @lucaa , here you are ! I used the word “fichier” that can be seen in the second FAQ so at least this one should show up.
Many thanks !

Apparently, according to @gumn’s information and to my verification, this change is already in the FAQ application , it was done as https://jira.xwiki.org/browse/FAQ-21 and it’s released in version 8.4 of the FAQ application.

@gumn : ok, I see better now the scenario we’re talking about.

According to my tests, there is an issue with FAQ spaces that have whitespaces in the names, it’s https://jira.xwiki.org/browse/FAQ-29 (I also managed to reproduce it) . If it suits you, you can try to rename your FAQ space and it should work - it’s strange that you said you tried that and it didn’t do the job, maybe double-check the rename? - or you can wait for the fix…

1 Like

hello, i used Xwiki 12.10.7 and i needed to inject your solution manual (it was not in core code of page)

hello, i used Xwiki 12.10.7 and i needed to inject your solution manual (it was not in core code of page)

The solution here was involving a modification of the FAQ application, which is an application that is installed on top of the XWiki Standard base, from extension manager. The 2 are rather independent (FAQ application needs the XWiki Standard to work but is not part of it) so they’re versioned independently. 12.10.7 you are mentioning is the version of the XWiki Standard, the 8.4 I am mentioning is the version of the FAQ application. So you need to check the version of the FAQ application you have installed (from the administration, from extension manager).

Enjoy XWiki,

Thank you! May be problem in old version or in Demo flavor Xwiki.

Now it works after renaming the FAQ spaces, the wiki underwent some updates, maybe that explains why it is better now.
Many thanks @lucaa !!!