I hope this doesn't turn into a bikeshed of responsive sites vs separate desktop/mobile site

For the purposes of this task, let's assume that for some valid reason separate desktop and mobile URLs are needed. In that case, yes, everything that generates full URLs should automatically generate mobile or desktop URLs as appropriate for the incoming request.

The simplest method would seem to be doing it at an even lower level: have $wgServer, $wgCanonicalServer, $wgScriptPath, and so on contain the appropriate settings, then everything everywhere should automatically do the right thing. Does anyone know of a reason that wouldn't work?

I can't think of any reasons right now... I feel like that could work nicely (although it would require copy pasting all the wgServer entries into wmf-config/mobile.php)

This wouldn't help anything that uses ParserOutput cache, of course, (not sure if Echo/Flow use that) as we don't vary that on the mobile site but this would help api requests and special pages (which will help languages for sure)... Might also help CentralAuth which currently has to workaround this issue in MobileFrontend when it does login redirects.

We can try the config change out on https://en.m.wikipedia.beta.wmflabs.org/wiki/Headings and I can do some tests there to see the impact...

In T156847#2989772, @Anomie wrote:

The simplest method would seem to be doing it at an even lower level: have $wgServer, $wgCanonicalServer, $wgScriptPath, and so on contain the appropriate settings, then everything everywhere should automatically do the right thing. Does anyone know of a reason that wouldn't work?

In theory splitting parser cache would be a problem there (since very few pages would actually need it, but it's hard to determine which ones). In practice MobileFrontent splits the cache anyway so that's not really an issue.

Most subtasks seem to be related to link generation in Echo and that would probably be solved by setting domain related core variables appropriately.

The remaining cluster of problems is with handling external links. E.g. CentralAuth loginwiki domain name and shared cookie domain. That is now done in the EnterMobileMode hook which is hard to maintain and has led to bugs. Maybe there should be some sort of hookable domain-wrangling method in core which all software-generated external URLs are required to be passed through.

MobileFrontent splits the cache anyway so that's not really an issue.

Only HTML. ParserOutput is shared between desktop and mobile... MobileFormatter runs its magic on that and relies on the resulting HTML to be cached by varnish which has always sucked FYI

but yup, I agree, the majority of problems would probably be solved by changing wgServer value on mobile domains and I like the simplicity of the solution.

In T156847#2991439, @Jdlrobson wrote:

Only HTML. ParserOutput is shared between desktop and mobile... MobileFormatter runs its magic on that and relies on the resulting HTML to be cached by varnish which has always sucked FYI

It seems to be split, at least with the config the WMF uses: (1) (2) (3)

If parser cache were not split we would get weird bugs with in-content URLs generated by stuff like {{fullurl:}}. Granted there isn't really any reason to use fullurl instead of localurl but it happens.

Interesting. I wouldn't rely on the code as the source of truth though - definitely would be worth investigating before going ahead with this change.

My reasons for confusion are:

1. We had issues last year with parser output pollution (sections were leaking into desktop skin) - T124356
2. MFStripResponsiveImages is applied inside ThumbnailBeforeProduceHTML and I'm not sure where in the parser code this hook gets called.
3. We wanted to do this and were told we couldn't/weren't. See T125899.

Here is the log event (with debug headers) for action=purge on the mobile site writing to the parser cache. The key it writes to is enwiki:pcache:idhash:39870143-0!*!0!!*!4!*!responsiveimages=0. So it's definitely splitting the cache.

This proposal is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

This bug affects the project wikimirror.

Replacing domain names with their onion equivalents was mentioned as a similar problem.

I would also add that this feature would be particularly useful when visiting from mobile. At the moment, users visiting a mirror of Wikipedia (say en.vikiansiklopedi.org) get redirect of en.m.wikipedia.org regardless of the original domain (instead of en.m.vikiansiklopedi.org).

@Tgr can you define a straw man proposal of what needs to be done here? It would be good to have a generic solution here and if you can spec it out maybe some reading web devs can make it happen.

Seems to fit with infrastructure since this touches core and reading web products and came up again as a result of SEO assessment (see T198969)

Is this something the core platform team is interested in? (Noting a lack of team ownership here) and it seems like a good fit.

This sounds like a reasonable task for CPT to work on, but could you elaborate on the urgency of the request so we can prioritize. We may not be able to schedule it in the immediate future.

Hard to gauge urgency, but this bug does keep coming up (see related objects) and impacts a variety of workflows:

• impacts product (e.g. Flow/notifications)
• login flows (e.g. OAuth)
• user experience (where editors use mobile site on desktop browser)
• 3rd parties e.g. T156847#3357947

All that seems pretty important to me but that assumes there is an obvious and easy solution and there is something we can do.

It would help to have a technical solution documented here. I see T156847#3365656 but no follow up.

In T156847#5695574, @CCicalese_WMF wrote:

It would help to have a technical solution documented here. I see T156847#3365656 but no follow up.

IIRC there are two separate issues here:

• Sometimes the actual domain is different from the domain in $wgServer. For Wikimedia wikis the mobile domain is the usual reason for this; there could be others (e.g. if you want to make the wiki accessible via a TOR onion service, that will have its own domain, maybe even a separate mobile domain). Currently that gets ignored when generating links with wfExpandUrl, Title::getFullURL or the like, and the domain from $wgServer will be used. Most links are relative and do not include a domain, but there are exceptions (wikitext using {{fullurl:}}) and that will link to the wrong place and cause slow-down or worse.
• Ideally, when I am on the mobile domain, links to other wikis should also point to the mobile domain. (Same for onion service etc.) As Jon said, this affects interwiki links (T171398), various security-related browser roundtrips (T145545, T112730), cross-wiki notifications (T107108) and probably a number of other things.

The first problem is probably easy-ish to fix (just make PROTO_CURRENT, or maybe some new flag, use the current domain) but in practice most issues are caused by the second one. Off the top of my had I can think of two ways to handle it:

• Introduce some new abstraction layer (domain variants or something like that) and integrate it into the interwiki-related abstractions (SiteLookup etc): if we are currently on the mobile variant of the domain, then an interwiki link to another site should go to the mobile variant of the interwiki URL, if that variant exists.
• Introduce some transform step for interwiki links: extensions can, via some hook mechanism, provide a transform function that gets called in the interwiki URL and can make changes to it. (MobileFrontend sort of does that already, but via hacky means that are not fully integrated with core logic.)

The first is probably nicer, the second is probably easier to do.