Page MenuHomePhabricator

Search ignoring my settings explicitly set on [[Special:Search]] (advanced search) when search term starts with "<Namespace>:"
Open, LowestPublic

Description

https://commons.wikimedia.org/w/index.php?title=Special%3ASearch&profile=advanced&search=MediaWiki%3AVisualFileChange.js&fulltext=Search&ns2=1&redirs=1&profile=advanced

Is the search string. I want results in the user-namespace but instead I get only results for the MediaWiki-namespace because search "thinks" it must be smart and override my setting.

Results:

  • MediaWiki:VisualFileChange.js
  • MediaWiki:VisualFileChange.js/exec.js
  • [...]
  • MediaWiki:JSONListUploads.js

Not one result in user namespace

Expected:
Only search results in user namespace or at least only a few in MW-Namespace.


Version: unspecified
Severity: minor

Details

Reference
bz37871

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:22 AM
bzimport added a project: CirrusSearch.
bzimport set Reference to bz37871.
bzimport added a subscriber: Unknown Object (MLST).

(In reply to comment #0)

Expected:
Only search results in user namespace or at least only a few in MW-Namespace.

I would say no results from other namespaces, only the ones selected by the user. That is why the user is selecting specific namespaces in the advanced search, right?

PS: We are writing a scenario to check this problem, in the context of https://www.mediawiki.org/wiki/QA/Browser_testing/Search_features

[Merging "MediaWiki extensions/Lucene Search" into "Wikimedia/lucene-search2", see bug 46542. You can filter bugmail for: search-component-merge-20130326 ]

Verified as an issue in CirrusSearch. Recategorising.

The namespace: thing is supposed to override the clicking. Changing it too much is going to cause trouble with people that rely on it or the behaviors that stem from it (stuff like the prefix url parameter). If we're going to change it I'd advise at a minimum the prefixes continue to override the "Content pages" tab. It'd probably be safer for them to override all tabs but Advanced.

I think it's actually an issue in core, not Cirrus or any other search backend.

(In reply to comment #4)

The namespace: thing is supposed to override the clicking. Changing it too
much is going to cause trouble with people that rely on it or the behaviors
that stem from it (stuff like the prefix url parameter). If we're going to
change it I'd advise at a minimum the prefixes continue to override the
"Content pages" tab. It'd probably be safer for them to override all tabs
but
Advanced.

That makes sense. If someone goes to the trouble to manually configure what namespace they're searching in, then types in "MediaWiki:Foo" as their search query, they're not expecting search to override their manually selected namespaces. In most other cases where they've not chosen their namespaces manually, it makes sense for this override to take place.

But, how are you expecting to determine if the user manually adjusted the checkboxes or simply went to https://commons.wikimedia.org/wiki/Special:Search and expected the manually typed namespace to override them?

And if you are thinking "let's check if typed on skin search box or Special:search", that would be very inconsistent, as searching «MediaWiki:VisualFileChange.js» in the skin, then pressing Search again, would lead to a completely different result.

PS: You can search results in user ns only by issuing "MediaWiki:VisualFileChange.js".
Maybe the fix shall be adding a «Did you mean… ?» for this kind of conflicts.

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Deskana lowered the priority of this task from Low to Lowest.Dec 29 2015, 11:59 PM
Deskana moved this task from Needs triage to Search on the Discovery-ARCHIVED board.
MPhamWMF subscribed.

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.