[00:03:17] Hi tofu. Bye tofu. [06:30:02] hello all [06:30:16] need a help on forming api with proofread [06:31:44] https://phabricator.wikimedia.org/T133781#2245021 [06:31:48] details are here [13:19:47] morning [13:21:38] o/ [13:24:23] howdy Niharika [13:29:47] I'm good, Auger. How're you doing? [13:34:10] i'm doing pretty good, just sipping the morning coffee, settling in for the mundane :D [13:40:27] The most awesome of bugs have a tendency to turn up on the most mundane of days! :) [13:41:16] hehe [15:31:37] Hi all, I'm having a funky CSS issue. I have a modified skin installed, and some of the image background assignments made in Mediawiki:Common.css aren't working correctly on precisely one special page. It's utilizing an incorrect image that's defined in the actual skin files and gets trumped everywhere else by the rule set in Mediawiki:Common.css [15:31:48] How do I make Special:UserLogin&returnto=Home&returntoquery= listen to reason!? [15:38:26] Ulfr: site and user CSS is disabled on login/signup etc. pages by default, there's a config option somewhere [15:38:38] !wg AllowSiteCSSOnRestrictedPages [15:38:38] https://www.mediawiki.org/wiki/Manual:%24wgAllowSiteCSSOnRestrictedPages [15:40:33] MatmaRex: <3 [15:47:50] MatmaRex: Before I propagate this to a production site, is there any reason in particular why that's a bad idea to enable? [15:48:21] Security [15:48:29] Huh? [15:48:29] Ulfr: if you have site administrators who are not quite trusted or morons, they could break the login page for everyone. https://phabricator.wikimedia.org/T72672 [15:48:51] Oh [15:49:15] Meh. All the people who have admin permissions sit within easy reach for a back of the head slap. [15:49:39] lol [15:51:39] And unfortunately it's that or leave unique CSS directories for file structures that shortly won't be directly editable. I'll take the risk someone accidentallies everything [15:52:21] So I know which one I'll pick. Thanks for the assist. Never would've found that in a million years :( [15:57:11] Ulfr: I wrote that extension for that issue that prevents saving JS expressions in CSS in the first place. https://github.com/HydraWiki/Bug70672 [15:58:01] Trela: Oh, excellent. Thanks very much! [15:59:33] So if you disable the security that will prevent people from potentially putting in an exploit. [16:06:42] Trela: It would be more through ignorance than stupidity. Though in my honest opinion that extension needs a badass nickname, bug70762 is just so.. [16:07:31] SEO is intended for people searching for "bug 70672 work around". [16:08:24] Naturally, and I'm strictly speaking from a form rather than function viewpoint, but the LiamNeeson extension would just have that pizzaz [16:08:28] prevents your browser from getting taken [16:10:26] I'm sorry, I'll shut up now. Thanks for the bugfix :) [16:24:05] we have {{CURRENTYEAR}}, but is there one for "nextyear" ? (I assume not, as not in docs, but hope springs eternal. :) [16:24:39] quiddity: {{#expr:{{CURRENTYEAR}}+1}} [16:24:52] aha, deep magic! ty :) [16:25:05] Yeah, he's a wizard [16:25:34] quiddity: don't try this for {{CURRENTDAY}} though, unless you think february 1 is actually january 32. ;) [16:26:05] (you can do more advanced time calculations with {{#time:}}) [16:26:09] Trela: Sorry to bother you again so soon, but this is with a legitimate question. On one wiki the bugfix ran fine. On another it's making the site error out because of a [ on line 16 of Bug70672.php, which is the start of your credits array. How'd I make your extension mad? [16:26:48] Ulfr: Is that server running PHP 5.3? PHP 5.4 is the lowest supported. [16:26:56] Trela: Well played. [16:27:27] 5.4? [16:27:43] 5.3 < 1.27, 5.5 >= 1.27 [16:28:27] Ulfr: 5.3 and 5.4 are end of lifed by PHP no longer receive security updates. http://php.net/supported-versions.php [16:29:09] *and no longer [16:30:07] Trela: depends(tm), some distros will backport security patches to older php versions as long as that distro version is supported [16:30:18] LTS ftw! [16:30:24] that said, if you want to run modern mediawiki, you're gonna need php 5.5 [16:30:33] 1.27 drops support for older php [16:30:38] <-- runs modern mediawiki on 5.3 till just now [16:30:38] That is true, but I would never recommend people run older versions without personally knowledge of what gets back ported. [16:30:48] *personal [16:31:02] It's less that I want to run older versions and more I have to deal with reams of paperwork to change software versions [16:31:05] and I don't hate trees [16:31:50] Ulfr: Do what I do. "Here is a scary page that says they stopped releasing security updates for this old version." Then everyone scrambles. [16:32:09] fsvo everyone [16:32:29] See, that's the trick. Everyone gets scared, and then I *still* have to fill out paperwork regarding why I have to do my job [16:32:45] $wgVersion = 'oldVersionHere'; [16:32:50] RESOLVED WORKSFORME [16:32:56] I'm thinking of the trees, really. I promise it's not that I just don't want to fill it all out [16:33:10] Reedy: Does that variable assignment fix everything? [16:33:22] Well, the version didn't change, did it? [16:33:25] * Reedy coughs [16:33:39] I don't know, usually I wait for corroboration before I implement Reedy advice [16:33:52] It's not that I don't trust you, I just wouldn't put it past you to pull my leg a lil bit [16:34:12] It wouldn't cause any problems with MW core [16:34:17] It might screw around with extensions somewhat [16:34:26] If they have version comparison [16:34:29] in core, wgVersion is only used for display purposes [16:34:29] I do believe he is joking. :O [16:34:34] See?\ [16:34:47] This is why I usually wait for someone else to agree before I copy/pasta something with Reedy: before it [16:35:19] in any case, you have about a year to migrate to more modern php before there won't be any supported mediawiki versions for your platform [16:35:40] Skizzerz: and I will wait until that day to update, because boy do I love trees and hate paperwork [16:35:50] then you're in for a world of hurt [16:35:57] Trela: I don't want to alarm you but I have mysql servers running Ubuntu 10.04 [16:35:58] I recommend instead doing your job [16:36:06] Booo. Responsibility? Eww. [16:36:28] 10.04 is only a year out of support [16:36:33] * Reedy coughs [16:36:44] also if you're using php on ubuntu LTS, I don't believe they backport security patches for stuff in their repos... or if they do, not everything [16:36:54] my comment on backports was more for the rhel side of things [16:36:57] Ulfr: The only benefit we saw from upgrading Ubuntu from 10 -> 12 -> 14 was very small increases in networked disk performance. However, 10.04 is rather out of date. [16:37:13] By "we" I mean at not-WMF. [16:38:14] the AWS service I use to execute launch scripts for my boxes still hasn't added templates for 14.04, and the only difference I noticed between 10.04 and 12.04 was that I no longer was root by default [16:38:15] :( [16:38:35] o_o Root by default. [16:38:57] If I'm the only user it's a non-issue [16:39:15] ah, if it's in the main repo canonical will backport security patches for the lifetime of the os [16:40:10] Ulfr: A whole room of security people are cringing right now. [16:41:31] I know, it's fun [16:43:06] I'm also not completely negligent, the only servers that I run as root by default on aren't accessible from anywhere other than behind a vpn [16:43:36] and I run my vulnerability scans frequently enough to keep people happy and resolve them as they arise :P [16:44:11] Facebook recently messed that up recently and had an insecure version of a product that allowed getting around the VPN and into their network. :P [16:44:26] Myself and English are not getting along today. [16:51:04] Grumble. Now my test environment machine won't run because my config is broken because I thought why not upgrade, skizzerz made me feel negligent [16:51:37] :P [16:52:40] :) [16:55:35] Trela: If you want to make a whole room of jQuery developers cringe, including this one, show them code that has an array defined like this: var Array = new Array(); [16:56:41] Ulfr: I could make them cringe just by showing them my Javascript. [16:58:34] Nono, the point of that staement is that it runs, it javascript doesn't care, but it's treating an array like something it's not [16:58:34] :D [17:05:37] Hi, I would like to disallow non registered users to read Special: namespace, I have installed https://www.mediawiki.org/wiki/Extension:Lockdown extension but I do not know how to set that to anonymous group [17:15:26] !lockdown [17:15:26] Lockdown is an extension for preventing read or write access by namespace and limiting access to special pages, see < http://mediawiki.org/wiki/Extension:Lockdown >. For per-page access protection, see !ppp. For general information on preventing access to your wiki, see !access. [17:15:37] !access [17:15:37] For information on customizing user access, see . For common examples of restricting access using both rights and extensions, see . [17:16:27] yes Krenair, but how do I mean anonymous? [17:17:31] there is no group that means anonymous users (non registered and loged in users) [17:19:32] the only one is "*", but it also includes users, sysops, etc [17:23:29] no [17:24:34] so how do I disallow for anonymous users but allow to users and sysops? [17:26:03] you disallow access to '*' and allow access to 'user' [17:26:43] by looking at the extension docks, the way to do that is e.g. $wgSpecialPageLockdown['Export'] = array('user'); [17:27:14] that will allow all logged-in users access to Special:Export, and implicitly means anonymous users do not have access [17:27:22] replace Export with whatever other special page [17:27:27] and how to disallow all namespace? [17:27:36] I do not understand your question [17:27:49] are you saying you do not wish for logged-out users to be able to view your wiki at all? [17:28:03] I would like to hide Special page to non registered users [17:28:44] I would like to allow the wiki, but no special namespace [17:28:54] special pages I mean [17:29:43] I put $wgNamespacePermissionLockdown[-1]['read'] = array('*'); but seems not working [17:30:12] because you want array('user') [17:30:21] the value is the list of people ALLOWED access [17:30:24] but user means registered user [17:30:35] all logged-in users are in the 'user' group [17:30:43] no logged-out users are in the 'user' group [17:31:30] but Special:SpecialPages can be viewed by logged-out users [17:31:48] because you used '*' and not 'user' [17:31:54] by using '*' you said "everyone can do this" [17:32:03] again, the list is a list of people allowed access [17:32:13] if they belong to a group in that list, they can do the thing [17:32:26] so your list needs to NOT have the groups you do not wish to have access to it [17:33:05] so setting this: $wgNamespacePermissionLockdown[-1]['read'] = array('user'); [17:33:21] try it [17:33:54] I am doing that, and logged-out users still can acces to Special Pages [17:36:07] hi is there a way I can disable the API [17:36:19] I think a lot of the spam comes trhough it, and is really not something I need for this wiki. [17:36:30] hinojosa: then you'll probably need to use the SpecialPageLockdown and copy/paste it once per special page [17:36:53] ok, I am going to try it [17:37:35] bluesilver: https://www.mediawiki.org/wiki/Manual:Configuration_settings#API [17:37:49] notably, $wgEnableAPI and $wgEnableWriteAPI [17:38:07] that said, spambots are more than capable of using the regular edit interface to post spam, so that isn't going to really deter them [17:38:19] I recommend looking into anti-spam extensions instead (or in addition to that) [17:38:55] ConfirmEdit springs to mind, it's used to add captchas to pages if they add links etc. [17:39:18] you can also make use of AbuseFilter filters to outright block the addition of links by certain classes of users [17:42:45] see https://www.mediawiki.org/wiki/Manual:Combating_spam for more information and options [18:14:27] Skizzerz, disabling Talk namespace works [18:14:36] so it could be considered as a bug, is not it? [18:15:04] ? [18:15:11] the special namespace is special, as the name implies [18:15:29] I did not expect disabling normal permissions would work on it, because those normal permissions are likely not checked [18:15:43] yes, but because is special, it should not be readable by logged-out users, is not it? [18:15:59] why not? [18:16:17] it's special because the pages there have special functions and are not normal wiki pages [18:16:23] because it contains sensible information such as Version page [18:16:29] there is no security issue in revealing them [18:16:55] version numbers are not sensitive information, nor is displaying them a security vulnerability [18:17:26] that is called "security by obscurity" and doesn't work [18:17:43] if you keep everything patched (as you should), there is no issue telling the world that you keep everything patched [18:17:52] could work or not, but it is security [18:18:02] it really isn't [18:18:50] additionally, hiding Special:Version does not hide the version number [18:18:55] it is revealed in a myriad of other places [18:19:01] and to hide the sysop user is not security for you, right? [18:19:25] no, choosing a strong password for the sysop user, however, is [18:19:38] again, security by obscurity is not security [18:19:55] if you want to be super paranoid and apply it on top of normal security practices, go for it [18:20:05] but it should not be your only layer of defense [18:20:18] (and mediawiki is a horrible platform if you want to truly obscure some things but not other things) [18:22:07] an example of the version thing, I can run mw.config.get('wgVersion') in my browser's js console to get the version number, and the html generated by mediawiki includes the version number in a tag [18:22:35] the mediawiki version, but not apache version [18:22:39] or mysql version [18:22:40] for your sysop user, I can view the page histories or list of authors of a page to get the list of users that edited that page, and that is NOT a special page so restricting the special namespace doesn't block that [18:22:55] your apache version is likely revealed by a response header unless you turned that off too [18:23:09] yes, we do [18:23:10] and even then I can probe your webserver's features to figure out what version you're running [18:23:15] and what about mysql version? [18:23:20] irrelevant [18:23:32] unless your mysql server is exposed to the outside world (why?) [18:24:19] does not matter the reason [18:24:28] yes? [18:24:34] it is information that should be hide [18:25:02] you should firewall off your mysql server box so only the webserver can talk to it, and in mysql itself ensure that the only remote users that can log in are from the webserver [18:25:25] ok [18:25:27] do that, and exposing the version number won't really matter; you can if you want but you're secure either way [18:25:40] so four you, if this line $wgNamespacePermissionLockdown[-1]['read'] = array('user'); does not work [18:25:55] it is not a bug [18:26:07] it is just "there is no problem" [18:26:10] right? [18:26:17] no, because mediawiki's special namespace doesn't work that way, and is why Lockdown offers a different config variable for locking down special pages [18:26:38] you can make use of that variable instead, or write your own extension to lock down all of them at once [18:26:55] I just question the usefulness of doing so, because security by obscurity doesn't work [18:30:32] makes no sense to say it is not a bug because "mediawiki's special namespace does not work that way" [18:31:22] I would agree you if it is documented that there is no possible to refer to special namespace (-1) [18:31:27] but it is not [18:31:42] so for me, it is a clear bug [18:31:45] each special page is responsible for implementing its own permissions, regular permissions like read, edit, etc. simply aren't checked for it [18:31:52] er [18:31:54] read is checked [18:32:30] I was hoping you all could point me in the right direction.. [18:32:45] I was upgrading from 5.5 to 5.6 PHP [18:32:57] and now Apache2.4 will not start [18:33:08] check the error log? [18:34:38] Yes...sec [18:35:05] Cannot load C:/php/php5apache2.4_.dll into server [18:35:49] You forgot to charge your flux capacitor [18:36:42] _ at the end? [18:37:05] php5apache2_4.dll is more likely [18:38:26] @Reedy...more likely corrupt? [18:38:35] No, a more likely filename [18:39:27] Its there and showing the new date, so it was replaced [18:41:56] From a fresh download of 5.6.21 for windows... [18:41:58] IT is php5apache2_4.dll [18:42:03] Not what you put [18:42:44] yes a fresh download, backed it stopped the service..etc [18:43:00] [19:35:06] Cannot load C:/php/php5apache2.4_.dll into server [18:43:04] confirmed (pnp5apache2_4.dll) [18:43:06] Was that a typo yourself? [18:43:37] aaahh..I see what your looking at [18:43:38] sec.. [18:43:43] checking the log [18:44:27] typo [18:44:59] in what? your config? what you wrote here? [18:46:43] it was a typo what I did, its not in the logs that way or on the system that way [19:06:53] I want to tell "If you are leaving this page not wishing to continue reading this site, is it because: 1. you don't have time to volunteer. 2. you disagree with site's philosophy. 3. you consider yourself too stupid or too uneducated". Which MediaWiki extension you recommend to gather such information from users? [19:08:58] you'd have to make your own [19:09:17] bawolff: I am now considering https://www.mediawiki.org/wiki/Extension:AJAXPoll [19:09:46] at least, no extensions I know of trigger survey immediately when user tries to leave the site [19:10:15] bawolff: no, the survey should be shown at some "entry" (landing) pages of the site [19:10:54] oh, well you could try ajaxpoll. Not a whole lot of really good extensions for that sort of thing [19:11:36] Skizzerz, despite of the discussion, thanks for your help [19:11:48] :) [19:11:54] bye [19:12:25] Thx Reedy...kinda stuck downloading Xampp and see if I can find anything [21:53:25] Hey. I just installed mediawiki in a subdir (public_html/wiki). From before I have wordpress in the root (public_html/). When I go to domain.com/wiki it just shows the Wordpress 404. If I'd just put a simple index.html in public_html/wiki I'd see it (I've tried). Anyone know how this can happen? [21:54:15] I've done nothing to change the mediawiki install myself. Just installed it with cpanel, which also created a database for it. [22:11:30] sjokkis: wordpress alias are taking priority over mediawiki [22:11:42] moreover, you probably want articles at domain.com/wiki/article [22:11:50] not domain.com/wiki/index.php/article [22:11:58] so you should have installed mediawiki osmewhere else [22:12:01] *somewhere [22:12:05] such as domain.com/w/ [22:14:04] Platonides: So, to tackle one thing at the time, do you know how I'd fix those redirects? [22:15:08] you'd put something at the beginning of the wordpress .htaccess [22:16:21] Platonides: There are other services installed to subdomains, like web email, that don't have this problem, installed by my predecessor. But I don't see anything in the wordpress .htaccess referring to those [22:16:38] Platonides: And I haven't found anything in cpanel that seems like it's related, either [22:16:54] each domain will have its own configuration, I guess [22:24:00] Platonides: And about the install location. Do you mean I should simply install it to a different folder? I didn't get the part about domain.com/wiki/index.php/article. Are you saying I shouldn't have put mediawiki in public_html/wiki considering wordpress is in public_html/ (or strictly speaking, the wordpress index.php is in public_html/ while the rest is in public_html/wp) [22:24:18] that's different [22:24:27] you'd have the same problem if there was no wordpress [22:24:28] i mean [22:24:41] you want the articles of your wiki in domain.com/wiki/SomeArticle ? [22:24:48] Yes [22:25:02] then you shouldn't have installed the mediawiki files in a folder named /wiki/ :) [22:25:17] you should have chosen any other name [22:25:25] a common choice is /w/ [22:25:39] but any would do [22:25:46] Ah, I see. There'll be a naming collision? [22:27:04] yes [22:27:14] because in /wiki/ there will be the mediawiki files [22:27:21] not the articles, which are "virtual" [22:27:26] And now it works [22:27:58] Instead of selecting the subdomain wiki.domain.com during install, I just selected domain.com, specified that it should install in /w/ and now I'll just set a subdomain that redirects to /w/ [22:28:11] Right? [22:30:14] you may use a subdomain or not [22:30:20] up to you [22:30:28] although what you say seems a look odd [22:31:01] Right. Although, I'm not clear on how I'd make it appear as domain.com/wiki/article. Right now it's domain.com/w/index.php?title=lkjlkj [22:31:31] yes [22:31:37] you need a .htaccess [22:31:49] In public_html/wiki? [22:31:50] that will make /wiki/ point to /w/index.php?title=$1 [22:31:54] Right [22:31:58] usually at the root [22:32:03] !shorturl [22:32:03] To create simple URLs (such as the /wiki/PAGENAME style URLs on Wikimedia sites), follow the instructions at or try the new beta tool at . There are instructions for most different webserver setups. If you have problems getting the rewrite rules to work, see !rewriteproblem [22:42:51] Hi, I'm using CirrusSearch. sometimes on searching, the first result page shows no results. how come? for example the query has 158 results, but results 1-20 are not shown, the others are shown [22:43:16] Platonides: So, there are already some rules for Wordpress in that file. If I add the rule generated by the redwerks website above those, I'm always redirected to MediaWiki. If I put them below, I'm always redirected to Wordpress [22:43:56] https://dpaste.de/1cVp [22:46:45] auvajs: it's probably because the index is not well synced with the db, it can happen sometimes if you add/move namespaces. You can add '&cirrusDumpResult' to result page URL and tries to investigate [22:49:02] dcausse: when I run updateSearchIndexConfig.php [22:49:18] it has some error I'm uncapable to deal with [22:49:32] sjokkis: [22:49:39] just put before teh Wordpress code: [22:49:40] RewriteEngine On [22:49:40] RewriteRule ^/?wiki(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L] [22:49:45] that should do it [22:49:50] dcausse: MergeMappingException[Merge failed with failures [22:50:05] the rest of mediawiki rewrites shouldn't be needed [22:50:12] assuming your wiki is public :P [22:50:28] dcausse: http://pastebin.com/AQnEfb7W [22:50:54] dcausse: any idea? [22:51:42] Platonides: That did the trick. Thank you for your help! [22:51:55] auvajs: yes you need to do a full rebuild, let me check the command [22:53:02] :) :) [22:57:43] auvajs: should be: extensions/CirrusSearch/maintenance/updateSearchIndexConfig.php --reindexAndRemoveOk --indexIdentifier now [22:57:43] dcausse: I found it, curl -XDELETE 'localhost:9200/index_name' [22:57:58] ah ok :) [22:58:31] auvajs: with the maint script you can still serve queries while rebuilding :) [22:58:37] xdelete & updateSearchIndexConfig.php & forceSearchIndex.php [22:59:12] dcausse: ah ok :) I'll save it for later :) [22:59:56] dcausse: thanks for help :) gn [23:00:02] yw :)