[00:26:32] hi everyone! [00:26:53] is it possible to check if a user is logged in from LocalSettings.php ? [00:27:18] i would like tweak the settings depending on wether the user is logged in or not [00:27:40] but it seems that the $wgUser object isn't available in LocalSettings.php [00:27:47] at the time LS is executed MW is mostly not initialized yet, so you'll have to use an extension function [00:28:31] extension function? you mean a function introduced by an extension? is there one available or I have to make it ? [00:28:32] $wgExtensionFunctions[] = function() { RequestContext::getMain()->getUser()->isLoggedIn() { ... } }; [00:28:40] ah [00:28:41] thanks ! [00:33:07] any default log for visualeditor ? [00:33:40] i don't have parsoid, and mine don't load, it's normal because depends on parsoid ? [00:35:50] Hi, I'm having a spot of trouble with an upgrade of my mediawiki to 1.27, I'd really love some help if I could get it. [00:36:05] Baloogan: try describing your problem [00:36:23] if someone knows about your problem, will probably chime in [00:37:10] I use DataInvoker to serve data from a database, and I get a blank page with "Exception encountered, of type "Error"" on it. Nothing is added to my /var/log/httpd/error_log file [00:37:44] My wiki works, but any page that uses DataInvoker (which used to work under earlier media wiki versions) gives me that. And I can't go fix the issue since I don't get a useful error [00:38:24] I'd double checked the db credentials, and before if the db was having an issue or the credentials were changed I would get a useful error and the page would render mostly correctly. [00:38:34] Example of this error: https://wiki.baloogancampaign.com/index.php/EnumOperatorCountry?Country=Austria&CountryID=2007&Year=0 [00:39:22] !wg Debug | Baloogan [00:39:22] Baloogan: https://www.mediawiki.org/wiki/Manual:%24wgDebug [00:39:33] er… no [00:39:50] https://www.mediawiki.org/wiki/Manual:How_to_debug#Logging [00:40:02] Thanks [00:40:13] that should help you get started [00:56:38] it's possible to render a sidebyside 2 column of "mw-collapsible ? [00:59:37] * legoktm slaps MaxSem [01:00:00] MaxSem: using $wgUser or requestcontext in an ExtensionFunction will break stuff [01:00:16] https://www.mediawiki.org/wiki/Manual:$wgExtensionFunctions [01:00:25] > Note however that at this point the RequestContext is not yet fully set up, so attempting to use it (or equivalent globals such as $wgUser or $wgTitle) is liable to fail in odd ways. [01:20:17] hey people. just read about an awkward yet desperately simple attack vector on webpages, and mediawiki - and that counts all wmf wikis - is affected. fairly high risk of phishing is involved :/ [01:20:30] that's bad [01:20:40] that's pretty much where i'm at [01:20:55] could you open a security task at https://phabricator.wikimedia.org ? [01:21:14] sure, wasn't entirely certain where to do so [01:21:16] hopefully it won't be as bad as it sounds, but… [01:21:23] oh trust me, it is [01:22:13] pity is there's already a commit about it >_< [01:23:13] I find strange that it works on any webpage and it's not well-known [01:23:37] @Platonides thank you very much, found the issue, was an issue I've fixed before but simply not having the ability to see the error means I was lost until you showed me the way :D thank you [01:23:46] :D [01:23:49] you are welcome [01:24:39] * Platonides recommends Baloogan to share his patch so other users can benefit, too [01:35:28] ;) well I'm not sure I'd want to take on the task of supporting patching this extension from php5 to php7.. [01:40:49] Baloogan: in such case, I advice to publish the patch, and state so [01:41:25] a comment like "This is how I fixed it on my local wiki, but I don't wish to support the extension migratation and sheperd it." [01:41:46] it'd be beneficial to have it in the extension repository [01:42:22] generally when you patch it locally, submit upstream, so you can avoid to have to maintain a separate release/branch/code [01:43:03] if not, you'll end with too many correctives and upgrades will be an hell [01:43:36] so in the long term, you simplify your life with patches upstrem [07:50:28] Hello [07:50:40] Is the function wfFindFile() bugged for linux hostsß [07:51:10] Its working correct for a windows environment, but keeps returning me false for my linux server [07:52:45] Nevermind, the function is working fine.- [10:35:48] Is anyone familiar with an issue with MediaWiki over Cloudflare's HTTPS where the stylesheet URLs get 'ruined'? [10:36:49] On my wiki: http://theinfosphere.org/, when I call with HTTP, the stylesheet-hrefs start with 'http://theinfosphere.org/', but when I use HTTPS, they turn into 'https://theinfosphere.org:80/'. [10:37:09] Which obviously won't work, as there is no TLS handling over port 80. [10:37:27] Indeed, my browser throws a fit: SSL_ERROR_RX_RECORD_TOO_LONG [10:38:31] if your wiki should be accessed only in https, try setting $wgServer with the https protocol [10:39:47] Vulpix: It can be accessed both ways. [10:40:00] I just want both to work. [10:42:07] try setting it protocol-relative, $wgServer = '//theinfosphere.org'; [10:42:20] Vulpix: Thanks, that worked. [10:43:03] you should also set $wgCanonicalServer with the preferred protocol for mails [10:43:35] Vulpix: Good thinking. [11:04:12] Hello. Are there any tools to make it easier to restructure an article, like changing the order of heading, or "promoting" a heading and all its subheadings (i.e. making them one level deeper than before) [14:00:20] Hi abramelin. [14:00:23] There's VisualEditor. [14:00:43] Or you can write a bot/script that does a find/replace, if you know Perl, PHP, Python, etc. [14:02:32] Debra Does VisualEditor let me change the order of headings (and their contents) easily? [14:05:13] Maybe more easily than editing wikitext. [14:33:31] hiho [14:35:40] can someone help me with an error from mediawiki? [14:36:40] !ask | Battlelore [14:36:40] Battlelore: Please feel free to ask your question: if anybody who knows the answer is around, they will surely reply. Don't ask for help or for attention before actually asking your question, that's just a waste of time – both yours and everybody else's. :) [14:37:45] ok thx :) [14:38:28] i got this error after i install mediawiki http://pastebin.com/ZQe5P1VD [14:38:40] and i dont know what i can do now [14:42:42] operation not permitted renaming /tmp/l10n_cache-de.cdb.tmp.1845336236 to /tmp/l10n_cache-de.cdb , shouldn't happen since the original file is already here and probably created by MediaWiki, unless that /tmp folder is shared with other users and /tmp/l10n_cache-de.cdb already exists... [14:44:07] so should i delete this files? [14:44:33] Battlelore: if your wiki is already setup (you have a LocalSettings.php) you can try setting https://www.mediawiki.org/wiki/Manual:$wgTmpDirectory in a folder exclusive for your installation, giving it proper permissions and not accessible from the web [14:45:27] yeah it is setup i habe the LocalSettings.php [14:45:31] have [14:45:33] * [14:45:33] I'm wondering why MediaWiki it's trying to rename that file to the same /tmp directory... maybe you've set up any cache directory to /tmp? [14:45:56] the tmp folder is empty [14:49:35] hi ! [14:49:49] hi [14:50:10] anyone knows how to get the raw url of an image through the javascript api, given the title name? [14:50:18] Vulpix do you can write the path where i have to made the changes` [14:51:07] im building an extension that would show the full size image when hovering over a gallery thumbnail, so i have the title of the image, what i need is to get the raw url of it .. [14:51:16] im checking the javascript api docs but no luck yet .. [14:54:52] Battlelore: you need to edit LocalSettings.php and set $wgTmpDirectory to a path writable by the webserver, ideally one that's not accessible from the web [14:55:28] maybe you can just create a new folder inside the /tmp folder for your wiki to prevent clashes from other apps/customers [14:55:51] ok thx, ill try it now [14:56:06] using the /tmp on a shared host is scary, though [14:57:16] in the localsettings.php is no $wgTmpDirectory [14:57:28] or should i add it? [14:59:24] yes, you should add it [15:00:13] note that this is a php file, you need to put strings inside single or double quotes, and add a semicolon at the end of the line [15:01:15] $wgTmpDirectory; [15:01:19] like this? [15:03:23] Battlelore: $wgTmpDirectory = "/tmp/yourdirectory"; [15:05:14] it seem like it work now *.* [15:05:33] thank you Vulpix [15:05:48] yw :) [15:11:08] oh, Sophivorus wasn't patient enough to see a response... [15:14:18] hi ! [15:14:32] so say i have a file name such as File:Example.jpg [15:14:41] how can i initialize a File object for it ? [15:15:01] something like File::newFromText( 'File:Example.jpg' ); [15:15:05] !class File [15:15:05] See https://doc.wikimedia.org/mediawiki-core/master/php/html/classFile.html [15:15:27] im looking at it, but it requires a repo object [15:16:46] also, it's an abstract class [15:18:08] yeah, you should get the LocalFile class instead [15:18:31] but I don't know how to get to it from a Title... [15:18:34] !class Title [15:18:34] See https://doc.wikimedia.org/mediawiki-core/master/php/html/classTitle.html [15:19:57] to create a localFile object, a repo is needed, im trying to figure out how to create that [15:21:13] you probably don't want it created, but get a reference to the existing one [15:21:37] ah, thanks [15:22:32] you may want to take a look to one of the Api classes that do things with files [15:22:37] !class ApiQueryImageInfo [15:22:37] See https://doc.wikimedia.org/mediawiki-core/master/php/html/classApiQueryImageInfo.html [15:25:28] Sophivorus: ah, there seems to be a global static function wfLocalFile() accepting just the file title :) [15:26:27] awesome :D [15:28:03] Vulpix: that was it vulpix, many many thanks [15:28:21] by the way, im thinking that if mediawiki is the story of the slow move from global variables to objects [15:28:38] I found it inspecting that api class code [15:28:48] then it would make a lot of sense to create a bunch of shorthand methods in the global $mediaWiki object [15:28:57] like getSkin [15:28:58] getUser [15:29:02] getWhatever [15:29:24] so that we can always use just the global mediawiki user to get whatever we need [15:29:29] without having to use old globals [15:29:48] or doing weird travels through the object hierarchy [15:30:17] sorry, the global mediawiki object* [15:39:49] anomie: hey, do you have a minute? I have a question for standard in query response in API [15:40:16] Amir1: What's the question? [15:40:21] https://gerrit.wikimedia.org/r/#/c/299284/30 [15:40:37] In the Daniel's comment [15:40:49] he suggests that we use a more compact response [15:41:19] but I checked every API response in mediawiki core and all of them were like each row = an array [15:41:48] If you think it's not a big deal. I think it's easy to make it compact [15:41:57] (A note there would be awesome) [15:42:36] Amir1: The comment on PS30? [15:42:47] Yeah [15:51:01] https://twitter.com/codelitt/status/768833890895040512 [15:51:15] Some nice words for MediaWiki [15:51:38] Lightweight? lol [15:54:38] lightweight! [15:54:51] i wish i could figure out this LDAP stuff :( [15:55:35] Amir1: It could go either way. Your current style seems to resemble the output for most existing modules in core, but with the underlying DB query you're using there's no reason you couldn't do a structure like Daniel is suggesting if you want to. BTW, I note you have the possibility for a 'url' property in there, which would fit a bit nicer with Daniel's scheme since it depends only on the entity and not the aspect: "wbentityusage": [ "Q7":{ [15:55:35] "url":"...", "aspects":["O"] }, "Q9":{ "url":"...", "aspects":["S"] } ] [15:56:11] anomie: amazing, thanks [15:56:39] I know the Daniel's suggestion is much better. I was thinking if it's some kind of standard way to do it [15:59:33] i want to somehow figure out how to configure LDAP authentication to move users into groups that can only see X categories [16:01:03] CKoerner_WMF: nice change from everyone making fun of our code quality [18:03:16] I recently upgraded to MW 1.27.0 and now have some errors for thumbnails in Special:ListFiles and Special:NewFiles for XCF images that are large and complex files. Smaller XCF files creates thumbs (showing one layer). Previous MW did not display XCF thumbs at all, which was not a problem. The error message is a bit long but ends with "Error code 137" relating to ImageMagick failing to... [18:03:18] ...convert the source file into a PNG for some reason. Is there a way to disable thumb-generation for specified file types or simply suppress the error? [18:03:44] MW has a timeout for rendering images [18:03:57] code 137 means timeout was reached [18:04:38] Ok. That explains, as the file size is 37MB [18:06:40] err wait [18:06:55] That's the error code for the process being killed (124 is the timeout) [18:07:12] Which is still probably a similar issue, but might be memory limit instead [18:07:28] Ok. [18:08:15] Anyways, if you want to disable, try putting unset( $wgMediaHandlers['image/x-xcf'] ); [18:08:21] in LocalSettings.php [18:08:41] that would disable for all xcf (This only works on 1.27 or less. that won't work on 1.28+) [18:08:54] There's probably a way to just kill the error well keeping xcf if you want [18:09:49] If you edit the page MediaWiki:thumbnail_error on your wiki, it will change how thumbnail errors are shown. Deleting the $1 should remove the big long error statement [18:11:52] And if you want to just make the files work, try adjusting variables that start with $wgMaxShell... [18:17:57] The "unset( $wgMedia..." gave me an instant fix and a Gimp icon instead for XCF thumbs for the current version and speeded up the Special:NewFiles page rendering. [18:19:30] Many thanks for your many solutions, all of which are most helpful. [18:24:40] There's an equivalent for 1.28+ when you eventually upgrade, its just different then 1.27 due to changes in media handling code [18:34:40] I found setting $wgMaxShellMemory = 0; generated the XCF thumb. Not sure what a good value is. Anyway, once the thumb was generated it's there and I removed the 0 memory limit as I trust in MW's default. [20:52:24] anomie: Do you think having a class named CSPFalsePositive that has the list as a constant, and a single method isFalsePositive() would be a good solution? [20:53:19] bawolff: I think $wgCSPFalsePositive = [], then set it in CommonSettings.php (or maybe a file included from CommonSettings.php) would be a good solution. [20:54:10] I think I'd want the false positive urls to also be there by default for third-parties [20:55:04] I could include it all in DefaultSettings.php, but if it gets really long we might not want to do that either [20:55:08] OTOH, putting it in code means you either have the hard-coded list plus the configured list anyway, or people have to patch the code in order to add one. [20:56:19] I'm also pretty unsure how long the list will end up being [20:57:17] Given how much adware exists and likely domain-hopping to try to avoid blockers of various sorts, I'd think it would get very large. [20:58:01] Perhaps, although I imagine sophisticated malware would be smart enough to insert itself in a way that's not blocked by CSP [21:00:32] anomie: So, do you think putting it in includes/DefaultSettings.php for now would be good, and if it turns out to be so huge we don't want it there (more than 500 entries?), we move it to some other system [21:00:39] ? [21:01:19] bawolff: It'd be better than hard-coding it in a class somewhere, anyway. [21:01:31] ok, I'm going to do that [21:01:43] I agree that users should be able to add custom entries as the need arises [21:02:10] what do you want to do? [21:03:38] treating malware as a false positive is strange [21:03:42] Platonides: This is in reference to https://gerrit.wikimedia.org/r/#/c/306765/ [21:04:59] so False Positive as in "this is not in the wiki, it was blocked because the user browser is hijacked and modifying our content" [21:09:13] yep [21:09:29] Which well sad for the user in question, there's not anything we can really do about it [21:11:53] uploaded a new version of the patch [21:12:23] * bawolff is hopeful this patch could be reviewed quickly, and maybe make it into the next swat window [21:16:15] so then I could have the weekend worth of csp data with those entries filtered out [22:44:13] Anyone willing to review https://gerrit.wikimedia.org/r/#/c/306765/ ? /me would like to try to sneak it into swat window if it gets reviewed in time [22:44:50] bawolff: $this->getConfig()!! [22:45:04] Right! I should know that [22:45:17] Just a minute [22:51:26] legoktm: how about now? [22:51:57] bawolff: you didn't remove the global line :P [22:52:56] This is what happens when I try to do things too quickly ;) [22:53:25] Ok, sixth time's the charm :P [22:53:39] xD [22:53:42] +2'd [22:53:45] Woo [22:53:47] thanks [22:56:25] are we sure this won't break wikisource ? :-p (poke Dereckson :-p ) [22:57:59] Alphos: Is that directed to me? [22:58:56] wikisource issue was typehint signature mismatch, there is no typehint in 306765 [23:00:03] I promise this will not break wikisource [23:00:06] :P [23:00:16] Only wikis that are possibly affected are elwiki, testwiki and test2wiki [23:00:22] bawolff mostly directed at Dereckson :p [23:00:27] And it won't break those either ;) [23:00:35] don't mind the madman behind the plastic screen and copper wire :D [23:06:55] ¿Este es el canal de soporte del software? [23:07:39] si, pero in ingles [23:08:06] Oh. :) [23:08:06] most of us don't speak spanish (that was about as much as i could do), sorry ;) [23:08:42] I think there is a #mediawiki-es , probably dead though [23:09:38] I speak english... Bad. Jajaja. [23:11:42] you probably speak it better than i speak spanish. again, "pero" is about the hardest word i can remember ;p [23:13:30] Im installing MediaWiki, but when I upload a image, the server cant create a thumbnail, this is the message: Unable to run external programs, proc_open() is disabled. Error code 1 [23:15:06] Do you have access to php.ini ? [23:15:11] Yes. [23:15:27] Ok, in that file, look for the disabled_functions config [23:15:33] and remove proc_open from it [23:16:30] uh, make sure it doesn't affect other code [23:17:07] ask the person who added it in your `disabled_functions` setting WHY they did [23:18:17] Alphos: Its probably to prevent "hacking". adding random stuff to disabled_functions used to be a common hardening technique (albeit a not very effective one) [23:18:32] also, make sure you're editing the correct php.ini ;-) and restart your webserver (or php worker if you're using php-fpm) ; if you're on a debian-based system (which includes debian, ubuntu, linux mint), you'll have to fully stop and fully start it again for it to have any effect. [23:18:35] Its probably safe to remove it from disabled_functions [23:18:57] bawolff i know, but it's been used because some people eval'd stuff, to avoid proc_open to being eval'd [23:19:34] granted, if eval is somewhere in the code, it needs to be removed anyway, but for people who aren't php-savvy, a replacement may well be uneasy to setup [23:19:45] Is a VPS, this configurations are the standar [23:20:06] (and no, fpc(); include; is NOT a valid replacement, security-wise :p ) [23:20:43] dannyLopez all right then, if mediawiki is the only thing on your vps, go on :-) [23:20:46] Security wise, if randoms can execute code, you're already screwed. disabling proc_open isn't going to help [23:21:12] depends on random ; but yeah, generally speaking, eval() is bad news ;) [23:21:25] Dont find disabled_functions [23:21:30] [01:21:18] If eval() is the answer, you're almost certainly asking the wrong question. -- Rasmus Lerdorf, Creator of PHP [23:22:04] OTOH, If Rasmus Lerdorf is answering, you're almost certainly asking the wrong person. [23:22:07] dannyLopez you may find it in your apache or nginx configuration, depending on what php SAPI you're using. do you know if you're using mod_php or php-fpm ? [23:22:13] dannyLopez: Sorry, disable_functions [23:22:15] ori XD [23:22:15] I made a typo [23:22:21] no d at the end of disable [23:27:26] http://pastebin.com/rVKbiMe6 [23:28:48] dannyLopez: That's probably not the right php.ini file [23:29:16] usually its somewhere like /etc/php.ini or /etc/php5/php.ini [23:30:19] or /etc/php5/apache2/php.ini [23:30:59] dannyLopez it's doubtful php.ini would be in public_html/ [23:31:30] try seeing the output of a phpinfo() [23:31:39] where it locates the used php.ini [23:31:44] dannyLopez write a file with nothing else than (write it on your server, of course) [23:32:07] Ok. [23:32:56] And put in what folder? [23:33:12] Sorry, Im newbie in Centos. Jajaja [23:35:47] dannyLopez : your web root ? i'm guessing it's /home/regalale/public_html/ in your case [23:36:12] browse to it, and look at your "Server API" line, which should be in the first table [23:37:06] http://pastebin.com/YJNqcVDC [23:37:57] No, this is not my web root, The root of wiki is /home3/fundac21/public_html/wiki [23:37:59] stop using the command line for now (except for editing that phpinfo file i'm talking about, if you use a command line editor) [23:38:30] i really don't need all that `find` output, which tells me nothing about which file to edit ;) [23:38:55] just write (an empty file, with just that in it) [23:41:45] dannyLopez: Alternatively, try setting $wgUseImageMagick = false at the bottom of LocalSettings.php (It will make MW try to use internal functions instead of image magick to resize images) [23:41:54] Some like this? http://fundacioninnovagen.org/prueba.php [23:42:31] dannyLopez perfect ! so you'll want to edit /usr/local/lib/php.ini [23:43:05] find disable_functions in there (nano /usr/local/lib/php.ini ; Ctrl-W > disable_function) [23:44:50] I coment like this disable_functions = symlink, show_source, system, shell_exec, passthru, exec, popen, allow_url_fopen #, proc_open [23:45:02] oh wow, they really went all the way, didn't they ? [23:45:22] also, why on earth would they put allow_url_fopen in disable_functions ?! that one has no effect >_< [23:45:50] i'd mostly go with just commenting the whole line, and adding disable_functions = [23:45:56] (nothing after the = ) [23:46:26] lol [23:46:31] (also, as a rule, don't disallow allow_url_fopen, ffs ! ) [23:46:37] Sarcasm? [23:46:43] dannyLopez really not [23:46:54] Oh, jajaja [23:47:09] You say coment all line after = ? [23:47:13] no [23:47:16] comment the whole line [23:47:30] and add a line with nothing else than "disable_functions =" [23:47:39] Ok [23:48:19] Rebot the httpd or something like that. [23:48:22] what's amazing is that they forgot to disable eval()¸ but tried disabling allow_url_fopen, which is not possible to disable in disable_functions [23:48:23] ? [23:48:40] After changes [23:50:00] Oooh Alphos ypu are a genius [23:50:02] :) [23:50:06] You* [23:51:06] dannyLopez : have you stopped and started apache ? [23:51:16] i don't mean restart, i mean full stop, full start [23:51:25] if not, you'd better :) [23:52:25] (i never remember if centos needs a full stop, but i'd rather be safe than sorry ; and you need that configuration change to be registered with apache) [23:52:37] No Alphos, I dont stop apache, but this is the result: http://i.imgur.com/6ABACSA.png [23:52:55] dannyLopez : still, you should stop and start it [23:53:05] Ill do [23:53:15] But, this is my lunch time [23:53:23] so apachectl stop ; apachectl start [23:53:27] See you. Muchas Gracias. [23:53:32] it's really as simple as that, should take 10 seconds [23:53:36] Alphos: maybe they needed eval for something they used? [23:53:38] Ok [23:53:51] Platonides : maybe they needed to go die in a fiery pit ? :D [23:55:06] Done Alphos. Hola Platonides :) [23:55:52] Platonides : srsly, disable_functions = allow_url_fopen # WHY ?! http://cdn.quotesgram.com/small/58/75/2033786295-whywouldyoudothat.jpg http://i.imgur.com/IH4fZyx.gif?1 https://www.youtube.com/watch?v=PEZWYXPvmS8