[03:01:10] treeshadow: you should ask in #wikipedia-en-help [07:28:14] what would cause an ugly string of text to display in the header after migrating to a new server [07:30:34] c: what does the text say? [07:30:41] \'" width="0" height="0" data-mode="scan" data-site-id="5b0ebd3346e0fb0001352968">';var a=document.getElementById("vmv3-frm");a=a.contentWindow?a.contentWindow:a.contentDocument;a.document.open();a.document.write(' [07:32:53] uh sounds like something is being injected somewhere... [07:33:01] maybe an extension or in LocalSettings? [07:33:11] if you grep for the data-site-id value, do you find anything? [07:35:18] hmm, looks like i fixed it fixing another bug [07:35:38] which i shall not admit here <.< [07:47:55] c: glad I could help! :) [14:12:24] In theory, it's probably possible [14:12:31] I dunno if any solution exists [14:26:22] and phab uses ldap or oauth [16:26:06] I'm trying to upgrade to php 7.x and mediawiki 1.31, but I keep getting Class 'DOMDocument' not found errors when it tries to do things with LocalisationCache [16:26:28] I can't find any advice on the web other than "install the php-xml module," but I've already done that and confirmed what it is loaded [16:26:35] is there somewhere I should be going next? [16:26:42] s/what/that/ [16:27:21] for clarification: I did not get this error without php-xml installed and then try to fix it by installing it; it was always there [16:27:26] tsundoku: you maybe installed the wrong version of the module; make sure you installed the php7 version of it [16:27:39] I compiled php with it myself, so it's not a separate package [16:27:42] ah [16:27:55] in that case installing a package module isn't going to do anything for you; that only applies if you installed a package version of php [16:27:58] right [16:28:07] I mean, I did install a package version, but I made the package [16:28:13] and the XML module is contained within it [16:28:44] check your php configure flags for either --disable-dom or --enable-dom=shared [16:28:53] if you have the former, recompile php without that flag [16:28:58] I have --enable-dom=shared [16:29:13] if you have the latter, ensure that the dom.so file is available in your php extension dir and that php.ini is configured to load it (extension=dom.so) [16:29:26] one moment [16:29:34] dom.so present [16:29:53] there is no mention of dom.so in php.ini, so I will try that next [16:30:24] I didn't have such a line for 5.6, though [16:30:46] if 5.6 was installed via apt (not self-compiled) it'll be in a sub-ini file in the "mods-enabled" directory [16:30:56] no need to worry about that [16:31:12] otherwise it may have been statically linked instead of dynamic :) [16:31:31] anyway, that should fix your issue once you add that to php.ini (and maybe restart apache and/or php depending on how you have that set up) [16:31:43] going to try it [16:32:03] the vendor package for 5.6 in my OS users a conf.d/ subdirectory and I don't see any mention of dom.so in it either [16:33:25] very interesting [16:33:27] that did fix it [16:33:27] thanks [16:33:44] I don't know why 7.2 needs it and 5.6 didn't, but it works [16:34:00] it was likely statically linked into your 5.6 binary; that's the default PHP behavior [16:34:05] perhaps [16:34:22] I haven't looked at their build spec in a while [16:34:26] (this is Solaris by the way) [16:36:55] it's been a while since I manually compiled PHP; thankfully all of the things I currently use have up-to-date versions in package repos [16:37:33] I used to compile it for IRIX, a long time ago [16:37:38] that was generally 5.2.x [16:38:31] Solaris has vendor packages for 5.6 and 7.1 now, but the 7.1 package doesn't have fpm and I had some other reasons to compile my own [16:38:42] I used to compile it manually on windows... that was a major pain [16:40:45] must have been [16:40:53] IRIX wasn't that hard really [16:41:28] I think there was some weirdness once it got up into 5.3 but 5.2 and below were easy [17:27:03] Recently upgraded a wiki to 1.31. Running the job queue via cron. The watchlist emails are being sent out with "localhost" URLs in them. Any idea what I'm missing? [18:07:23] burfo: you probably need to set $wgServer explicitly in LocalSettings.php [18:07:35] normally it autodetects based on webserver headers, but it can't do that via cron obviously [18:09:58] Thx, I'll check that out. [19:02:07] We should make setting that more explicit probably. [19:02:15] The guessing is kind of hokey, IMO. [19:18:52] legoktm: $wgServer did resolve the 'localhost' issue; thank you. [19:47:23] hi randomredditor [19:47:28] this channel is about the MediaWiki software [19:47:48] if you have a question about a wiki's contents, please, take it to the people who run that wiki [20:22:31] I've installed mediawiki (on dreamhost one click install, fwiw) and when creating new user accounts and having the password sent to their emails they are not getting them [20:23:15] the first time I sent the email to a test account I didn't get it... so I created a second account with the same email and it worked [20:23:27] check the spam folder? [20:23:33] then I deleted both accounts, sent emails to two more accounts that I created (both with different domains) and got both [20:24:02] but I sent emails to others to create accounts for them, and they are not getting them... one is on gmail (same domain as one of my accounts that worked) and the other msn but nobody's getting them [20:24:14] and they are not going to spam folders [20:27:14] I would make sure your email is setup correctly, for example a lot of providers will filter based on SPF and such these days [20:27:39] Derk: msn is notorious at blocking emails; check to see if you got bounces [20:28:09] ok but if I create an account sending to two different gmail addresses and it gets to one and not the other, and it's not in the spam folder, then I don't know what's going on [20:28:28] the point is that if some of them are getting through, it's not mediawiki's problem [20:28:28] I mean two different accounts [20:28:38] it's further down the setup [20:28:58] hm, there's no weird rate limiting or cool down or anything? [20:29:00] either with how email is configured for your domain at dreamhost, or at the provider end blocking them (perhaps due to the IP you're using being on a blacklist) [20:29:10] not in mediawiki [20:29:17] ok, fair enough, thanks! [20:29:42] you can try poking dreamhost's support and they may have more insight into what's going on [20:34:24] So, interesting question - if a user's proxy / vpn passes XFF headers, and the VPN is blocked, should the user be prevented from editing still? [20:41:27] SQL, XFF headers should be ignored unless the remote IP is trusted to provide them [20:41:54] it strikes me as a contradiction to both block and trust the proxy [20:42:11] Krenair: that's what I thought - something I've run into a couple times now tho: https://en.wikipedia.org/wiki/User_talk:27.33.172.241#Block_Request_-_more_info the user appears to be editing from one IP, but a block from another is affecting it [20:42:15] but in such a situation I would expect the block to be ignored and the edits to go through under the IP passed by the proxy [20:42:53] Or, the editor is being less than truthful I guess. [20:43:27] unless I guess the proxy passes in it's own IP as the XFF header for some utterly bizarre reason [20:44:22] in any case, that wouldn't impact wikipedia [20:45:00] IDK, Bizzare, and I've seen it a couple times lately so I figured I'd check [20:45:07] wikipedia has trusted XFF stuff set up doesn't it Skizzerz? [20:45:25] yes but not from anywhere [20:45:36] sure it doesn't trust literally any random host out there [20:45:40] only some random hosts out there [20:46:34] a CU would reveal for sure what's going on [20:46:48] otherwise my internet is being too crappy right now for me to do much other than IRC :( [20:47:34] Fair enough. I'll chalk it up to trolling or trying to hide VPN usage in the hopes of getting unblocked. Thanks for the second set of eyes guys [20:48:59] at some point I think someone should review the list of trusted hosts tbh [20:50:58] it looks like there's stuff in there ranging from the British Columbia school network to the Saudi government [20:52:04] I think hosts on that list can impersonate any IP out there on-wiki [20:53:11] Krenair: is there a public list of those ips somewhere? Curious now. [20:53:35] noc.wikimedia.org [20:53:51] trusted-xff.php, although they're not in a format immediately human-readable [20:54:01] noc.wm.o is a silly site [20:54:14] I don't know why we still have that [20:54:27] is it not up to date? [20:54:31] Meh, just hex to IP [20:54:35] Not too hard to conv [20:54:38] it probably is but I think the site has outlived its purpose [20:54:55] *shrug* I still find it useful every once in a while [20:54:58] we have a public mediawiki configuration repository with a decent repo browser [20:54:59] beats digging through puppet configs and crap [20:55:04] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/TrustedXFF/+/refs/heads/master/trusted-hosts.txt [20:55:17] don't think wikimedia has this list overridden anywhere [20:58:44] SQL, ^ [20:59:12] Krenair: thanks :P I wrote something to convert em from hex hah [20:59:17] lol [21:07:58] Krenair: It could be replaced by a page on wikitech.wikimedia.org probably. [21:08:04] But it's still kind of nice to have an index. [21:28:46] in my install I've got it set up so only administrators can edit, users with accounts can view, and those without accounts cannot view [21:29:14] how do I disable the ability for non-administrator users to move pages? [21:29:59] why on earth would you want to do that [21:30:11] oh because only admins can edit [21:30:12] weird [21:30:12] ok [21:30:38] $wgGroupPermissions['user']['move'] = false; [21:30:42] $wgGroupPermissions['user']['move-subpages'] = false; [21:30:48] $wgGroupPermissions['user']['move-rootuserpages'] = false; [21:30:55] $wgGroupPermissions['user']['move-categorypages'] = false; [21:30:59] $wgGroupPermissions['user']['movefile'] = false; [21:31:02] Derk, give that a go ^ [21:31:09] take a look at Special:ListGroupRights once you're done [21:31:13] thanks... [21:31:15] ok will do that too [21:31:20] you may have to grant those permissions to the 'sysop' group [21:32:26] nope, that seems to have worked [21:32:31] thanks :) [22:57:01] I'm getting an explicit transaction still active error when I try to delete an image from one of my mediawiki sites [22:57:08] is there anything at all I can do about that? [23:00:11] tsundoku: the error message should tell you where it was opened [23:00:50] if that's the image deletion code, then some fatal error occured and the transaction could not be closed properly, so look for the error logs to find the real error [23:01:06] the database's error logs? [23:01:16] if it's somewhere else then some code probably opens a transaction and does not close it [23:01:27] no, wiki error logs in general [23:01:38] exception/error/fatal channels [23:02:38] you mean like this? http://ix.io/1oJ4