Page MenuHomePhabricator

Code break shown when searching "-{" on Wikidata
Closed, ResolvedPublicBUG REPORT

Description

Steps to Reproduce:

  1. Open the https://www.wikidata.org/w/index.php?search=-%7B&title=Special%3ASearch

Actual Results:
"There were no results matching the query. {{#switch: |120=You may propose a new property. |146=You may [{{fullurl:Special:NewLexeme|lemma={{urlencode:{{#invoke:SearchParser|getLemmaFromInput|1=-{}}|PATH}}}} create a new lexeme] for "". |#default=You may [{{fullurl:Special:NewItem|label={{urlencode:-{|PATH}}}} create a new item] for "-{". }}" or "没有与查询匹配的结果。 {{#switch: |120=您可以提议新属性。 |146=您可以为“”[{{fullurl:Special:NewLexeme|lemma={{urlencode:{{#invoke:SearchParser|getLemmaFromInput|1=-{}}|PATH}}}} 创建一个新的词位]。 |#default=你可以给“-{”[{{fullurl:Special:NewItem|label={{urlencode:-{|PATH}}}} 创建一个新的数据项]。 }}" shown.

Expected Results:
Like the “没有与查询匹配的结果。 你可以给“12345AAAA”创建一个新的数据项。” at "https://www.wikidata.org/w/index.php?search=12345AAAA".

Event Timeline

The issue is with https://www.wikidata.org/wiki/MediaWiki:Search-nonefound having {{#switch:{{NAMESPACENUMBER:$1}} and $1 being -{ for the example problematic URL, which doesn't work because its an invalid title

Aklapper removed a project: Advanced-Search.
Aklapper added a subscriber: matej_suchanek.

Thanks for reporting. This looks like a local content issue (local overwrite for a default string) which needs to get fixed by editing content on that website instead, which means that's not handled in Wikimedia Phabricator...

Heads-up to Matěj per edit history.

Reopening because I don't know how to solve it locally (other than by reverting T263258 or even T132729).

Reopening because I don't know how to solve it locally (other than by reverting T263258 or even T132729).

Maybe add <nowiki> mark around $1 can slove it.

Maybe add <nowiki> mark around $1 can slove it.

$1 is already escaped, so this is unnecessary. Adding around $2 won't help because {{urlencode:<nowiki>$2</nowiki>|PATH}} returns nothing (we could live with not having returned anything for "invalid" input but not for valid).

Oh, the problem is that title with big quote isn't a valid title, and unpaired big quotes broke the parsing process. Maybe we can check the title in lua module, with mw.title.new and check the return value...

Oh, the problem is that title with big quote isn't a valid title, and unpaired big quotes broke the parsing process. Maybe we can check the title in lua module, with mw.title.new and check the return value...

And all wikitext with plain $2 (without nowiki marks) should move to lua module to not break parsing process.

Oh, the problem is that title with big quote isn't a valid title, and unpaired big quotes broke the parsing process. Maybe we can check the title in lua module, with mw.title.new and check the return value...

And all wikitext with plain $2 (without nowiki marks) should move to lua module to not break parsing process.

Very good idea! It seems not to break, but the form is now prefilled with -&#123; (not a big problem)...

Very good idea! It seems not to break, but the form is now prefilled with -&#123; (not a big problem)...

Maybe the text was escaped by nowiki or unstripNoWiki...

matej_suchanek claimed this task.

Seems so. I suspect this is considered LanguageConverter syntax because -{ and }- get escaped, but { or } alone don't. Some other inputs also get escaped, like <script>alert("");</script>.

The main problem is solved, nevertheless. Thanks a lot @Func!