This task represents Prep #3 of RFC: Mobile domain sunsetting, and is a blocker to WE6.4.4 (FY25-26 Q1), as tracked by the parent task T214998: RFC: Serve mobile and desktop variants through the same URL (unified mobile routing).
Background info
The $wgMobileUrlCallback config variable is set in production wmf-config (Codesearch: MobileUrlCallback) to a function that inserts the m. subdomain in the appropiate position. This is used in MobileFrontend for two purposes:
- A: MobileContext::hasMobileDomain() returns true whenever this variable is set (instead of the default null) and returns a modified value. When wgMobileUrlCallback is not set, or when the function returns the input unchanged (as it does e.g. for wikitech.wikimedia.org and login.wikimedia.org today), then hasMobileDomain returns false.
- This in turn powers dozens of side-effects in other MediaWiki features but inside MobileFrontend itself, it primarily does one thing: It controls whether the "Mobile view" link, in the site footer below articles, moves you to a the m-dot domain, or merely sets a cookie on the current domain. (Codesearch: hasMobileDomain)
- Similarly, it also controls the addition of the discovery link in the HTML head on desktop responses: <link rel="alternate" media="only screen and (max-width: 720px)" href="//en.m.wikipedia.org/wiki/Pagename"/>
- B: MobileFrontendHooks::onTitleSquidURLs adds the mobile version of all given URLs to the list of URLs to purge in Varnish.
In the early phases of the rollout, we will make the canonical domain vary between serving desktop HTML and serving mobile HTML (rather than today, where it varies between desktop HTML and mobile redirect), while the mobile domain remains unchanged.
Note that from the MediaWiki perspective, both today, and after the rolling, the mechanism by which MobileFrontend is activated is not the URL, but the MFMobileHeader HTTP header (X-Subdomain). Today, the Varnish layer removes the m-dot from the URL, and then sends a regular pageview to MediaWiki with the MF HTTP header set. After the rolling, Varnish will be doing that, and doing the same thing on the canonical domain as well for mobile user agents.
Scope
- Decide how to configure MobileFrontend to act like there is no mobile domain (so that hasMobileDomain returns false, and thus any code generating or modifying URLs becomes inert, and thus the new experience on the canonical domain stays within the canonical domain). It is important at this stage, that we do still purge both URLs for compatibility and to avoid stale caches.
Sign off:
- Consult and validate technical approach from Varnish side (SRE Traffic)
Proposal
- Add a local onTitleSquidURLs hook in wmf-config that is effectively a standalone copy of MobileFrontendHooks::onTitleSquidURLs, that when wgMobileUrlCallback is null, will adds URLs by applying today's local wmfMobileUrlCallback function directly.
- Apply Varnish changes to pilot domain, which serve MF pageview directly on canonical domain for mobile user agents.
- Set wgMobileUrlCallback to null for pilot wikis. This will disable purpose A above, and thanks to the local hook in wmf-config will not disable purpose B so that purges keep working.
The execution of these steps is not in scope for this task. This task is about deciding how we configure the MobileFrontend side, and what order we need to do things in during the rollout.