| Igorsolovki | |
| Feb 26 2018, 11:33 AM |
| F14028975: Screenshot_20180226_142129.png | |
| Feb 26 2018, 11:34 AM |
| F14028962: Screenshot_20180226_142054.png | |
| Feb 26 2018, 11:33 AM |
| F14028966: Screenshot_20180226_142105.png | |
| Feb 26 2018, 11:33 AM |
| F14028968: Screenshot_20180226_142134.png | |
| Feb 26 2018, 11:33 AM |
| F14028964: Screenshot_20180226_142040.png | |
| Feb 26 2018, 11:33 AM |
Hi all!
Whilst image is present in https://en.wikivoyage.org/wiki/Special:ListFiles (for examp.: ValenciaBanner2.jpg )
it could not be found in media search results by partial name:
Some debug info on third-party install can be found here: https://phabricator.wikimedia.org/T186997
This appears to be a specific to the search system, not the editing environment; the two search queries that are issued by the visual editor don't return any results for the partial title [1][2], but the second search query does return a result for the full title [3][4].
It looks like VisualEditor is using the full text search api. If you want partial title matches it would need to use the prefix search generator. Alternatively the full text api can be convinced to do prefix searches (although in an exceptionally more expensive way) by appending a * to any partial token. If prefix search is too limiting, as you want to search non-title matches, a tradeoff might be to generate a full text search query in the form of: valenciabanner OR intitle:valenciabanner* which will limit the * expansion to only titles/redirects.
waiting for a response from VE team, until then there's nothing Search Platform can do.
Closing out low/est priority tasks over 6 months old with no activity within last 6 months in order to clean out the backlog of tickets we will not be addressing in the near term. Please feel free to reopen if you think a ticket is important, but bare in mind that given current priorities and resourcing, it is unlikely for the Search team to pick up these tasks for the indefinite future. We hope that the requested changes have either been addressed by or made irrelevant by work the team has done or is doing -- e.g. upgrading Elasticsearch to a newer version will solve various ES-related problems -- or will be subsumed by future work in a more generalized way.
Re-opening tasks and removing from team workboard per IRC feedback given yesterday and discussion with MPham.
I just installed MediaWiki for the first time and bumped into this issue while user testing. It would be wonderful to be able to rely on the native search!
I can confirm @EBernhardson's observation that the Insert → Media search runs from the api.php full-text search API. This only matches full 'words', lacks typeahead, and since it doesn't consider . a delimiter, the final 'word' must include the suffix (e.g. lastWord.suffix). This behavior significantly encourages users to name media files with spaces, not camelCase, hyphenation, etc.
The main/page search runs from the rest.php autocomplete page title API and performs typeahead for page titles starting at any word in their titles; files are only shown with the file: prefix, which is then considered the beginning of the string, so the next 'word' must be the first of the file.
The REST search pages API seems like the most fitting one, since search terms can be listed in any order, but it doesn't seem to offer typeahead.
I would be happy to assist in improving native media search, but I'm afraid I'm mostly limited to user testing.
not sure if it helps but mainpage is saying
Effective June 1, 2021: Phabricator is no longer actively maintained.
I'm not sure what that's got to to do with this task. This is a bug in mediawiki and has nothing to do with the underlying software used to report the bug.