[00:14:45] Hm.. why is api.php on MediaWIki-Vagrant saying 'httpsexpected' warning on api requests? [00:14:46] (HTTP used when HTTPS was expected.) [00:15:05] if ( $request->getProtocol() === 'http' && ( $request->getSession()->shouldForceHTTPS() || ( $this->getUser()->isLoggedIn() && $this->getUser()->requiresHTTPS() ) [00:15:05] ) ) { [00:15:15] Bad configuration? [00:22:02] Krinkle: should not happen unless you enabled the https role [00:22:41] I didn't [00:22:44] roles list -e: betafeatures, gadgets, performanceinspector, categorytree, globalcssjs, poolcounter, cirrussearch, mobilefrontend, tidy, cite, monobook, visualeditor, confirmedit, navigationtiming, wikimediaevents, eventlogging, parserfunctions [00:22:50] requiresHTTPS is always false unless $wgSecureLogin is enabled, and the session flag is only true if the user logged in via https [00:23:37] $wgSecureLogin = false in DefaultSettings, and remains that way at run-time per eval.php [00:24:41] There is a forceHTTPS=true cookie set apparently. [00:25:57] deleted cookies, logging in anew, and... it didn't come back [00:26:01] maybe you used the https role in the past and it sticked around? [00:26:03] Hm.. must be a remnant of some old bug [00:26:24] Maybe indirectly via another role? I've never enabled it myself. [00:26:24] happened to me in the past, real annoying [00:26:40] can lock you out of the wiki completely under certain circumstances [00:27:36] role::wikimediaproduction is the only role that includes it [15:54:40] anomie: hey. I'm trying to figure out how to move forward with resolving role and model IDs. Never mind the QueryBuilder for now. It seems I need either a wrapper for the result set, or some kind of expandResultRow() method, which seems ugly. [15:55:14] do you think the requirements I outlined in my last mail are reasonable? [15:55:33] DanielK_WMDE: I haven't read that mail yet, give me a few minutes. [15:57:51] DanielK_WMDE: I'd say if code is dealing with DB rows, it should be prepared to deal with what's in those DB rows instead of thinking that ints are going to somehow magically be turned into strings. If something doesn't want to deal with DB rows, it should use a newFromRow() method (or some other sort of DAO) to get an object that handles the transformation for it. [15:58:36] RevisionStore is that DAO [15:59:13] The fundamental problem is that way too much code deals with DB rows :/ [16:00:18] So, your idea is that the RevisionRecord should take care of resolving the IDs? RevisionRecord is supposed to be a value object, it shouldn't know about services... but I suppose I can use callbacks for this [16:00:57] It doesn't have to be RevisionRecord, the newFromRow method could be on RevisionStore. [16:02:02] it indeed is in RevisionStore. And it could fill in these fields if they are not in the row, from a join. [16:02:16] fair enough for now. thanks! [16:03:00] i'll grep for direct access to rev_content_model to see how much code needs to be fixed for this to work... [17:47:35] Warning: Invalid operand type was used: processForm expects array(s) in /srv/mediawiki/php-1.31.0-wmf.2/includes/specials/SpecialBlock.php on line 827 :\ [17:48:10] Notice: Undefined index: 1 in /srv/mediawiki/php-1.31.0-wmf.3/includes/media/FormatMetadata.php on line 744 [17:48:25] Notice: Undefined index: flow-workflow-change in /srv/mediawiki/php-1.31.0-wmf.3/extensions/Flow/includes/Model/AbstractRevision.php on line 871 [17:53:13] Is this an issue? [17:53:14] ErrorException from line 309 of /srv/mediawiki/php-1.31.0-wmf.3/includes/debug/MWDebug.php: PHP Warning: Missing img_description_text and img_description_data fields in row with MIGRATION_OLD [Called from CommentStore::getCommentInternal in /srv/mediawiki/php-1.31.0-wmf.3/includes/CommentStore.php at line 215] [17:53:34] They're all commonswiki [17:55:21] The Flow one can be easily protected against with an isset(), but not sure if that's the /best/ action. [17:56:11] terbium + commonswiki. Is someone running a script? [18:06:32] no_justification: Regarding the CommentStore one, looks like maintenance/refreshFileHeaders.php has a similar issue as what was fixed in I2ecb6030. The fix should be similar too. [18:07:24] And there are probably other maintenance scripts with the same issue. [18:15:19] Ah, someone's running refreshFileHeaders on commons! [18:15:25] (which is also the cause of the Flow issue) [18:20:26] Special:Preferences is broken for me on mw-vagrant (https://phabricator.wikimedia.org/P6111) Anybody else seeing this? [18:22:37] The error is essentially: Expected instance of MediaWiki\Auth\PrimaryAuthenticationProvider, got AntiSpoofPreAuthenticationProvider [18:23:43] I'm all up to date but maybe my setup has become misconfigured after some recent changes [18:38:43] stephanebisson: It's fixed in master I believe [19:11:03] Fatal error: Stack overflow in /srv/mediawiki/php-1.31.0-wmf.2/vendor/wikimedia/remex-html/RemexHtml/Serializer/Serializer.php on line 274 [19:11:07] That doesn't sound fun ^ [19:11:21] anomie: hey, I've been searching for an API module to turn global user id to username, I couldn't find any, is there a way to turn 3349 to Ladsgroup? I found the other way around: https://meta.wikimedia.org/w/api.php?action=query&list=users&ususerids=3349&usprop=groups%7Ceditcount%7Cgender [19:11:39] sorry, wrong link [19:11:48] https://meta.wikimedia.org/w/api.php?action=query&meta=globaluserinfo&guiuser=Ladsgroup [19:11:56] The other one doesn't work :/ [19:13:42] Amir1: Someone should probably add a parameter to globaluserinfo. [19:14:34] so there is none :( [19:14:51] anomie: I can work on it but the extension seems super hard to setup in localhost [19:15:08] is there a way to experiment with it with less hassle? [19:29:39] Notice: Undefined index: version in /srv/mediawiki/php-1.31.0-wmf.3/includes/specialpage/ChangesListSpecialPage.php on line 632 [19:30:29] no_justification: I see why that is [19:30:56] no_justification: Moriel will fix [19:31:14] Or wait, I wil [19:31:23] kthx [19:32:43] no_justification: https://gerrit.wikimedia.org/r/383902 [19:33:42] +2'd and backported to wmf.3 [20:44:46] Amir1: the centralauth vagrant role worked well last time I tried [23:02:28] do you think an RfC on class/method naming conventions would be worth the effort? MediaWiki core is such a hodgepodge of competing conventins now [23:03:46] for example, Something implements SomethingInterface vs. Something implements ISomething vs. DefaultSomething implements Something [23:29:33] tgr: daniel is the one you will end up arguing it with, but yeah consistency at least in core would be nice [23:31:36] it was just an example, there are many other things [23:31:55] like Foo::singleton() vs Foo::instance() vs Foo::getInstance() [23:33:06] I like "do it like everything else" rules, but if that hasn't been around since the start then there's some horrible cleanup to do [23:33:17] and LTS releases make that difficult sometimes [23:33:29] anyway, I imagine no one cares too much what exactly we end up with, I'm just curious if ending up with something at all is seen as positive or pointless overpolicing