Change 547643 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] Introducing SkinDefaultModules hook

https://gerrit.wikimedia.org/r/547643

From IRC

Perhaps we could make site.style itself extendable then?
2:15 PM Rather than for MF to register a different one, which is incompatible with the idea of a bundle representing a purpose to be delivered to a page
2:15 PM and wastes startup bytes (a little bit)
2:16 PM The power problem is with extensions using it to add or replace modules, instead of just removing. As well as those decisions being potentially based on user or title which makes it uncacheable and incompatible with various long-term directions.
2:17 PM What would you think about making site.style itself possible to turn into mobile.site.styles?

How would this work in practice? A hook inside the SiteModule ? A setter somewhere that allows us to set the main style/main script module?

How would this work in practice? A hook inside the SiteModule?

Yep, that sounds good to me. This would be a stateless hook with the limited power to deterministically change the array of pages from getPages of SkinModule and SkinStylesModule are composed of. Stateless in so far that it would not be allowed to vary only by ResourceLoaderContext and Mobile's side-wide context (e.g. isMobileDevice), and not by user or page title, given that it would be evaluated by the startup module which is a cachable and user/page-agnostic execution context.

EDIT: Consolidating these two faces of the coin also helps remove another module from the registry :)

Change 549225 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] Enable site modules on mobile domain

https://gerrit.wikimedia.org/r/549225

Blocked on core change: https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/547643/

Change 562380 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Remove mobile.site and mobile.styles modules

https://gerrit.wikimedia.org/r/562380

Change 547643 merged by jenkins-bot:
[mediawiki/core@master] resourceloader: Introduce hooks in ResourceLoaderSiteModule

https://gerrit.wikimedia.org/r/547643

Okay, this should be taken care of in MobileFrontend (https://gerrit.wikimedia.org/r/562380) and then finally updating targets in core (https://gerrit.wikimedia.org/r/549225) which should be merged for the same release.

Change 549225 merged by jenkins-bot:
[mediawiki/core@master] Enable 'site' and 'site.styles' modules on mobile target

https://gerrit.wikimedia.org/r/549225

I'll QA this one.

Train operator: If by Wednesday/group1, the MobileFrontend change (https://gerrit.wikimedia.org/r/562380/) has not landed into branch (either before the branch cut, or afterward with backport) then consider the train blocked until its logical parent in core (https://gerrit.wikimedia.org/r/564150) has been reverted in-branch - by cherry-picking that revert to wmf.15.

Change 564156 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] "Enable 'site' and 'site.styles' modules on mobile target (take 2)

https://gerrit.wikimedia.org/r/564156

Bumping out sprint for a bit to focus on other things that are more important right now. I will get back to this!

I've been asked to focus on T232140 - but this will be my priority after that one's dealt with.

@Krinkle on review wrote:

I'm not confident this is compatible with current MW and cache setup. How will the cached pages work if the module is served as empty?
If I understand correctly, what you need here is to keep the old modules as-is, unchanged, undeprecated, but no longer queued for new page views. Then next week, it can be removed entirely without deprecation.

That way, cached views continue to load the correct code via the old module, and newer views will load the correct code via the new module.

To explain my thinking around the patch order. It's not a big deal if the two patches get merged together (as they should be) but I want to mitigate the risk one of the 2 scenarios that can occur if one patch doesn't merge for some reason.

• As soon as the core patch (https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/564156/) lands site and site.styles will get loaded on the mobile site.
• As soon as the MobileFrontend patch gets merged (https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/562380/) mobile.site and mobile.site.styles will disappear from the mobile site and a hook callback will be registered to swap out site and site.styles for mobile.site and mobile.site.styles respectively.

Depending on the order of the patches two scenarios arise:

1. If core patch is present but not MobileFrontend patch, then mobile.site AND site etc will be loaded. This increases CSS payload and negatively impacts performance.
2. If MobileFrontend patch is present but not core, then no site styles of any nature will be loaded and a hook callback will be registered but never called.

Ideally, both of the patches land together to avoid these issues however given site styles on mobile are being discouraged for template styles, I think scenario 2 is the lesser problematic. In the case of a revert #2 can be fixed using mobile gadgets if necessary. #1 is much more damaging in production due to the caching implications.

Both patches will be going out in the same train.I have no concern about any kind of intermediary stage where one patch hasn't applied.

My CR on the MF patch has to do with the contents of the MF patch, and already builds on the assumption that both go out at once. I'm happy to elaborate if needed, no problem, but perhaps this clarifies it already. Could you re-read the CR with that in mind and let me know if you have a more specific question?

@Jdlrobson Currently MF loads mobile.site and mobile.site.styles on page views via the onBeforePageDisplay hook. Page view HTML is cached. Specifically:

… <script> … mw.loader.load( [ … "mobile.site" … </script></head>

The end-result of what you're proposing is to:

• make mobile.site no longer included in the page view modules queue,
• make mobile.site no longer exist (or do nothing),
• make site be what mobile.site was,
• let site become valid for targets=mobile so that core's inclusion of site in the page view modules queue will start applying in MF context and thus end up in the queue output in HTML.

The current two patches do this all in one go. If we look ahead how that would behave, it would break the mobile site code for all page views by unregistered users, because those page view HTML responses are cached by the CDN for upto 7 days.

Their HTML will still only be trying to load mobile.site, it doesn't yet have site in its queue. Their startup module will have been updated immediately and no longer contain mobile.site (it will contain site though). Regardless of startup module, when the browser requests mobile.site from the server, all MediaWiki knows is the current version which is an empty file module that only contains the generated line console.warn(" … deprecation message …");.

There are two ways you can solve this.

1. Keep the old mobile.site still registered in extension.json, exactly as it works today, in the MobileFrontend patch. Then remove it in a separate commit to be merged one week later (no need for deprecation).
2. Keep the old mobile.site still registered in extension.json, as empty module aliasing the new site module (dependencies: ["site"]). No deprecation. And removed one week later.

This amended version of the MobileFrontend patch will then land around the same time as the core patch. The order truly doesn't matter. I'll +2 them together. They'lll go out in the same wmf branch and end up on Beta around the same time as well. The second MF patch can be merged one week later (more specifically, at least 7 days after the next train has succesfully rolled out). Does that make sense?

@ovasileva This was nearly done, I think. Would it be possible to finish this off while we still have it fresh in mind? It's nearly done and shouldn't take more than half an hour to look over and finalise – however it could easily cost half a day or more (for multiple people) next time.

@Krinkle is code reviewing if anyone in the team can grok https://gerrit.wikimedia.org/r/c/562380 and give it a +1 that would be helpful

Change 564156 merged by jenkins-bot:
[mediawiki/core@master] "Enable 'site' and 'site.styles' modules on mobile target (take 2)

https://gerrit.wikimedia.org/r/564156

Change 562380 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Remove mobile.site and mobile.styles modules

https://gerrit.wikimedia.org/r/562380

Change 883629 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/MobileFrontend@master] Drop unused MobileFrontend modules

https://gerrit.wikimedia.org/r/883629

Change 883629 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Drop unused MobileFrontend modules

https://gerrit.wikimedia.org/r/883629