[11:54:10] hi, I have a problem with a mediawiki upgrade, when running update.php nothing happens [11:54:59] I am going to a redhat 7 host with apache and php71 from the redhat software collections, suspecting problems with that but not sure [12:03:11] akoopal: Could you please make a post here: https://www.mediawiki.org/wiki/Project:Support_desk? And describe your problem? [12:04:00] With all details like MW version (current), MW version (want to upgrade), PHP version, etc etc [12:04:14] sure [12:04:18] Thanks :) [14:24:01] d3r1ck: took a while, but posted it [14:24:32] :+1; [14:25:00] akoopal: It's literally displaying "config-mysql-old" [14:25:02] ? [14:25:29] "config-mysql-old": "MySQL $1 or later is required. You have $2.", [14:25:42] I'm not sure why it's not substituing it for a message (that's seemingly an installer bug) [14:26:18] Reedy: literal copy/paste yes [14:26:45] min mysql version should be 5.5.8 [14:26:50] in pointy brackets [14:27:03] server as well? [14:27:10] yeah [14:27:35] * Reedy tests [14:28:00] that requirement is indeed in the upgrade guide [14:28:32] reedy@ubuntu64-web-esxi:/var/www/wiki/mediawiki/core$ php maintenance/update.php [14:28:32] MediaWiki 1.32.0-alpha Updater [14:28:33] Your composer.lock file is up to date with current dependencies! [14:28:33] ⧼config-mysql-old⧽ [14:28:34] Confirmed [14:28:49] akoopal: Want to file a bug in phabricator for that specific issue? Or would you like me to? [14:29:07] I think you understand it better :-) [14:29:27] but my solution is likely an upgrade of mysql server and client? [14:29:33] Possibly [14:29:46] But it's a little hard to know what versions MW thinks it has etc when it doesn't tell you :P [14:29:57] yep [14:30:16] add me to the phabricator ticket please [14:31:37] https://phabricator.wikimedia.org/T206765 [14:33:06] Tracked it down [14:34:21] hmm, I have client 5.6 and server 5.6, that should be good [14:34:54] client 5.7 [14:35:06] was confused by 5.5.x [14:41:12] Reedy: put a small update on the support desk as well [14:41:28] seems the mysql version is an issue [17:30:37] any reason why native mediawiki file caching would affect ad impressions and how to avoid that? [17:32:36] don't use ads [17:33:01] :) [17:38:56] Reedy: unfortunately ads are paying the hosting costs, so without another source of revenue ... [17:48:02] "for the price of a coffee..." [17:48:34] c: By file caching, you mean..? [17:48:57] wgUseFileCache [17:49:01] I'm wondering if only at first render it actually makes an ad request or something, then caches the output, but doesn't ping the ad server or similar [17:49:33] on any subsequent view [17:50:03] probably depends on how the ads are implemented; if it's js that loads them after domready then I wouldn't see why file caching would matter [17:50:05] c: 1) add some propaganda articles to your wiki, e.g. like that wiki article claiming man who cut off their member are prime example of /Woman [17:50:17] 2) beg users for money like Jimmy Wales [17:50:21] 3) ??? [17:50:24] 4) profit [17:50:26] don't make me mute you [17:50:28] for trolling [17:53:10] c: well allright, if you don't like jokes... (though that was in fact true about Woman article on wikipedia, during few months at least) [17:59:43] Skizzerz: Via an Advanced Ads plugin in Wordpress, that uses widget type boxes. mediawiki is wrapped inside wordpress (by theme only). no other integration [23:37:28] Hi all, I'm working on an extension that requires storing some data against a user. It's a small amount of data, so naturally I've opted for User::setOption. However I've discovered that (despite calling saveSettings) it doesn't seem truly persistent between refreshes. [23:38:46] st_prg: Are you calling $user->saveSettings() after? [23:38:55] I am [23:39:11] After some digging in the loadOptions function, I have noticed there seems to be a 'default options' and an 'override options' - do I need to do anything with those? [23:42:58] Shouldn't do [23:43:08] Do you have the code you're using? [23:43:51] Sure, one sec [23:44:36] Reedy this is what I had that I thought was working - which seemingly isn't. [23:44:36] https://github.com/shanept/mediawiki-LdapAuth/blob/master/src/Auth/PrimaryAuthenticationProvider.php#L373 [23:45:49] OOI, why are you saving it to your own table too? [23:46:34] Part of a previous revision/train of thought, I haven't gotten around to removing yet [23:46:55] I was looking at linking accounts before, but I think auto-created accounts are the *correct* way to do it [23:49:50] Other extensions definitely use exactly the same pattern [23:49:55] // Save filter in user preference [23:49:56] $user = $this->getUser(); [23:49:56] $user->setOption( 'aftv5-last-filter', $params['filter'] ); [23:49:56] $user->saveSettings(); [23:50:08] So the issue is that, come time for my postAuthentication hook, I cannot simply getOption( 'domain' ) [23:50:11] Right [23:50:45] This is bizarre because mine definitely aren't persisting between refreshes [23:50:55] Are they actually making it into the database? [23:51:21] No [23:51:31] That would be the user_preferences table, right? [23:53:05] Sorry, user_properties* [23:55:51] yeah, should be [23:57:59] So I've just popped it into my postAuthentication function and it has indeed written to the db [23:58:29] * st_prg confused [23:58:40] Um [23:58:44] Is that code called from anywhere? [23:58:45] https://github.com/shanept/mediawiki-LdapAuth/search?utf8=%E2%9C%93&q=autoCreatedAccount&type= [23:58:46] I think I'll write it off as something bizarre that I've broken... [23:58:50] The function looks orphaned [23:58:54] Or weirdly dynamically called [23:59:08] unless the parent calls it.. [23:59:10] * Reedy looks [23:59:28] It is called, yes