[11:05:41] does the offline content generator work at the moment? [12:22:52] can we create new namespaces when mw is alreay installed and in use? [12:23:27] sup peoples [12:34:24] vev_: yes. if you have any pages in the "fake" namespace right now, you'll need to run a maintenance script afterward (/maintenance/namespaceDupes.php). [13:17:48] what about this "Do it early. Manipulation of $wgExtraNamespaces must be completed during MediaWiki initialization; for instance it cannot be manipulated in a post-initialization hook like $wgExtensionFunctions." [14:42:55] anyone? [15:07:43] khodafez: what about it? [15:14:06] Yaron: vev_'s questions [15:14:21] question* [15:15:13] vev_ and i are working together [15:15:52] Yaron: we think the answer is yes: can we create new namespaces even if mw is already in use [15:16:30] Didn't MatmaRex answer your questiion? [15:16:56] yes [15:17:02] but khodafez sees [15:17:05] well, I got it from https://www.mediawiki.org/wiki/Manual:Using_custom_namespaces [15:17:09] khodafez: that seems to be about extensions that add their own namespaces [15:17:22] Do it early. Manipulation of $wgExtraNamespaces must be completed during MediaWiki initialization; for instance it cannot be manipulated in a post-initialization hook like $wgExtensionFunctions." [15:17:38] khodafez: vev_: Wikipedias in various languages gain new namespaces all the time and nothing bad happens [15:17:47] oh ok :) [15:18:19] thanks [20:40:51] Hi! Is anyone here? [20:40:51] Hi Choco31415, I am here, if you need anything, please ask, otherwise no one is going to help you... Thank you [20:41:12] I come with a problem involving http, https, and email links on Mediawiki. [20:41:27] Basically its preventing a page from saving. [20:41:53] However, links formatted like //www.google and {{Link|www.google}} do not cause the problem. [20:41:59] Any ideas? [20:43:03] Choco31415: do you mean that saving an edit that adds a link, causes the save to be rejected? do you get any error message? [20:43:30] Here's a more detailed description on what is happening: [20:43:30] http://serverfault.com/questions/715002/sporadic-problems-saving-edits-in-mediawiki [20:44:33] I'm trying to get another opinion on the issue because the one we got above does not seem to help us. [20:46:10] the "dowload php file" may happen on a severe error from the webserver, like a segmentation fault [20:49:13] I'm given the message to our group chat. [20:49:35] you should get an entry in the error.log file if this happens, though [20:50:22] well, if you're in a shared host, you probably don't have access to the general log [20:54:10] I only have FTP rights. [20:55:35] Choco31415: Slightly off-topic - but you're aware that $wgRawHtml is really insecure unless you trust every single person who has a login to your wiki? [20:55:40] best you can do in this case is, gather at which time this happens, and open a ticket to your hosting, so they can look at the logs and investigate [20:56:19] Choco31415: Some shared hosts will provide a copy of your error log somewhere accessible from ftp (although lots do not) [20:57:06] The other people in my group have other rights. [20:57:11] They can access phpMyAdmin. [20:57:19] And the wiki database. [20:57:54] Choco31415: Do any of them have access to a cpannel type interface? Often that has a link to an error log [20:58:29] if the problem is a segfault, it may not be logged on the user account of the executing page, but on a private general error log [20:59:40] No cpanel. [21:00:07] We do not have access to the error log. [21:00:18] *Edit: we do. [21:00:21] I'm getting it right now. [21:00:24] Via email. [21:01:02] The problem is that we're not getting any error messages. [21:01:09] interesting [21:01:11] Also, some time we get it, and sometime not. [21:01:50] Choco31415: I can reliably get a 503 with the following request: http://scratch-dach.info/w/api.php?action=parse&text=http://test.name%20foo%20[https://example.com] [21:01:57] Maybe apache mod_security is installed [21:03:37] Do you want to see the error log? [21:03:59] The wiki server is up. [21:04:04] I wonder why we're getting a 503? [21:05:09] The group says it doesn't seem to be a php interpretation problem. [21:06:34] Are you able to get a list of apache modules? mod_security / mod_security2 are known to cause these types of problems [21:06:52] Try making a php file containing just And then see what it's output is [21:07:18] http://pastebin.ca/3270680 [21:09:50] Hi again! [21:09:55] My computer went into sleep mode. [21:10:16] If you missed it earlier, I said [21:10:20] 16:06] Are you able to get a list of apache modules? mod_security / mod_security2 are known to cause these types of problems [16:06] Try making a php file containing just And then see what it's output is [21:10:27] That's the last I caught. [21:10:29] yep, that's all I said [21:11:12] I'm asking... [21:11:19] from your log file: FastCGI: "/..../w/index.php" aborted: incomplete headers (0 bytes) received from server after 3 sec [21:11:37] It might be that FastCGI has way to short a timeout [21:13:23] Choco31415_: Also, PHP Fatal error: require_once(): Failed opening required .../w/includes/normal/UtfNormalUtil.php [21:14:07] But there is no log error message? [21:14:45] Is interesting. Can you verify that the file /w/includes/normal/UtfNormalUtil.php exists. If its missing, that could explain why you sometimes have fatals [21:15:45] Someone will be joining us. [21:15:49] hello? [21:15:52] Hi Arne! [21:18:21] @bawolff, we have someone closer to the server. [21:20:01] Is there a connection between the UTF and url error? [21:20:14] It doesn't seem so. [21:21:39] Choco31415_: I don't think so. Looking closer, if that file was missing, your wiki would not work at all [21:22:36] Arne should be on in 10 seconds. [21:22:39] *about [21:22:50] Assuming he finishes his monologue. [21:23:11] I am here now [21:24:02] I don't think there is a connection between the UTF and the url error. [21:25:04] Most likely, I'd guess there was some sort of over-active security filter, that's being triggered (like apache's mod_security) [21:25:12] I don't have any idea what coud be the reason. I disabled all extensions, we updated to mediawiki 1.25 and so on... [21:25:24] http://scratch-wiki.info/phpinfo.php [21:25:28] one moment... [21:26:48] How would you check if we have mod_security activated? [21:28:40] some servers expose the installed modules in the HTTP Server: header, but that doesn't seem to be the case here [21:28:41] Also, this problem has only happened after the Wiki changed providers. [21:28:52] and the wiki workes fine the first 3 months after changing the provider [21:28:58] I was thinking phpinfo() would expose it, but that doesn't happen with fastcgi [21:29:08] Why did you change to a provider using such an ancient OS? [21:29:19] I guess you'd need access to apache config file [21:29:39] (It of course could be some other sort of filter, that's not mod_security. Or it could be something totally different) [21:29:44] The old provider's database size limit was too small. [21:29:50] 1 GB [21:30:06] And the new provider is cheaper. [21:31:01] or it might be Vulpix's theory about php segfaulting [21:31:44] Anyways, I can reliably reproduce by putting "http://example.com http://example.com" (no quotes) into http://scratch-dach.info/wiki/Spezial:Vorlagen_expandieren [21:31:49] We don't know what it is? [21:32:03] Nvm, Arne does. [21:32:27] What makes you think its segfaulting? [21:32:47] Unrelated, but you're missing two point releases with various security fixes [21:34:29] Do you know how we would see a segfaulting error? [21:34:30] AlSame thing with the security fixes? [21:34:56] it may be a segfault, or maybe a blank page... fastcgi can break terribly if headers are not correctly set, etc [21:36:52] Choco31415_: Ultimately, you should probably ask your host to investiagate. If they're not helpful, I'd reccomend switching to a different host [21:37:29] The interesting thing is this only happens at one of our wikis. [21:37:38] The DACH wiki experiences the problem, but not Id, Ru, Jp, ect... [21:40:09] Well the id wiki is on a totally different version of MediaWiki [21:40:28] Id, yes, but I believe the test wiki is not. [21:40:35] http://test.scratch-wiki.info [21:40:47] 1.25.3 [21:41:29] 1.25.3 is close to 1.25.1 (DACH) [21:41:30] http://test.scratch-wiki.info/wiki/Special:ExpandTemplates seems to experiance the same error [21:42:58] Odd. [21:43:02] That's new. [21:43:05] It was working earlier. [21:43:11] Maybe its the database size? [21:43:29] We're not getting error messages. [21:43:30] I don't think so [21:43:43] Will you be on tomorrow? [21:43:52] if this only happens when adding external links, looks like an anti-spam measure [21:43:59] External, and emails [21:45:30] Will you be on tomorrow? [21:48:24] I will ask at the provider the mod_security is enabled or not [22:07:10] lol [22:07:26] https://phabricator.wikimedia.org/T103667#1826683 - doesn't the 24h message completely vanish the attempt to not disclose if a particular email address is registered with an account? [22:10:43] unless the message is returned always even if the email address doesn't exist... but I suspect it's not the case [22:10:56] Vulpix: yea, good point. agree [22:16:08] Vulpix: and _now_ i got a hit in the logfile.. [22:17:34] well, the 24h message may be tied up to the IP address requesting the password reset, not the target account... but I'm not sure about that [22:19:53] if it's the 1st case, it would be a complete failure :P