[05:42:40] ㅎㅎㅎㅎㅎ [05:43:12] 불렀으 면말을 하ㅣ [11:59:25] hmm. this is probably a stupid question on my part. but is it possible to undo all changes made to a mediawiki page say, over the last five or six months? [12:00:46] greeter: Go into the page history, find the last revision you want, view it and hit edit, then save the page? [12:00:59] alright, i'll give that a shot [12:01:41] perfect :-) thanks [12:15:25] You've probably already seen this, but a friendly reminder just to be on the safe side: We won't be able to edit the wikis for about half an hour or so today because of some testing. [12:15:29] This starts in about two hours. https://meta.wikimedia.org/wiki/Tech/Server_switch_2016 [13:06:28] morning [13:17:01] JohanJ: thanks! :) [15:28:11] Are all the fancy date things like "Template:Weekday in month" that Wikipedia uses available packaged up somewhere? [15:28:48] G_SabinoMullane: You could use Special:Export on https://en.wikipedia.org/wiki/Category:Date_mathematics_templates [15:31:24] Thanks, seems simple enough, will give it a go. [15:55:20] Ran into https://phabricator.wikimedia.org/T47750 (but getting further) [16:07:48] I made img_auth and apache get in a fight and now I can't make them stop -.-; [16:08:54] the documentation recommends and Alias between the images directory and img_auth.php to forward requests to the correct place, but that doesn't seem to help much if the url already has the word images in it. Can someone direct me to the correct rewrite syntax for an apache config to correctly redirect instead of giving my webserver the vapors? [16:23:30] I don't understand $wgScriptPath: https://www.mediawiki.org/wiki/Manual_talk:$wgScriptPath#Is_a_directory_name_really_legit_here.3F [16:23:59] Parsoid and OCG assume that this is a virtual path we can use to build URLs. The Manual and some of the other talk page comments seem to think this can be a filesystem path instead. [16:24:30] who's right? how should we build our URLs if we can't use $wgServer . $wgScriptPath ? (as reported by siteinfo) [16:27:27] cscott: it's a virtual path. $IP is the filesystem path. [16:28:10] cscott: i guess it depends on what you and the documentation mean by "virtual path" [16:28:25] it's a URL path, let's say. [16:29:19] MatmaRex: https://www.mediawiki.org/wiki/Manual:$wgScriptPath says "or the actual directory into which MediaWiki is installed" [16:29:46] and https://www.mediawiki.org/wiki/Manual_talk:$wgScriptPath discusses setting `$wgScriptPath = dirname($_SERVER["SCRIPT_NAME"]);` which is also a filesystem path. [16:30:25] cscott: well, most of the time it will also refer to an actual directory [16:30:30] but it doesn't need to [16:30:53] oh, wait, maybe not: "'SCRIPT_NAME' Contains the current script's path. This is useful for pages which need to point to themselves." versus "'SCRIPT_FILENAME' The absolute pathname of the currently executing script." [16:31:15] $wgScriptPath is the thing that you put between the domain name and the index.php when building URLs. [16:31:19] MatmaRex: I have a user which has it set to /var/www/mediawiki/ [16:31:20] its whole purpose is to build URLs with [16:31:33] cscott: well, that user did it wrong then [16:31:42] does their wiki work with that? [16:32:04] MatmaRex: apparently! [16:32:28] perhaps they also set $wgArticlePath to something that actually works, and so the broken $wgScriptPath value is not ever used [16:32:33] everything except for generating PDFs from pages with images using OCG -- OCG chokes on the bogus $wgArticlePath [16:33:00] no, $wgArticlePath is missing in their LocalSettings.php, so it's generated from $wgScriptPath [16:33:44] could you respond to my question at https://www.mediawiki.org/wiki/Manual_talk:$wgScriptPath, to record our consensus that filesystem paths are bogus? then I'll figure out an edit to Manual:$wgScriptPath to make it clearer that filesystem paths aren't appropriate. [16:35:11] done [16:42:29] 12:35:10 PM) cscott-free: Umar: it looks like your $wgScriptPath should be just '/', although see https://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory [16:42:29] (12:38:39 PM) Umar: ok with this setting [16:42:29] (12:38:50 PM) Umar: i open my site http://ocg01.mysite.local [16:42:30] (12:39:03 PM) Umar: then its automatically redirected on http://index.php/?title=Main_Page [16:42:58] sigh. that's why wiki_in_site_root_directory isn't a good idea, I suppose. MatmaRex -- any advice? [16:44:32] wut [16:45:14] cscott: that is super weird [16:45:26] wait, maybe it should be $wgScriptPath = ''? without the trailing slash [16:46:01] cscott: perhaps something is redirecting to $wgScriptPath + '/' + 'index.php?title=Main_Page' [16:46:20] and with this config, this results in //index.php?title=Main_Page, which is treated like protocol-relative URL [16:46:50] ah, yeah. Umar reports that setting $wgScriptPath to '' works. [16:46:59] so i think you're right, there's a double slash issue somewhere [17:50:36] Howdy, When creating my wiki I also created an admin user with the wizard. Now I'm using external auth; and want to get rid of the initial user? How can this be done? [17:51:34] Looks like Extension:UserMerge *might* work but meh [17:52:30] what's the problem wit that user? [17:52:41] you can simply not use it [17:53:12] (simply trying to understand your problem) [17:53:13] Platonides: I probably should have called it Administrator; I gave it a username with my name so now I have two accounts [17:54:02] fignew: you could rename it [17:54:04] Also; It's not two-factor auth like our external auth so potentially a security issue [17:54:14] Renaming would wold [17:54:16] as well as demote it and block [17:54:19] work* [17:54:28] !e RenameUser [17:54:28] https://www.mediawiki.org/wiki/Extension:RenameUser [17:55:33] I wanted to demote the user but I couldn't find it when searching in User rights managemen [17:56:17] Could be because of a space in the username? [17:56:26] I'll rename it to Administrator and see :) [18:02:15] Platonides: do I need to escape spaces or something when searching for a user? It's saying user doesn't exist for the renameuser extension :( [18:02:50] no [18:03:05] just provide the name in utf-8 [18:03:21] does it still appear on listusers? [18:03:31] maybe you already got rid of it in some other way… [18:04:45] Yes, still in my userlist; Didn't attempt anything yet. Could be related to external auth? [18:11:57] maybe [18:38:57] Okay so I'm wondering if i can make a wiki family from the same database? [18:39:20] and please do not redirect me to the help page it is too confusing for me [18:39:38] You can, but if you ever decide that you want to split them later it will be rather annoying and difficult. [18:39:59] or you could use table prefixes for different wiki [18:40:14] Yep: https://www.mediawiki.org/wiki/Manual:$wgDBprefix [18:40:17] okay. how could I do it through the same database since I won't be splitting them anytime soon? [18:40:26] Oh ok. [18:41:16] how do I get them all connected if they are sundomains? [18:41:26] subdomains* [18:42:21] what would be the easiest way to go about it? [18:43:41] Will there be a separate Mediawiki installation folder for each wiki? [18:44:22] yes [18:44:55] When installing them use the same database connection details, but with a different $wgDBprefix for each.(I believe it says "Database prefix" in the installer.) [18:45:41] Okay I got that part. then how would I connect them all afterwards? [18:46:14] For sharing things like media files? [18:46:36] and user and block tables yes. [18:46:49] and user group tables [18:47:31] Ohhhh, yeah, that gets a bit complicated. https://www.mediawiki.org/wiki/Manual:Shared_database [22:33:37] I have a reason to add a second namespace for files. Is there a convenient way to designate a new namespace as being of type File? [22:34:33] no, it's not possible :( [22:34:55] That makes me sad too. [22:34:56] File and Category namespaces are quite hopelessly hardcoded [22:35:37] Phooey. I'm using a separate namespace for public stuff that does not require login to view. [22:35:55] Want corresponding functionality for associated files. [22:36:09] Looks like I'll just hsave to host them off-wiki. [22:36:32] Unless somebody has a clever solution? [22:48:30] FlipBill: Per-namespace read restrictions? [22:59:37] Leah, perhaps. Is that an extension you are suggesting? [23:00:22] I'm current got a whitelist to make a single namespace public. [23:00:30] Trying to keep it simple. [23:00:53] FlipBill: Granular read restrictions aren't really supported in MediaWiki. [23:01:17] Your single public namespace may leak data from private pages. [23:06:58] Yeah, I've seen those warnings. I haven't seen specific examples. [23:10:10] FlipBill: https://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions [23:10:23] (not so specific, but more specific than "there are issues") [23:10:35] it's possible to handle all this right, just difficult [23:22:12] MatmaRex, thanks. That's a good checklist to run through. I'm not dealing with super secure stuff. Just preferred confidential and small site with limited set of editors. Want to expose a few pages for read access to public.