[02:07:04] Is there any way to detect if the user is currently editing with VisualEditor (2017) wikitext mode (ie a public detection function in VE at all to use with extension) [17:15:28] just hit something really strange: I am using $wgUseCdn with Varnish, and I recently updated MW from 1.35.0 to 1.35.2 and judging by tcpdump [17:15:50] purging a page results in an HTTP CONNECT attempt to 443 [17:15:56] instead of PURGE [17:58:28] hmm so how do I even log in to Phabricator with my old wikitech account [18:03:23] I do not understand why is it using HTTP CONNECT [18:19:49] apparently it sets proxy in curl options to wgCdnServers, huh [18:22:41] oh. [18:24:33] now I get it [18:24:59] recent changes break compatibility with Varnish [18:25:28] I think if I disable curl it will suddenly work [18:44:55] * Remilia has dirty-hacked her way around this issue [18:46:04] this is where it breaks; https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/tags/1.35.2/includes/deferred/CdnCacheUpdate.php#303 [18:46:45] if $url has https:// cURL does CONNECT [18:46:55] if it is plain http, everything works as expected [19:01:46] Remilia: if it the cache requests are in plain-text (say on localhost) to the wiki instance, then $wgInternalServer may be of interest [19:03:04] hmm [19:04:24] grknight: I am unsure if this will apply in case of cdnCacheUpdate… [19:05:23] going to check [19:05:48] I have not looked deeply but our Varnish setup doesn't seem to be suffering issues on 1.35.2 and we have that set [19:10:01] grknight: oh it does seem to work, thank you [19:10:17] I guess I did not have cURL enabled before [21:24:49] addshore: the math in this image does not add up https://usercontent.irccloud-cdn.com/file/0HH0fiSK/image.png [21:25:12] oh I misread, last line is not "Total" [21:25:13] it says "Tests" [21:25:26] Yes! :P [21:26:29] the differences seem small enough overall that I would attribute the difference to something minor in configuration, something we could trivially do as well. overall when we compared it to Travis, our CI was notably faster because we run mysql in RAM, for example, and have 2 CPUs per worker instead of 1; + git caching of course. [21:27:36] also, while opinions differ, it seems in general that there appear to be funds available for "productivity"-esque ideas, so if all it takes is more hardware, and if that is our limit, that is presumably fine as-is. either way, persuing cloud providers is most likely a futile effort. [21:28:00] s/fine as-is/fine to increase if needed/ [21:28:39] addshore: phan seems likely to switch to using composer-install per James comment. [21:29:31] while that is what you are asking for, it does not appear to solve the problem; which is that you'll still have at least some jobs use vendor and thus those get into the patch dependency dilemma. [21:29:53] perhaps I'm misunderstanding the issue you actually want to solve. having it run both ways would decrease flexibity, right? [21:30:02] you'd have to satisfy both [21:33:31] Remilia: $wgInternalServer should be set with http:// if you use things like Varnish, which CdnCacheUpdate will use (it uses wfExpandUrl with PROTO_INTERNAL). [21:34:01] that shoudl get you back to not having to to the https connect [21:34:15] Remilia: it's possible that adding curl made it pick a different purge method indeed. https://phabricator.wikimedia.org/T264735 might be related to the curl issue. [21:39:26] Is there a JavaScript API for changing user preferences? [21:52:17] harej: yes [21:52:25] Where can I read up on it? [21:52:34] https://www.mediawiki.org/wiki/ResourceLoader/Core_modules#mediawiki.api [21:52:39] >mw.Api#saveOptions - Changes one or more user preferences. [21:54:14] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/HEAD/resources/src/mediawiki.api/options.js