Page MenuHomePhabricator

English Wikipedia search results are incomplete
Closed, ResolvedPublic

Description

Sample affected page: en:User:Fæ/monobook.js contains rmflinks, but en:Special:Search/rmflinks doesn't show the page. This makes script maintenance difficult.

Looking at https://en.wikipedia.org/wiki/User:F%C3%A6/monobook.js?action=cirrusdump, I don't see mention of "rmflinks", but I clearly see it at https://en.wikipedia.org/wiki/User:Fæ/monobook.js?action=edit. This may be a separate issue, but this type of behavior is why I'm still very wary of the search index, particularly when its results are being used in important determinations (such as deprecating or killing code).

This is also why I'm still annoyed at needing to ask shell users to run mwgrep; text search via Special:Search is still (inexplicably) missing results. :-(

I don't see how these are related to this ticket, please create a new one or your complaints will be lost in some closed ticket. The particular case with monobook.js looks to be related to Sanitizer::stripAllTags(). It will likely be low priority, as i'm not qualified to dig through and adjust our mediawiki wide security related code.

Event Timeline

MZMcBride raised the priority of this task from to Needs Triage.
MZMcBride updated the task description. (Show Details)

@Deskana: I don't pay much attention to workboards, but regarding "Deskana moved this task to Advanced search syntax on the CirrusSearch workboard.", this task is very much specifically about regular text searches missing search results, as I understand it. The example given is https://en.wikipedia.org/wiki/Special:Search/rmflinks?ns2=1, which currently omits "User:Fæ/monobook.js". This task is not related to advanced search syntax, it is related to regular search syntax.

@Deskana: I don't pay much attention to workboards, but regarding "Deskana moved this task to Advanced search syntax on the CirrusSearch workboard.", this task is very much specifically about regular text searches missing search results, as I understand it.

True. However, in terms of rough categorisation, it fits better in this column as opposed to any of the others that exist right now. I could've created a new column, but the usefulness of each column decreases as more are added. Feel free to do that if you feel strongly about it.

Deskana assigned this task to ori.
Deskana triaged this task as Medium priority.
Deskana added a subscriber: ori.

The example query given now returns the expected results, so this appears to have been fixed. It was probably the patch that @ori submitted for T88247 that did this.

Awesome! Thank you, @ori, @Deskana, and @EBernhardson, for all your help here. I really appreciate it.