Page MenuHomePhabricator

RFC: Serve mobile and desktop variants through the same URL (unified mobile routing)
Open, MediumPublic

Description

Timeline

For the problem analysis and implementation proposal, see the Mobile domain sunsetting RFC on mediawiki.org.
For practical impact and timeline, see the August 2025 Announcement on mediawiki.org.

Annual plan: WE6.4.4 (m:FY2025-2026#Q1)
Status: Weekly status updates on mediawiki.org
Timeline: 1 July 2025 - 31 September 2025 (deployment schedule)
Outline:

Technical diagram from Mobile domain sunsetting on mediawiki.org:

WMF Unified mobile routing 2025.png (2×2 px, 408 KB)

The mobile handling code in Varnish is defined at https://w.wiki/FG4S.
The mobile domain code in Varnish and ATS is defined at https://w.wiki/FG4Y and https://w.wiki/FG4a.


Known issues with status quo

Known issues / extra work avoided:

Past issues / workarounds that can be obsoleted / similar ones avoided in the future:


Original 31 Jan 2019 pitch by @tstarling:
  • Resourcing: Core Platform Team (WMF) and SRE ServiceOps (WMF).
  • Code steward: (idem).

The m. subdomain, as in en.m.wikipedia.org, is annoying. Links shared on social media are randomly mobile or non-mobile, and so desktop users often accidentally visit the mobile site. Having separate domains complicates analytics and search engine optimisation.

The m. subdomain does not appear to reflect best current practice. Many websites are able to detect mobile clients and deliver the correct variant through an unmodified URL. For example, WikiTravel does this, using CloudFront and MediaWiki/MobileFrontend.

I propose removing the m. subdomain. The frontend would detect the desired device variant based on UA and request cookies, and send it to MediaWiki in a single header, and would vary the resulting cache based on this request header. MediaWiki (MobileFrontend, or core after T100402 is fixed) would use this request header to select the skin.

@BBlack suggests starting with a soft launch. We would initially remove the device detection redirect from en.wikipedia.org to en.m.wikipedia.org. We would redirect away from the old domains only when the traffic on them has declined. Obviously, to avoid breaking links, the redirect will have to be retained forever.

We could look at how device detection works in third-party CDNs for ideas on what to call the request header or any other unresolved details.

Related Objects

StatusSubtypeAssignedTask
OpenKrinkle
DeclinedNone
ResolvedVgutierrez
Resolvedtstarling
Resolvedmforns
ResolvedKrinkle
ResolvedJAllemandou
ResolvedKrinkle
ResolvedKrinkle
ResolvedKrinkle
OpenNone
ResolvedSgs
OpenNone
ResolvedJdlrobson-WMF
ResolvedKrinkle
ResolvedKrinkle
ResolvedJAllemandou
ResolvedJAllemandou
OpenNone
ResolvedKrinkle
ResolvedBUG REPORTKrinkle
ResolvedKrinkle
Resolvedakosiaris
ResolvedDzahn
ResolvedMaxSem
ResolvedAndrew
InvalidAndrew
ResolvedKrenair
ResolvedJdlrobson
ResolvedFlorian
ResolvedNone
ResolvedPeter
ResolvedPeter
DeclinedPeter
OpenNone
ResolvedSpikemfossati
ResolvedEtonkovidova
Resolvedjsn.sherman
Resolvedvaughnwalters
OpenNone
DuplicateNone
ResolvedNone
ResolvedPeter
ResolvedPeter
ResolvedPeter
ResolvedKrinkle
OpenNone
OpenKrinkle

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Krinkle renamed this task from RFC: Remove m-dot subdomain, serve mobile and desktop variants through the same URL to RFC: Serve mobile and desktop variants through the same URL (unified mobile routing).Sep 4 2025, 8:56 PM
Krinkle updated the task description. (Show Details)
Krinkle updated the task description. (Show Details)

Has anyone actually used Wikimedia websites on a mobile device here? Most of the time it is not editor-friendly, in fact, it's often clearly made to just be consumed and not produced (that is, editing is more difficult for mobile users). Automatically directing mobile users to the worst UI is a bad idea, this should be able to be disabled. It's bad enough that the English-language Wikipedia keeps directing you to the mobile mode once you click on it once, even if you explicitly try to go to a desktop page, you have to manually go to the bottom and click on "Desktop mode".

Users should be able to configure how they want to use Wikimedia websites, not be forced into the worst possible mode.

I don't think this ticket is to remove mobile mode (i.e. the skin MinervaNeue and the extension MobileFrontend). I think this ticket is just to remove the m. subdomain. I think the website will auto-detect if you're on mobile or not and serve you that skin and mode. And if you want to toggle between mobile and desktop, there is a toggle link in the footer of every page (it says "Mobile view" or "Desktop" depending on which mode you're in).

Has anyone actually used Wikimedia websites on a mobile device here?

Yes, of course they have. Almost everyone here has 15+ years of Wikipedia and MediaWiki experience (and we all have mobile phones)

Most of the time it is not editor-friendly, in fact, it's often clearly made to just be consumed and not produced (that is, editing is more difficult for mobile users).

I personally disagree. But it is definitely not targeting people who make 10000 edits a year, not feature complete and likely never will be. But closing the gap is what people here are working on and this is 1 step in that process.

Users should be able to configure how they want to use Wikimedia websites, not be forced into the worst possible mode.

This should make that easier and not harder, so that should be nice.

do I understand correctly that you want to use the desktop version on mobile? if so, as far as I know this task should help you because you won't be sent m. links that force you onto the mobile version

This should make that easier and not harder, so that should be nice.

It would be nice if someone could explain why that is in plain English. For a long while, the mobile version was very aggressively pushed on phones (e.g. it wouldn't remember the desktop preference no matter what one would do, you couldn't get the Vector 2022 sidebar to stay opened etc.) and I believe people have concerns that something like that might happen again.

For instance, to me it's unclear what happens after the change when you click on various external links (with and without m.) depending on your current mode. One would hope (and should probably test 😅) that all link combinations take you to the same page without changing the skin.

Okay let me try: this change is not making the mobile mode go away. It doesn't change anything on who is shown what. What changes is this: if you navigate wikis on phone and hasn't opted out (using desktop footer link or browser option), you won't be seeing .m. url anymore. You still be shown mobile frontend, just under ro.wikipedia.org for example (and not ro.m.wikipedia.org)

What helps in sharing is simple: going to .m. domain unconditionally gets you to mobile view even if you're on desktop which personally has been a thorn on my side as an admin since mobile editors share links in WP:AN of my wiki when someone was rude to them and every time I have to remove that .m. link to be able to see it properly. After this change, people stop sharing .m. links since they won't see them. They share the same url but you ✨️ magically ✨️ see different views based on whether you're on mobile or desktop or you have opted to see desktop on mobile using the browser function or the "Desktop view" footer link (or "Mobile view" on the other way around)

To test what this change entails, simply play with https://mediawiki.org or wikitech.wikimedia.org since they have been switched already.

HTH

Wow, Wikipedia now redirects from mobile to desktop URL! This is sufficient for my Wikipedia edits, but surely serving both from the same URL is way more elegant.

One more thing that I think we should consider in this entire story.. navboxes. As google now does all of its indexing via the mobile site, we will have lost all remaining effect of the link tree building that google was scraping from navboxes, as these are stripped from the content completely...

We should possibly assess SEO impact of that, it might be significant (or not).

That was done some time ago, and isn't particularly related to this task. T198949: Add navbox links to mobile page HTML There's other still-open friends in that context.

Now that mobile and desktop are served from the same URL, I am kind of satisfied and ready to unsubscribe. Recently I haven't done any edits into Wikipedia though, as I've been reading it less than previously. I still haven't read the entire Code of Conduct. And I consider it nice to have some information in a task's description of how anyone willing can possibly contribute.