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.
- Mentioned In
- T108149: "insource" search doesn't find matches in js/css pages
T88247: insource should search article text on non-wikitext pages. Probably.
- Mentioned Here
- T88247: insource should search article text on non-wikitext pages. Probably.
T108149: "insource" search doesn't find matches in js/css pages
@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.
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.