(broken styles aside tbh it looks better than the desktop default - but this was not intended behaviour from the patch)

This might make sense to make a core feature at some point (or its own tiny extension, bundled with core).

If we do, we'll need to resolve the tech debt around the handling of placeholders for pages that do not yet exist. The different handlers that exist for this in core are currently being bypassed, which likely causes some long-tail extension or gadget compat issues already.

For example, we already have different defaults for most wiki pages vs file pages, and a special header for talk pages. And a variant for when there is no permission to create it.

• noarticletext
• noarticletext-nopermission
• talkpageheader
• filepage-nofile-link

And there's more on the extension hooks side as well, such as the hooks used by ArticlePlaceholder and GlobalUserPage, which also handle pages that don't "exist".

Having first-class support for user pages here would certainly make sense. Figuring out where it properly fits in between all these will be a bit more difficult though, so probably best for a later task :)

Change 582892 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Only replace the user page default on mobile

https://gerrit.wikimedia.org/r/582892

I use a custom search engine in Firefox to search on the English Wikipedia. When I search for a page that doesn't exit, I am not taken directly to Special:Search. Instead, I see the noarticletext page. If I want to continue searching, I can then click the "Search for "Foo" in existing pages." link.

With this regression, that link doesn't exist. Instead of finding what I'm looking for, I hit a dead end. This happens regularly. I'd quite appreciate the patch above being merged and deployed post-haste.

In T248141#6006726, @AntiCompositeNumber wrote:

I use a custom search engine in Firefox to search on the English Wikipedia. When I search for a page that doesn't exit, I am not taken directly to Special:Search. Instead, I see the noarticletext page. If I want to continue searching, I can then click the "Search for "Foo" in existing pages." link.

With this regression, that link doesn't exist. Instead of finding what I'm looking for, I hit a dead end. This happens regularly. I'd quite appreciate the patch above being merged and deployed post-haste.

Are you searching for user pages? I'm seeing the link fine on other namespaces https://en.wikipedia.beta.wmflabs.org/wiki/Foooo (just wanting to clarify this bug is not impacting other places)

Correct. I type !w User:FooBarBaz, which takes me to https://en.wikipedia.org/wiki/User:FooBarBaz, which is a dead end. Other namespaces work as expected (they show a page with a search link). If the user does not exist, like !w User:FooBarBazBin, I also get the expected page.

Change 582892 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Only replace the user page default on mobile

https://gerrit.wikimedia.org/r/582892

Quick QA: back to normal on beta cluster. Moving to needs QA in production (@Edtadros - this is on next week's train so should be ready April 8)
https://en.wikipedia.beta.wmflabs.org/wiki/User:Jdlrobson

Change 585537 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] MobileFormatter should run with content provider

https://gerrit.wikimedia.org/r/585537

@Jdlrobson @ovasileva -- thanks for fixing this. One day, the Growth team wants to work on figuring out how to prompt newcomers to create good userpages, and this bug might provide us some interesting accidental data to analyze. It might be interesting to see whether userpage creations went up or were higher quality during this time period. We don't want to do this analysis right now, but for when we get to it in the future:

• Can you tell the exact timestamps of when the bug started and ended?
• Did it affect all wikis? Just Wikipedias?

FYI @Trizek-WMF @RHo @nettrom_WMF

Hey there is T248347 to capture that! Have added you as subscriber.

@Jdlrobson @pmiazga When will this be deployed? The current Tech News says “it has been fixed”. This newsletter usually goes out on Mondays in the European evening, so if the patch is deployed before folks read the newsletter, it should happen during the European Mid-day SWAT or at latest during the (American) Morning SWAT. If this isn’t going to happen, I think the newsletter should use future tense.

In T248141#6029459, @Tacsipacsi wrote:

@Jdlrobson @pmiazga When will this be deployed? The current Tech News says “it has been fixed”. This newsletter usually goes out on Mondays in the European evening, so if the patch is deployed before folks read the newsletter, it should happen during the European Mid-day SWAT or at latest during the (American) Morning SWAT. If this isn’t going to happen, I think the newsletter should use future tense.

@Tacsipacsi - the fix is on this week's deployment train, meaning it will start getting deployed tomorrow (April 7) and finish on Thursday (April 9). @Johan - I'll make a correction for Tech News

@Jdlrobson / @ovasileva I'm not clear on what the acceptance criteria are.

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: macOS Catalina
Browser: Chrome
Device: MBP
Emulated Device: iPhoneX

Test Artifact(s):

QA steps

✅ AC1: Visit https://en.wikipedia.beta.wmflabs.org/wiki/User:Jdlrobson and confirm you see the text "Wikipedia does not have a user page with this exact name.

Change 585537 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] MobileFormatter should run with content provider

https://gerrit.wikimedia.org/r/585537