[11:08:07] Can anyone help? I have been editing my Wikipedia theme but now it won't let me. I am trying to edit minervaneue.css but when I click edit it doesn't do anything. [15:05:02] hello, has anyone had experience using luasandbox under php5? im getting random segfaults that i can't figure out how to fix [15:18:22] o/ [15:19:21] I added 'svg' to the array of file extensions permitted to be uploaded, and that all works. I uploaded an SVG, but mediawiki is trying to convert it into JPEG/PNG [15:19:34] can I disable this behaviour and just have the SVG be embedded as-is? [15:19:49] can't find anything on the wiki about it [15:26:16] Browsers are not always good at svg, so MediaWiki makes a fallback image by default. [15:26:28] You can still view svg though. [15:27:08] Not much docs on it, but see: https://www.mediawiki.org/wiki/Manual:Image_administration#SVG [15:32:55] Hi everyone. I just upgraded a copy of mediawiki to REL1_29. I have several extensions installed and they're all using REL1_29. I just got visual editor to work but now I noticed the source editor doesn't work. [15:33:07] mediawiki debug logs indicate nothing, browser console shows "Use of "toolbar" is deprecated." [15:33:46] (more correctly, 9 instances of 'toolbar' being deprecated, no idea where they're all coming from) [15:35:07] G_SabinoMullane: this is a private wiki for my computer science notes, the only browsers I use have full support for SVG [15:35:19] I'm more concerned about embedding them in wiki pages [15:36:12] PuppyKun hi, is that jquery.ui? [15:36:28] possibly it is caused by wikieditor which uses jquery.ui [15:38:10] paladox: how would i know if it's jquery.ui ? [15:38:22] i just realized.. is there like no longer a non-extension source editor? [15:38:49] Um,it should say [15:38:50] This page is using the deprecated ResourceLoader module "jquery.ui.position". [15:38:56] This page is using the deprecated ResourceLoader module "jquery.ui.widget". [15:38:57] I forgot to wfLoadExtension( 'WikiEditor' ); and when i tried to edit pages with source nothing happened besides it addint the editnotice (interface message) to the top of the page [15:39:08] oh [15:39:15] after adding the extension I can actually see an editing window but I still see the console warnings [15:39:34] whcih extensions do you have installed? [15:40:05] I don't see the reference to resourceloader modules [15:40:06] 1 sec [15:41:23] BetaFeatures, CirrusSearch, Cite, CiteThisPage, CommonsMetadata, ConfirmEdit, Elastica, Gadgets, ImageMap, InputBox, Interwiki, LocalisationUpdate, MultimediaViewer, Nuke, PageImages, ParserFunctions, PdfHandler, Poem, Popups, Renameuser, Scribunto, SpamBlacklist, SyntaxHighlight_GeSHi, TemplateData, TextExtracts, UserMerge, VisualEditor, WikiEditor [15:41:58] (cirrussearch rocks btw. Only reason i upgraded to rel1_29 was because cirrussearch rel1_28 required an earlier version of elasticsearch that I wasn't sure how to downgrade to) [15:42:22] thanks [15:42:23] hmm [15:45:43] Is it possible to create a "noob" user group that allows read access to all pages, and write access in user:talk pages, but nothing else (or allows write access to all user space, but can't edit any articles/files)? [15:46:24] sounds like a job for abuse filter + a friendly notice. [15:47:05] there's namespace protection i think so you could just protect ever namespace except the ones you want noobs to be able to edit.. except I think you'd have to have a non-noob group with the edit permission :/ [15:47:44] Banaticus: yeah, but rather than a "noob" group that removes the access, you'll need to remove it from everyone and have a "non-noob" group that grants it [15:48:05] https://www.mediawiki.org/wiki/Manual:$wgNamespaceProtection [15:48:49] !permissions [15:48:49] For information on customizing user access, see < http://www.mediawiki.org/wiki/Help:User_rights >. For common examples of restricting access using both rights and extensions, see < http://www.mediawiki.org/wiki/Manual:Preventing_access >. [15:48:59] Like I said though if [[Extension:AbuseFilter]] is an option you could create a filter that checks for account age, namespace, etc. [15:49:03] o; nifty shortcut [15:51:46] mikius: You should still be able to (view / insert in wiki text) your svg upload [15:52:45] I looked at Help:User_rights, but didn't see anything about blocking edit access over most of the wiki, but allowing edit access in userspace. And I believe the page mentions that it's not really possible to block edit access from one particular namespace. I'll look into the abusefilter extension. [15:55:24] Banaticus: you can definitely block access to a particular namespace with https://www.mediawiki.org/wiki/Manual:$wgNamespaceProtection . restricting *read* access is mostly impossibly though [15:55:30] block edit access* [15:56:05] abusefilter can probably be used to do the same though. use whichever you find easier to configure [15:58:49] G_SabinoMullane: I fixed it by installing NativeSvgHandler [15:58:53] works like a charm [16:02:56] https://www.mediawiki.org/wiki/Manual:$wgNamespaceProtection looks great, $wgGroupPermissions['managers']['official-edit'] = true; then granting employees official-talk-edit permission, etc. [16:03:54] mikius: what about NativeSvgHandler? Doesn't Chrome already do that? [16:05:22] Banaticus: mediawiki was trying to use ImageMagick (or something) to convert SVG files to PNG, I had to install the NativeSvgHandler extension to bypass this behaviour [16:05:58] so my SVGs are now being embedded in wiki pages *as* SVGs, rather than PNG [16:06:13] [which is what I wanted] [16:07:01] I think SVG's are displayed as PNG's for ease of rendering and page caching? Are your pages still being cached? [16:07:22] Unless you click into the image to view the file and pull up the actual svg. [16:07:37] they are, they're displayed as non-vectors for browser compatibility purposes [16:08:00] I don't have an issue anymore, my issue was that I wanted mediawiki to embed the SVG as-is rather than a PNG conversion of it [16:08:06] it's working fine :) [16:25:28] Hi, can anyone tell me what extension Wikipedia use that allows to quickly add categories to pages? [16:26:59] freenoodle: None (when it comes to the term 'extension'. :) But maybe you mean the HotCat.js gadget on some Wikipedias? [16:29:34] andre__, Yes, you are right, that's what I was looking for [16:35:17] andre__, I guess to get the "gadgets" into the preferences menu, one needs to install the gadgets extension https://www.mediawiki.org/wiki/Extension:Gadgets right? [16:36:49] paladox: I just got back from lunch. Didn't change anything and s:Version still shows wikieditor enabled but now I can't edit source at all again... Do you have any ideas? [16:37:22] Hmm, any errors in the logs? [16:37:34] https://www.mediawiki.org/wiki/Manual:How_to_debug [16:39:58] freenoodle, yes I think so [16:40:21] PuppyKun which wiki is this? [16:53:01] paladox: It's a private wiki I have set up at work [16:53:32] ah ok [16:53:54] would mediawiki 1.30 work? [16:54:30] oh that is not released yet [16:54:46] wikieditor dosen't work? [16:55:24] did you set this [16:55:25] wfLoadExtension( 'WikiEditor' ); [16:55:26] # Enables use of WikiEditor by default but still allow users to disable it in preferences [16:55:26] $wgDefaultUserOptions['usebetatoolbar'] = 1; [16:55:26] $wgDefaultUserOptions['usebetatoolbar-cgd'] = 1; [16:55:30] PuppyKun ^^ [16:55:53] PuppyKun: I'm an idiot [16:55:56] paladox: * [16:56:05] lol :) [16:56:11] I very recently changed my editing preferences [16:56:32] and I just realized the editing window moved to the bottom of the "preview" so the "edit not doing anything" was "show the edit box under the preview" [16:56:39] oh [16:56:45] I think it was two-fold. [16:57:04] I'm fairly confident that it wasn't working before I remembered to enable WikiEditor. Then i enabled it and it was working, then I changed my prefs lol [16:57:16] paladox: any chance you can help me with completely unrelated img_auth.php stuff? :) [16:57:41] I could try, though i doint think i've ever used img_auth.php [16:58:05] https://www.mediawiki.org/wiki/Manual:Image_Authorization#Apache_-_Compatibilize_with_clean_URLs [16:58:29] tried that yet all my urls on wiki are still things like "GET http://192.168.4.80/wiki/img_auth.php/thumb/1/10/" [17:00:53] http://192.168.4.80/img_auth.php/0/07/Undersized-OD_Kamax-5.108088.0.png works so I know the script works I just have to figure out what to make $wgUploadPath / $wgUploadDirectory and rewrite rules.. trying to read over the instructions again :) [17:02:03] $wgUploadPath / $wgUploadDirectory are where you want to store images [17:02:05] ie [17:02:26] well one of them has to point to img_auth.php unless im 100% mistaken [17:02:33] images/ [17:03:07] nope [17:03:19] as img_auth uses those configs [17:03:19] https://github.com/wikimedia/mediawiki/blob/5300df4838f68437c17d5d697de57a46f0b5e02c/img_auth.php#L46 [17:03:41] wgUploadPath defaults to images/ [17:07:27] paladox: weird.. guess it's b/c trailing slash or something .. ? [17:07:50] I set wgUploadPath to "images" and nothing loaded because my redirect was trying to load /wiki/images instead of /images/ [17:07:57] s/redirect/rewrite [17:07:59] maybe. though by images/ i mean /images without / [17:08:03] hmm [17:08:08] $wgUploadPath = "$wgScriptPath/images"; [17:08:18] I commented out $uploadpath [17:08:20] so whatever the default is [17:08:23] has the correct path [17:08:24] oh i see [17:08:30] /wiki/ [17:08:35] now I see GET http://192.168.4.80/images/thumb/b/b9/LRZB250CpPinOut.JPG/180px-LRZB250CpPinOut.JPG 403 [17:08:42] my htaccess rewrites are [17:09:05] https://phabricator.wikimedia.org/P6139 [17:10:56] paladox: huh [17:11:39] redirects the url so it uses $wgArticlePath = "/wiki/$1"; [17:11:46] Apparently copy/pasting thos completely as-is leaves my /wiki/ working and img_auth.php (when maually typed) [17:11:47] works [17:11:54] i.e. http://192.168.4.80/img_auth.php/0/07/Undersized-OD_Kamax-5.108088.0.png displays an image [17:11:59] :) [17:12:08] but when I go to Special:AllFiles I just get a bunch of 403 errors in the console [17:12:13] oh [17:12:49] all the file pages point to /images/thumbs instead of /img_auth.php/thumbs/ [17:13:47] https://phabricator.wikimedia.org/P6140 [17:14:04] PuppyKun that's partially my settings except from i left out the extensions [17:20:00] paladox: really hate to say this [17:20:07] ok [17:20:13] but I set $wgUploadPath to "$wgScriptPath/img_auth.php"; [17:20:19] and things suddenly seem to work exactly as I expect. [17:20:27] lol [17:20:31] on-wiki media links to img_auth.php/path/to/image and works [17:20:36] i log out and i cant see them [17:20:38] :) [17:20:49] thank you for helping troubleshoot it :) still using your rewrite rules [17:20:56] your welcome :) [17:56:43] Hi, can someone tell me what I need to do to get a list of all categories on a page? I have found the "Allcategories" entry in the description of the mediawiki api https://www.mediawiki.org/wiki/API:Lists/All#Allcategories but that seems to be about writing extensions, isn't it?Is there some wikicode which generates a list of cats? [17:58:30] freenoodle: can you please elaborate on what you are trying to do? [17:58:47] (as in, for what purpose do you need this list -- what are you trying to do with it) [17:59:33] Skizzerz, a small wiki, where the start page should immediately show what categories are already there [18:00:06] Skizzerz, or is there a macro that generates a category tree on the fly? [18:00:10] freenoodle: try putting {{Special:Categories}} in the page's wikitext [18:00:12] see if that does what you want [18:00:52] that will show all categories that are used on pages, including categories that don't exist yet [18:01:44] Skizzerz, no it doesn't. It generates a link to [[Special:Categories]] [18:02:39] ah, dnag [18:02:41] *dang [18:04:31] freenoodle: {{Special:AllPages|namespace=14|hideredirects=1}} might work for your needs then; it will show all existing pages in the Category namespace [18:04:37] (which are not redirects) [18:05:13] otherwise, you can look into extensions like https://www.mediawiki.org/wiki/Extension:CategoryTree [18:10:02] Yeah, I've been annoyed in the past, trying to track down all categories that a page might exist under, when some categories are added by templates. Easiest way is just to scroll to the bottom of the page (not in edit mode) and see which categories are listed. [18:10:31] Figuring out which templates might be adding those categories is a different beast, but the page should list all of its categories [18:16:19] Skizzerz, thanks! That does what I want [19:53:09] Hey guys, what are the first things you do when you install a new mediawiki somewhere? [19:53:25] In order to keep things organised, and well-oiled from the beginning [19:54:26] anti-spam stuff [19:54:41] this one is only accessible within the comapny network [19:56:01] did you subscribe to mediawiki-announce to get notifications about new releases / security updates? [19:57:07] Skizzerz, not yet, not a fan of newsletters, how is the list? [19:57:28] it's at https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce [19:57:47] about as low-traffic as you can get, just announcements about releases or security updates [19:57:49] no other chatter [19:58:49] ok good to know Skizzerz, cheers [20:01:29] flying_sausages: beyond that, basic stuff your org does for any other webapps you host -- documentation, regular backups, etc. [20:03:49] > documentation, regular backups, etc. [20:03:50] ha [20:03:56] that's a good one :p [20:53:15] flying_sausages: There are a lot of extensions you could look into for making your work easier. Standard templates/gadgets etc you call pull in from enwiki too. [22:22:09] Who here knows about MediaWiki’s Docker package? [22:22:49] My question is, what is the advantage of having a bunch of Docker containers over more traditional ways of setting up multiple wikis on the same server? [22:30:53] containers provide isolation, and all of the upsides and downsides that isolation brings [22:31:07] harej: ask davidwbarratt, or the folks at #wikimedia-services [22:31:58] for example, if you have a very high traffic wiki behind a load balancer, you can make use of containers to easily spin up or tear down new instances of the webserver to handle increased/reduced load on the fly, so that you aren't wasting resources by running everything for peak capacity 24/7 [22:32:34] containers also allow for easy snapshotting to make full-system backups before upgrades or as a DR strategy [22:33:27] and should there be a vulnerability in the webserver, only the container gets compromised and therefore only things specific to that wiki, rather than handing over data from unrelated things (such as other wikis) also on the webserver, assuming they're all under the same user otherwise [22:34:30] on the downside, it's more overhead to manage containers, and it's possible to have too much complexity if all you have is a small low-traffic wiki [22:45:14] harej: addsh.ore too. [22:47:52] Skizzerz: so might it make sense then to have one container for all the small wikis and then other containers for bigger wikis? Or does that not really make sense if I don’t know ahead of time what the big wikis are and spinning off a wiki into an isolated container is too much work? [22:48:09] addshore, you might have a good answer to my question above [22:51:20] hard to answer without knowing what you are trying to do [22:51:55] but in any case AFAIK mediawiki-docker is still experimental [23:00:34] harej: im my mind the simplest way (hah) would always be have the multi container approach. that would be the "correct" way [23:00:45] but without knowing more I cant say more! [23:04:35] addshore: the context is a wiki farm kind of thing where people fill out a form and it creates a wiki for them. I am thinking that having each wiki in a container would make administration easier, and in particular, easier to automate. [23:06:56] each wiki in a container is probably the wrong way to go in terms of scaling things. [23:07:06] harej: at wikidatacon? perhaps we should talk about this! [23:11:19] I won’t be at Wikidata Con :( [23:17:10] silly harej [23:17:19] Look, I can only afford so many trips to Europe a year!