[02:47:45] hi everyone, i'm trying to setup mediawiki on opensuse, using the OBS repo, and i'm getting a permissions issue when trying to browse to the site via the IP [02:47:54] has anyone run into this? [03:21:55] what adds the Print/Export section to the Left Nav? [03:22:03] junix659: we don't offer a lot of support for distribution MediaWiki packages [03:23:31] ah, the COllection extension [03:26:06] well i'm going to try and get this setup on centos by hand [03:26:13] junix659: if by permission issue, you mean you got a 403 error, this is a more general how to set permissions for webserver error. Would you know if you are in nginx/php-fpm, Apache/SuEXEC/PHP as CGI, Apache/mod_php config? [03:27:03] MediaWiki evolves quickly, with a CI model. If you wish to get the same update of functionnalities than Wikipedia sites, it's a good idea to install it manually. [03:27:40] For CentOS, you can also try a Docker container. [03:31:44] sorry, this is a apache/php setup I am getting a 403 error [03:32:52] Check the user running Apache (ps auxw | grep httpd ou ps auxw | grep apache2). Change the username of the MediaWiki folder for this web server. [03:33:08] (chown -R /path/to/mediawiki) [03:33:20] i did this [03:33:25] restarted apache, nothing [03:34:04] Check every folder to /path/to/mediawiki is at least 711 (no 700). [03:34:24] Reboot isn't needed. Then, read your Apache log, it will tell you the issue. [03:35:03] ok, ig from mediawiki 1.8.2 [03:35:09] i'm [03:37:28] Dereckson, just did chown -R wwwrun:www /var/lib/mediawiki, restarted apache to take the permissions, still get a 403 [03:38:25] You don't need to restart Apache to fix permissions issues. [03:38:44] still, its a force of habbit [03:38:46] i apologize [03:39:24] Do you know where Apache stores the logs? You could tail -f to see how evolves the error message. [03:40:55] it jsut says, client denied by configuration in /var/lib/mediawiki/webroot/index.php [03:42:07] This is an allow order issue. [03:42:45] By default, Apache denies clients. It has to explicitely be allowed for a set of folders. I guess /var/lib/mediawiki is outside of your webfolder, and so not available. [03:43:17] https://wiki.apache.org/httpd/ClientDeniedByServerConfiguration gives some hints about that [03:45:00] So here, you need in the Apache2 config, for example before the VirtualHost, a block Order allow,deny Allow from all (one instruction per line) [03:48:01] ok i did that, but i'm getting this - You don't have permission to access the requested directory. There is either no index document or the directory is read-protected. - so i'm guessing i need to put Indexes in there as well? [04:20:55] Does anybody here have experience with the mobilefrontend plugin? [04:24:48] Does anybody here have experience with the mobilefrontend plugin? [04:29:23] Hi sbhepburn. [04:29:29] What's your question? [04:30:06] Hi Carmela! I have followed the instructions located here: http://www.mediawiki.org/wiki/Extension:MobileFrontend but the logo of my intranet wiki still doesn't show up on mobile view [04:30:35] I have this line in my LocalSettings.php: $wgMobileFrontendLogo = "{$wgScriptPath}/mf-logo.png"; [04:30:49] If you try to load mf-logo.png in the browser directly, does it load? [04:30:53] And I've checked and checked again that that line is correct according to the instructions [04:31:05] Yes - it does load which is why I'm so tantalizingly close! [04:31:15] ... uh.... and yet so far [04:32:21] I'm not sure you want { and }... [04:32:39] Oh! Let me try removing them... [04:33:12] Still nada D: [04:33:47] Can you inspect the page element? [04:33:50] What do you see? [04:33:54] Is it a broken file link? [04:34:08] Are you sure the page you're viewing isn't cached? [04:34:13] That's what's funny - there isn't any mention of "logo" in the page source at all [04:34:24] It's like the PHP isn't injecting the html for some reason [04:35:26] UserLoginAndCreateTemplate.php ? [04:35:32] Are you looking in the correct place? [04:36:21] Wait - where should I be looking? I'm currently inspecting source of the mobile view of the wiki (which is still logoless) [04:37:18] That variable sets the logo for the login/signup page only. :-) [04:37:30] > Path to the logo used in the login/signup form [04:37:37] > The standard height is 72px [04:37:41] From MobileFrontend.php. [04:37:45] Perhaps the docs are misleading. [04:37:51] Or that variable name is. [04:38:04] Probably both. [04:38:23] Oh! [04:38:32] You might want $wgMFCustomLogos. [04:38:43] Hmm... I was under the impression there was a logo that would be visible on each page? [04:38:45] Hmm, maybe not. [04:39:07] https://en.m.wikipedia.org/wiki/Main_Page [04:39:14] I don't see a logo there. [04:39:25] Well, there's the Wikipedia workmark in the footer. [04:39:28] Do you want something like that? [04:39:54] Oh! You know what - you're right - I think I've been misled all olong [04:39:55] along* [04:39:59] Let me check my login page.... [04:40:01] https://m.mediawiki.org/wiki/MediaWiki has no logo either. [04:40:56] Oh. My. God. [04:41:06] It's on the login screen. [04:41:09] Only. [04:41:43] *sighs* [04:41:45] Louder. [04:42:20] * sbhepburn dies a little inside [04:42:39] You should update the wiki page to be less misleading. ;-) [04:42:40] I've spent hours. *Hours* trying to get this to show up on every screen. [04:43:04] It's probably pretty trivial to insert a logo on the page. [04:44:22] The logo - it's all lossy and looks horrible - even though I made it from scratch to be the exactly requested resolution of 35 x 22 [04:44:55] =...( [04:45:00] Sounds like you're having a good day. [04:45:11] LOL [04:45:46] It's pretty much f$#@ this s%$# o'clock at this point. [04:47:01] That's how most Web development ends up. [04:47:30] So, so true. No truer words have ever been said. [04:51:58] Well, thank you so much for your help, Carmela. You were wonderful! [04:52:11] No problem. [04:52:15] exit [04:52:20] uh... [05:20:02] junix659: does it work now? [08:02:01] hello [08:02:29] marktraceur, apparently the bug I found yesterday is with WikiEditor's preview [08:02:33] but not the stock one [10:03:31] ah [10:03:59] it looks like the bug I filed isn't related to wikieditor, but with mediawiki's live preview feature. [10:07:59] Nahiyan: link ? [10:08:07] Nahiyan: since i have worked on both of those areas.. [10:09:46] oh sorry [10:09:48] uh [10:09:51] https://bugzilla.wikimedia.org/show_bug.cgi?id=73618 [10:09:53] here [10:10:02] thedj [10:10:21] good thing I spotted your message quickly... [10:11:48] um, ignore the comment saying it's related to WikiEditor.. [10:14:09] thedj? are you there [10:24:08] Nahiyan: sry, i'm at work, so my attention isn't fully on wiki things the whole time [10:25:31] ah, you are using live preview and the error dialog for scribunto is not showing up ? [10:26:47] Hi, how do I can encode non ASCII chars for the MIME headers? There is RFC2231 but if the header looks like that: 'Content-disposition: form-data; filename*=utf8''%C3%9C.jpg; name="chunk" ' it complains that 'filename' is missing. [10:33:46] Nahiyan: patch submitted. thx for reducing the problem to something more precise. [10:34:24] xzise: where i u seeing that content-dispostion [10:35:19] It's in the MIME request, right beside the binary data of the image. [10:35:45] but what url... [10:36:34] ahh [10:36:46] Puh I'm not sure about the exact URL [10:36:47] thedj, thank you! [10:36:53] thedj, that's exactly what happened [10:36:58] Why do you ask? [10:38:12] Oh sure api.php [10:38:30] https://en.wikipedia.org/w/api.php is it thedj [10:40:41] But I could get the MIME request, just wait a sec [10:41:01] xzise: i'll look in about 15 minutes ok. [10:41:15] That should be long enough ;) [10:41:17] if any details help. the codebase is big :) [10:43:14] :p thanks for the really quick fix thedj [10:44:55] ok [10:45:06] thedj, http://paste.ubuntu.com/9119715/ [10:45:18] so I sorted and sort of grouped Module:Documentation/configuration [10:45:23] looks nicer now [10:45:41] Well I use an API request so I personally don't need to worry about the codebase as long as the API does what it needs to do [10:49:43] Interestingly I could set the filename in the MIME header (line 55, not the filename 'entry' in the request line 46-51) to anything, it doesn't even need to match the actual filename [10:50:28] So in theory to allow also Unicode names I could just set it to 'test' or something, but I mean there must be a purpose for it. [10:52:34] ah, so you are trying to do an upload request ? [10:53:05] Yes via the api [10:53:21] sorry should've been more specific [10:54:47] yeah, so normally that would be the filename as it is currently on your machine [10:55:18] we probably don't do anything with it. [10:55:27] Okay, but what if there are non ASCII chars in it? [10:55:54] The RFC compliant version (in the paste) doesn't work as it doesn't detect it, directly encoded as UTF8 doesn't work either [10:56:20] Although � [10:57:23] Let me test it [10:59:09] Hmm okay using UTF8 does work [11:00:03] yeah it should.. [11:00:12] i [11:00:23] Well it's not a standard MIME request then [11:00:38] Which only allows ASCII characters in the headers [11:00:51] Also set the encoding of the entire POST to: "multipart/form-data; charset=UTF-8" [11:01:19] xzise: the spec is outdated, there have been various implementations in the wild that did 'something else' [11:01:41] And the problem is that the Python 3 library which creates it doesn't allow it to be UTF8 encoded [11:01:45] html5 now has set the rule as: make the entire request utf-8 and then the content of the filename should have the same encoding. [11:02:21] well HTML5 is not HTTP/MIME [11:03:23] true, but HTTP/MIME is broken :) [11:04:57] Depends ;) MediaWiki's specification is not following the standard [11:15:55] haha [11:15:57] 4.10.22.6 URL-encoded form data [11:16:03] This form data set encoding is in many ways an aberrant monstrosity, the result of many years of implementation accidents and compromises leading to a set of requirements necessary for interoperability, but in no way representing good design practices. In particular, readers are cautioned to pay close attention to the twisted details involving repeated (and in some cases nested) conversions between character encodings and byte sequences. [11:16:12] http://www.w3.org/TR/html5/forms.html#multipart-form-data [11:16:39] http://www.w3.org/TR/html5/forms.html#url-encoded-form-data [11:39:30] oh, my mediawiki installation is bugging out [11:40:00] database errors... [11:41:06] crap [11:57:14] apparently $wgLicenseTerms was removed in 1.23 [11:57:29] the configuration settings list wasn't updated [11:59:26] $wgHttpOnlyBlacklist as well [12:00:40] this is funny, apparently $wgQueryPages wasn't on the list but it was removed [12:00:50] I'm going to add it so I can mark it as removed [12:01:36] $wgMaxBacklinksInvalidate as well [12:01:43] hm [12:02:19] that one doesn't even have a wiki page [12:46:59] I need a bit of help [12:50:30] in the wiki, I can specify a variable's range to be (boolean) or a number [12:50:43] it looks like the code uses it both as a boolean AND a number [12:50:53] what do I put in one of these infoboxes? [12:50:57] https://www.mediawiki.org/wiki/Manual:$wgJobBackoffThrottling [12:56:47] can anyone help me with this? [12:56:49] https://gerrit.wikimedia.org/r/#/c/42061/2/includes/cache/HTMLCacheUpdate.php,unified [12:57:12] I'm writing a wiki page on that and I don't understand what the 'elseif ( $count >= 200 )' part does [13:04:23] ah, done!! [13:04:26] https://www.mediawiki.org/wiki/Manual:$wgMaxBacklinksInvalidate [13:22:37] okay, config list has been updated as well [13:23:02] and it only took me one and a half hours [13:50:29] ok, so I figured out my database errors were because of trying to make a basic extension [13:57:05] hmm, can't seem to get logging to work [14:04:48] ok.. looks like it was because I couldn't set custom variables in LocalSettings.php [14:06:12] oh good, debug log is working now [14:12:24] Nahiyan: I'm glad someone helped you figure out the bug [14:13:40] yeah! they even submitted a patch [14:13:42] thedj [14:14:29] I did some testing and apparently it was connected to the mediawiki's live preview [14:15:28] I've been working on my mediawiki installation, I still have a problem with mw.html [14:18:02] and Module:Documentation [14:19:39] or HtmlBuilder.. I don't know.. [14:21:40] Nahiyan: That's an excellent first lesson to learn in this community: thedj is the best [14:22:05] :O [14:22:11] great! [14:22:43] and I also did some edits about configuration options on the wiki and Shirayuki thanked me [14:24:44] :D supportive community is supportive, I'm glad to hear it [14:25:33] :p [14:25:40] I'm going to edit https://www.mediawiki.org/wiki/Template:SettingSummary [14:25:41] for style [14:26:09] I'm good at templates [14:26:19] see http://nanotrasen.se/wiki/index.php/Template:Item [14:26:40] I made that template so you can skip almost any parameter [14:26:57] Nahiyan: Neat! [14:27:06] the code is nigh unreadable [14:27:08] hello [14:27:12] hello b00b00 [14:27:41] marktraceur, it took a lot of tries to fix the excess newlines! :O! [14:27:43] i am on mediawiki 1.21, is there extension like ArticleComments.php that works for that version? [14:28:48] i saw only this for older versions http://www.mediawiki.org/wiki/Extension:ArticleComments [14:28:59] b00b00: unrelated to your question, but 1.21 is an unsupported version with security vulnerabilities. You likely want to upgrade. [14:30:04] thats another issue, but thanks [14:30:21] Nahiyan: Sounds cool, thanks for your help :) [14:31:01] marktraceur, same! :p [14:45:55] hmm [14:46:04] this template should be using Template:Infobox... [14:53:40] ok... it looks like Template:Infobox has been deleted about 5 times on mediawiki [15:04:34] Only 5? [15:09:04] heh [15:36:40] ok.. I'm still fixing the thing [15:41:29] I'm going to ask about recategorisation [15:42:07] because [15:42:17] it looks like it makes a new category for every language [15:46:00] uh [16:13:57] I need advice [16:14:12] there's duplicate categories [16:14:15] err [16:14:50] of the form: MediaWiki configuration settings introduced in {{{version}}} [16:15:08] and: MediaWiki configuration settings {{{version}}} [16:15:24] a comment in the template says "The category below is redundant with the category above, but is intended to make the category names uniform." [16:15:26] The former is a subset of the latter, probably? [16:15:28] OH. [16:15:30] Oh.* [16:15:30] nope [16:15:52] I don't like it because it wastes effort for editors [16:16:10] because effort spent on one form doesn't affect the other. [16:17:01] the second form seems to have more contributions put in [16:17:19] let me check [16:18:38] yeah [16:18:44] Nahiyan: You could probably use or write a bot to "fix" it? [16:18:45] looks like it [16:18:51] but the problem is [16:18:54] both have translations [16:19:21] which makes me think it won't be clean [16:20:21] The first form is more consistent with the other categories, (which I like) but the second has more translations and contributions [16:20:54] Is there any plugin to have case-insensitive URLs? [16:21:41] AlexHofstadter: You want [[StAr TrEk: InTo DaRkNeSs]] to be the same as [[Star Trek: Into Darkness]], you mean? [16:21:59] Yeah. [16:22:02] Hm. [16:22:42] WikiHow has it. I guess. [16:22:52] Possibly [16:23:36] Should I edit the source code of MediaWiki? [16:23:36] AlexHofstadter: So we have https://www.mediawiki.org/wiki/Manual:$wgCapitalLinks in core [16:23:40] But that's only for the first letter [16:24:29] Oww. [16:25:02] AlexHofstadter: http://www.wikihow.com/Say-Yes-in-FRENCH makes me think they have some magic doing redirects, but I'm not sure how yet [16:25:27] there is something that could be done using re-write rules, but ALL page titles would have to be lower case [16:25:36] Yeah [16:25:51] Which doesn't appear to be the case right now (pun accidental but I'll take credit for it) [16:26:03] WikiHow has - instead of _, but a simple .htaccess redirect should do it. [16:26:09] I sometimes wonder if an hook to decide what page retrieves from the URL wouldn't be interesting. [16:26:57] That's probably roughly what's happening [16:27:04] (but generally in another context, with some /fr /nl /de /en thoughts to offer language fallbacks and an alternative solution to the Translate workflow) [16:27:13] Or they have some middleware that checks for similar (case-insensitive) article names [16:27:32] * marktraceur wonders if #wikihow is a thing [16:27:46] Uh? [16:28:55] I'm asking in Wikihow's channel. [16:29:32] Imagine, the word Supercalifragilisticexpialidocious. I want to make it case-insensitive, so I write with .htaccess EVERY possible combination. [16:30:28] <^d> Can you not [NC] the rule in .htaccess? [16:30:43] Also you could use regexes [16:30:51] What? [16:31:05] <^d> 'nocase|NC' (no case) [16:31:05] <^d> This makes the test case-insensitive - differences between 'A-Z' and 'a-z' are ignored, both in the expanded TestString and the CondPattern. This flag is effective only for comparisons between TestString and CondPattern. It has no effect on filesystem and subrequest checks. [16:31:11] Aha [16:31:48] Oooh. [16:33:29] Thankies. [16:33:33] <^d> You're welcome [16:33:40] AlexHofstadter: or do a lower() to the passed string [16:33:48] !hack [16:33:48] https://www.mediawiki.org/wiki/Do_not_hack_MediaWiki_core [16:33:55] May the Gods bless you. [16:34:05] They won't, but thanks for trying [16:34:22] Hmm? [16:34:28] :) [16:35:59] Why that? [16:36:18] AlexHofstadter: Just a joke [16:36:53] I mean, why !hack [16:36:59] !hack [16:36:59] https://www.mediawiki.org/wiki/Do_not_hack_MediaWiki_core [16:37:04] Oh [16:37:18] I was worried Betacommand was suggesting that you edit core to make it work [16:38:33] Core? [16:38:50] You mean, the main code? [16:38:56] marktraceur: I was thinking that you could use lower() in the htaccess [16:39:15] Ah [16:39:23] Have to go. [16:40:06] <^d> There's a lower() function in .htaccess? [16:40:11] Bye. [16:40:13] Not sure if thats possible, but its an idea [16:42:28] ^d {lower:%{REQUEST_URI}} [16:43:03] with RewriteMap lower int:tolower [16:44:45] <^d> #TIL [16:45:29] Magic [17:31:46] I think I found a problem [17:32:14] Horizontal lists don't line-break for some reason [17:32:18] it does on wikipedia [17:34:23] well [17:34:26] this is ruining my navbox [18:02:16] ok... [18:02:20] here goes [18:04:24] uh [18:04:28] crap [18:08:55] What methods are possible with mediawiki if I need to have a nice title but still have a simple way to link to a page. For example; I need the title to be something nice like 'Clan Grid Controller' but I also need the url to be something like index.php/?title=fgtbw_clan_grid_controller [18:10:24] The reasoning is I'm going to have the wiki loading inside a game when people click the help button on an item. So the url request needs to be dynamic as in the title argument will always be something simple [a-zA-Z_] but I want the title on the page to not be horrible looking. [18:11:28] Like so. http://bwwiki.fgthou.se/index.php?title=fgtbw_clan_grid_controller The most simple way I can think of is to change the title text but keep the title name. [18:12:14] If that makes sense. tl;dr is it possible to change the bold title text at the top of a page without chaning the actual title. [18:16:48] AaronM: yes [18:16:51] !displaytitle [18:16:51] See . [18:17:18] you can use {{DISPLAYTITLE:displayed page title}} to override it, see that page for some config variables you might need to toggle first [18:18:52] see also: [18:18:54] !redirect [18:18:54] Redirects are used to forward users from one page name to another. They can be useful if a particular article is referred to by multiple names, or has alternative punctuation, capitalization or spellings. See [18:19:41] MatmaRex: DISPLAYTITLE has lots of restrictions. You can only change case / _/space etc [18:19:56] yuvipanda: yes, unless you disable them! :D [18:19:58] redirects are the wya to go here [18:20:02] MatmaRex: oh, you can disable *that*? [18:20:02] oh [18:20:03] ok [18:20:09] https://www.mediawiki.org/wiki/Manual:$wgRestrictDisplayTitle [18:21:18] Yea the DISPLAYTITLE seems easier in the short term but redirects feel like the better choice. I'll take the time to make the redirect pages then. Thanks you guys! [18:26:46] can anyone tell me what I can do to fix this? [18:26:48] https://www.mediawiki.org/wiki/Template:CS_cat_header [18:27:06] Here's a page it's being used on, the tags are visible and the body isn't full width: [18:27:11] https://www.mediawiki.org/wiki/Category:MediaWiki_configuration_settings_1.2.1 [18:27:34] I tried using the navbox's "style" param to change its width but it didn't work [18:28:35] also, there's a word "hlist" being output at the end for some reason, I have no idea why [18:51:33] I'd appreciate a third person's opinion on https://www.mediawiki.org/wiki/Thread:Extension_talk:ConfirmEdit/Reverts_on_ConfirmEdit%27s_QuestyCaptcha [18:51:42] holy crap documentation [18:51:55] the documentation was wrong for Template:Navbox [18:52:16] I checked the code to fix it... apparently I had to use the innerstyle param [18:53:04] Nemo_bis, hmm [19:18:37] Nemo_bis, ok, I read them [19:19:13] I have some points, 1. The server owner can do what they want but things like that aren't supported. [19:19:35] The question is whether that information is in MediaWiki's scope to answer [19:19:44] to distribute* [19:39:26] Nemo_bis, I'm writing a reply [19:51:41] Nemo_bis, point submitted [19:55:35] thanks [20:06:05] trying to fix all these is making me learn MediaWiki and all the modules [20:06:38] right now I'm checking /extensions/Scribunto/engines/LuaCommon/lualib/mw.html.lua [20:07:55] theeeeeere it is [20:08:13] I found a version that allows passing nils to mw.html [20:08:16] that should do it [20:08:46] it was bugging out because Module:Documentation calls .create() without the arguments so they're nil [20:09:34] but there's an error check that checks if the arguments have a string type [20:10:21] but it so happens that it's okay (probably) if the args are nil [20:10:23] sooo [20:10:31] I found this fixed version [20:10:33] https://github.com/wikimedia/mediawiki-extensions-Scribunto/blob/master/engines/LuaCommon/lualib/mw.html.lua [20:11:20] ahhhh [20:11:25] it's the latest dev scribunto [20:12:02] it should be fixed on the next release of scribunto, for 1.24 I guess [20:13:00] I'm just going to update scribunto to the dev version [20:14:20] INVESTIGATION CLOSED [20:18:48] Great! More errors! [20:18:52] I forgot more pages [21:44:15] Is there any way to display the currect version date the way you can display the current version? [21:47:21] $wgExtensionCredits[$type][] = array( 'version' => '1.2.3 (21-11-2014)' ...)