Last modified: 2014-03-09 18:05:14 UTC
When the search uses parameters prefix:, intitle: or +incategory:, it should not propose to create the page. See link, new users have been confused by this when searching archives and created pages like <something> prefix:Talk:Main Page . It seems unlikely that pages containing any of those strings need to be created.
These are legitimate page title names, no need for the software to block them. If a local wiki doesn't want them, an AbuseFilter or entry to the page title blacklist are more appropriate. Marking WONTFIX.
Where they're syntactical elements of a search query they really should be excluded from the search suggestion.
*** Bug 21137 has been marked as a duplicate of this bug. ***
*** Bug 21467 has been marked as a duplicate of this bug. ***
This also happens with the ~ and - prefixes, and the * suffix.
MediaWiki:Searchmenu-new is also a bit ugly: '''Create the page "[[:$1]]" on this wiki!''' I understand the bold, but the exclamation mark? While at it, if this bug is fixed the message can be made a bit more encouraging, like «'''You can create the page "[[:$1]]" on this wiki.'''» (such a wording would currently make the effects of this bug worse); the bug 27311 could make the link more helpful and always valid whatever the permissions/processes on the wiki.
As mentioned on bug 29989, this is also the case with double quotes used in search phrases.
*** Bug 29989 has been marked as a duplicate of this bug. ***
We actually did this with Cirrus. If other backends support fancy syntax and want to do the same, they can too by returning true in SearchResultSet::searchContainedSyntax() implementations.
