= Description = I did a fulltext search with some keywords and found a "display" bug. In a search result the matches (how many times the keyword is found in the wikipage or document) are displayed on the right side of the found item. I found out that since MoinMoin 1.9.x the searchresult always says 0 matches for pdf documents. -- MarcelHäfner <> I have noticed this problem also on this wiki itself. Try a text search mimetype:application/pdf (python). It will return results showing 0 matches even though the files do contain the word python. Also I have noticed the 0 matches problem on office documents, not just pdfs. -- BenWilliams <> == Steps to reproduce == Use this MoinMoin 1. Search for {{{ moinmoin.wikiwikiweb.de mimetype:pdf }}} in fulltext mode: [[http://moinmo.in/MoinMoinWiki?action=fullsearch&context=180&value=moinmoin.wikiwikiweb.de+mimetype%3Apdf&fullsearch=Text|Link]] 2. See the "0 matches" 3. If you make a test with older Moin 1.8.x its working: --([[http://lotek.heavy.ch/Index?action=fullsearch&context=180&value=mimetype%3Apdf+nato&fullsearch=Text|example]])-- I upgraded to 1.9.x anyway... == Example == See the matches 0 for pdf documents... {{attachment:screenshot.png}} == Component selection == ## Where you think is this bug happening ? (general, plugin [plugin name], theme [theme name], ... * Xapian (Xappy?) / Display Search Results == Details == ## If you got a traceback, please save the traceback page as html and attach here: ## [[attachment:traceback.html]] ## if the bug is in this wiki, just kill the table and write: This Wiki. ## If a traceback is not available, please fill in the details here: || '''!MoinMoin Version''' || 1.9.x || || '''OS and Version''' || this Wiki || || '''Python Version''' || || || '''Server Setup''' || || || '''Server Details''' || || || '''Language you are using the wiki in''' (set in the browser/UserPreferences) || || == Workaround == ## How to deal with the bug until it is fixed * Use older 1.8.x MoinMoin Version = Discussion = Maybe because Xappy was in 1.9.0 introduced Isn't that "0 matches" referring to matches of a search word within the content of the document? The stuff you found had a match in the document name (not content) and document type. * yes the matches should display how many times the search wort was found within the title or / and content of the document. But since the update from 1.8.x to 1.9.x the newer version will always display 0 matches, even if the search word was found "only" in the content... <
> '''Example:''' Search for {{{ moinmoin.wikiwikiweb.de }}} found for example document [[http://moinmo.in/FeatureRequests/CorporateWiki/GuiEditor?action=AttachFile&do=view&target=specifications.pdf&highlight=%28moinmoin.wikiwikiweb.de%29|specifications.pdf]] but 0 matches 1. found document but 0 matches {{attachment:zeromatches.png||width=450px}} 2. but search word is found in the pdf document 2 times {{attachment:found2matches.png||width=450px}} 3. so it should say "2 matches" and not zero * This bug is a bit insidious. It appears that attachments are indexed by looking at the attachment as it would appear with do=view. That adds lots of things to index other than the attachment's contents. All the words in the title will index but so will the words "attachment", "get", "view", "del", "shown", etc. I did a search on '''\[\[attachment''' (does that use the Xapian index?) and it found '''[[attachment''' for every attachment. What is insidious about this bug is that on the results page I can't tell an attachment that actually contains the search term from one that only has the search term in the "view" page since all found pages indicate '''0 matches'''. -BobbyBaucom <> = Plan = ## This part is for Moin``Moin developers: * Priority: * Assigned to: * Status: ---- ## If you are a moin core developer, replace the category to Category* in these cases: ## Category MoinMoinNoBug - if this is not a bug. ## Category MoinMoinBugConfirmed - if you can confirm the bug on current code. ## Category MoinMoinBugFixed - after the bug is fixed in current code. CategoryMoinMoinBug