Last modified: 2011-06-14 18:33:12 UTC
This bug is filed as consequence of my observation, that the search when having Extension:Vector fails for certain input values and page titles, reproducible. The description of the bug will be improved as soon as new facts are available. (see also r89900 ) Situation: - having one page: "EVL" in the wiki - input entered into search field: "e", "v", "l" ,(3xbackspace), "E", "V", "EVL" "GET /phase3/api.php?action=opensearch&search=e&limit=10&namespace=0&suggest= HTTP/1.1" 200 13 responses (requests corresponds to the one above) ["e",["EVL"]] (ok) ["ev",[]] ( ***wrong response***, should have been ["ev",["EVL"]] ) ["evl",[]] ( ***wrong response***, should have been ["evl",["EVL"]] ) "GET /phase3/api.php?action=opensearch&search=E&limit=10&namespace=0&suggest= HTTP/1.1" 200 13 responses (requests corresponds to the one above) ["E",["EVL"]] (ok) ["EV",["EVL"]] (ok) ["EVL",["EVL"]] (ok) I added a second page to the wiki: "EVL-Redesign" no full analysis done yet of this problem - strange behaviour again: - new page not part of the suggestion - but after Ctrl-F5, the new page is also present ["e",["EVL","EVL-Redesign"]] ["E",["EVL","EVL-Redesign"]] then I deleted page "EVL-Redesign" "GET /phase3/api.php?action=opensearch&search=e&limit=10&namespace=0&suggest= HTTP/1.1" 200 13 ["e",["EVL","EVL-Redesign"]] (wrong! second page EVl-Redesign does not any exists, but the response comes from the API! cache problem ? ) "GET /phase3/api.php?action=opensearch&search=e&limit=10&namespace=0&suggest= HTTP/1.1" 200 13 ["E",["EVL"]] (ok)
Search suggestions via opensearch suggestion interface are by default case-sensitive, unless an extension has replaced the default raw database prefix lookup with a fancier one that's able to do case-insensitive lookups. For instance: * TitleKey extension adds a case-folded title index table and uses that * our Lucene thingy may have some sort of fancy mode The output you're seeing looks like what I'd expect from a base MediaWiki install.
(In reply to comment #1) > Search suggestions via opensearch suggestion interface are by default > case-sensitive, unless an extension has replaced the default raw database > prefix lookup with a fancier one that's able to do case-insensitive lookups. > > For instance: > * TitleKey extension adds a case-folded title index table and uses that > * our Lucene thingy may have some sort of fancy mode > > The output you're seeing looks like what I'd expect from a base MediaWiki > install. Brion: citing the http://www.mediawiki.org/wiki/API:Opensearch page info box says (verbatim copied): "Get pages whose name case-insensitively match a given string. When limit is reached, results are ordered by number of incoming links." Who's wrong, the text, you or I ? case-IN-sensitively
See also example on that page [ "api", [ "API", "Apiales", "Apiaceae", "Apia", "Apicomplexa", "Apicomplexa lifecycle stages", "Apidae", >>>> "APIA Leichhardt Tigers", <<<< this is a case-IN-sensitive match with the querystring "api" IMO "Apical membrane", "Apical consonant" ] ]
(In reply to comment #2) > (In reply to comment #1) > > Search suggestions via opensearch suggestion interface are by default > > case-sensitive, unless an extension has replaced the default raw database > > prefix lookup with a fancier one that's able to do case-insensitive lookups. > > > > For instance: > > * TitleKey extension adds a case-folded title index table and uses that > > * our Lucene thingy may have some sort of fancy mode > > > > The output you're seeing looks like what I'd expect from a base MediaWiki > > install. > > Brion: > citing the http://www.mediawiki.org/wiki/API:Opensearch page info box says > (verbatim copied): > > "Get pages whose name case-insensitively match a given string. When limit is > reached, results are ordered by number of incoming links." > > Who's wrong, the text, you or I ? case-IN-sensitively Then the documentation is wrong. Case-insensitivity is provided by the TitleKey extension. If you don't have TitleKey but have $wgCapitalLinks = true (the default), one-letter searches will still be case-insensitive because page titles are first-letter case-insensitive ([[dog]] and [[Dog]] are the same, but [[DOg]] and [[Dog]] are not). Re-closing INVALID. I'll fix the documentation.
> Case-insensitivity is provided by the TitleKey extension. If you don't have > TitleKey but have $wgCapitalLinks = true (the default), one-letter searches > will still be case-insensitive because page titles are first-letter > case-insensitive ([[dog]] and [[Dog]] are the same, but [[DOg]] and [[Dog]] are > not). ok, this is fully clear > > Re-closing INVALID. I'll fix the documentation. quick feedback: I always use Brion's TitleKey extension (except in this case where I disabled that temporarily because I noticed a strange behaviour together with E:Vector and found this text that the api search is "case-in-sensitively" - I indeed had some doubts.) Currently I think, E:Vector does not work together with E:TitleKey. Will investigate this evening what actually happened - and report here later, if this is necessary. Fully agree with resolved/invalid - for the moment.
Checked again E:Vector plus E:TitleKey run update.php and rebuildTitleKeys.php again. It seems to be okay now.
