Problem
A handful of recently-developed MediaWiki extensions appear to scrape the address bar, looking for m. to activate some mobile-specific behaviour (Codesearch).
location.hostname.includes( '.m.' );
MobileContext->hasMobileDomain(); MobileContext->usingMobileDomain();
These are suboptimal today because:
- .. likely conflates MobileFrontend and the Minerva skin. Once upon a time these were the same thing, but since 2016, the Minerva skin has been its own thing. In most cases, conditionals are related to differences in skin HTML/CSS, which means they should apply even when use use the Minerva skin on desktop. MobileFrontend is much thinner than it used to be, largely focussed on post-processing of article body content, such as moving the lead paragraph above the infobox.
- .. it makes testing harder, since location is a complex global variable that is difficult to mock.
- .. you can select the Minerva skin in your preferences even on desktop.
- .. en.wikipedia.org/?useformat=mobile activates MobileFrontend but is not an m-dot URL.
- .. en.wikipedia.org/?useskin=minerva activates the Minerva skin but is not an m-dot URL.
- .. en.m.wikipedia.org/?useskin=vector activates MobileFrontend with the Vector skin, from an m-dot URL.
While these are relatively minor limitations today, with T214998: RFC: Serve mobile and desktop variants through the same URL (unified mobile routing) this unsupported mechanism will become ineffective, as most mobile views will then take place on standard domains instead of a mobile subdomain.
Background
There are standard and reliable mechanisms that should be used instead. These have existed for many years, and the majority of our code bases requires no changes, because they already use one of these mechanisms. To our knowledge, there are no circumstances in which an extension or gadget can't make use of one of these mechanisms.
If a caller needs to style their component differently to match or accomodate the surrounding skin, you can do this directly in CSS:
.skin-minerva .something { /* .. */ }
Or if your component should only be generated, or generated differently depending on the skin, you can detect that explicitly in JavaScript via mw.config. You can detect the Vector or Timeless skins this way as well.
if ( mw.config.get( 'skin' ) === 'minerva' ) { // ... }
Or to detect specifically that MobileFrontend is active on the current pageview (no matter how it is activated, e.g. by URL, user-agent, query param, etc), that can be done via mw.config as well:
if ( mw.config.get( 'wgMFMode' ) ) { // ... }
For server-side code, likewise, avoid checking against the mobile "domain" but rather check whether the mobile mode is active (regardless of how it was activated):
MobileContext->shouldDisplayMobile();
Scope
Blocking:
- ContentTranslation: mw.cx.SiteMapper.js, can this use use mw.config instead?
- Metrics Platform : client_platform_family in correctly set in the JavaScript client, but the PHP client uses the internal MobileContext->usingMobileDomain() function directly, instead of MobileContext->shouldDisplayMobile().
Non-blocking:
- Wikistories: convertUrlToMobile.js.
- This is okay-ish. It will continue to work fine. Once the m-dot becomes legacy, the URLs generated by this function will become redirects, at which point this code can be safely removed.
- Currently, this exists behind a few layers of re-inventions and assumptions that are close enough to work on Wikipedia, but break elsewhere. This particular function appears to be working around the fact that imageinfo.descriptionshorturl returns URLs like https://commons.wikimedia.org/w/index.php?curid=5750750 which are non-canonical, less-cached, and indeed don't qualify for known-safe automatic redirects to the m-dot URL. This should perhaps use concept URIs from WikibaseMediaInfo instead, e.g. https://commons.wikimedia.org/entity/M137720198 which redirect the canonical URL like https://commons.wikimedia.org/wiki/File:Tuscany_Pitigliano.jpg and display the mobile version.
- operations/mediawiki-config: missing.php. This is used to activate a "m-dot domain not found" error page, e.g. when WMF is amidst setting up a new domain name for a wiki site. This is a rare case where checking the domain is the appropiate and correct thing to do, since this relates to mistakes or incomplete DNS and Apache VirtualHost config, specific to m-dot domains. Since the m-dot subdomain will continue to exist, albeit as a mere redirect, this error handler seems fine to keep. Although it could also be removed anytime in favour a general "domain not found" error page.