[14:13:48] Krinkle: sso.wikimedia has $wgLoadScript set to the origin wiki, so that's where startup.js will be loaded from. startup.js has something like mw.loader.addSource({"local":"/w/load.php"}) which uses the normal script path, not the SSO domain script path. So module loading from JS will fail. Not sure what to do about that. [14:14:26] Can we just change that to use a full URL? [14:15:28] Krinkle: Yes, that's what setting $wgLoadScript to a full path should do. [14:15:43] by default it's a local path (agnostic of HTTP,HTTP, and m-dot) [14:15:48] HTTPS* [14:16:00] If MW is trying to be clever and shortening it somehow, that's a bug imho :) [14:16:19] oh I see, it's coming from the origin [14:16:24] where we dont set it that way [14:16:25] right [14:17:02] Well, in that case the reason we can't is clear: HTTP, HTTPS, m-dot. [14:18:23] We can do an audit of where the derived data is used. If we're confident it's not placed into any kind of backend cache, we can probably do an expand url. The idea being that HTML bootstraps the right direction. [14:18:51] so m-dot and canonical would both output the same relative URL like it does today on regular page views. but then inside load.php we expand the url [14:19:14] that should be safe, assuming no shared backend caches. [14:19:38] but I'm pretty sure we do have shared caches, but we might be able to fix them. E.g. expanding image urls to load.php?image=… [14:20:01] we don't need to change it for all MediaWiki I think, just all Wikimedia sites (which don't use HTTP) [14:20:09] we do use m-dot though [14:20:15] that would use the non-mobile domain on the mobile site, yeah [14:20:22] which responds with different content [14:20:34] there are isMobile conditions in module content [14:20:36] I guess unacceptable because of DNS lookup delay? [14:20:51] oh, it's actually different data? [14:20:58] true, but that's not the first problem, it'd actually behave differently [14:21:01] yeah [14:21:44] url formatting, wikitext parsing, and some module defintion variance as well. [14:21:59] The image url issues we can contain to stylesheets, stylesheets already expand client-=side relative to CSS location, so that can stay relative. [14:22:06] we'd expand it only for the startup.js response, not RL more widely. [14:22:34] I can't think off-hand of what shared cache that would involve. [14:23:52] Trying to account for mobile domain in Wikimedia config seems like a PITA so yeah that leaves expanding in load.php as you say. I'll make a patch. [14:24:08] thanks! [14:25:00] ( https://www.mediawiki.org/wiki/ResourceLoader/Architecture#Strategic_decisions_and_future_considerations is really cool BTW. Wish we had that for more components.) [23:54:26] I'm surprised Hannah's core change is passing CI even before the vendor patch is associated vua Depends-On - https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1054944 [23:54:37] CI output for the mediawiki-vendor-quibble job says: [23:54:38] > mediawiki/vendor is used, skip composer.lock check [23:54:55] that.. seems odd? [23:58:20] s/odd/wrong [23:58:22] T333412 [23:58:22] T333412: mediawiki/vendor can't be updated due to phpunit reporting composer.lock failure - https://phabricator.wikimedia.org/T333412 [23:58:38] https://gerrit.wikimedia.org/r/plugins/gitiles/integration/quibble/+blame/943e0690733e20ec357e5947dbe5062203e9a1c1/quibble/commands.py#608 [23:58:51] > All non-mediawiki/vendor jobs will skip checking for matching versions and continue "at their own risk". mediawiki/vendor will still check versions to make sure it stays in sync with MediaWiki core. [23:58:52] except.. [23:59:01] https://gerrit.wikimedia.org/g/mediawiki/vendor [23:59:14] > The vendor repo has special configuration, which skips the integrity checks and so allowing a circular dependency Gordian knot to be fixed. However, this means that, if merged alone without a pair, you'll cause ALL patches in MediaWiki and ALL extensions to fail their continuous integration tests. [23:59:18] one of these is wrong.