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)