[00:11:16] Hi, I was here earlier (Under a different name) - Does anybody know how to select an entry from the database and display that as an array? [00:12:19] FreeDuck: for what purpose? [00:13:06] Betacommand: To check the user's ID against another (custom) table that uses it. [00:13:31] Eg., so they can't put to entires in by accident. [00:13:32] FreeDuck: why would you want to display that to a user? [00:14:09] Not to display ti exactly, but to have an as a value I can use for checking. [00:14:12] *to [00:14:29] FreeDuck: then please say that [00:15:01] FreeDuck: do you have a user object for the current user? [00:16:19] I don't believe so, the only time the user is reference is to retrieve the ID for another purpose near the end of the file. [00:16:27] *referenced [00:17:39] FreeDuck: what are you trying to extract? [00:18:21] I'm looking to take the user's id from the 'user' table, and check if whether their ID is used in another table I created I prevent duplicates. [00:21:44] FreeDuck: https://www.mediawiki.org/wiki/Manual:Database_access [00:22:40] Betacommand - To be more precise, I'm collecting additional data from users (Date of birth), and that's stored in a separate table. To link the user to their Date of birth, I use their ID from the 'user' table. Once they enter their date of birth, I need to have it check if whether they've already made an entry with birthday so they can't come back and enter another birthday. [00:23:51] FreeDuck: is that question on its own form? [00:25:31] You mean in it's own form? The trouble I'm having is the logic behind checking if a value doesn't exist in a table - I only know how to check if there is one. [00:26:42] FreeDuck: select birthday from custom_table where user_id = 1; [00:26:53] that will either give you 0 or 1 result [00:27:14] count the results and use that [01:44:03] I'm having the hardest time understand how mediawiki handles it's funky database functions - How would I write this: https://dpaste.de/Qeju in "Mediawiki" form< [01:45:37] SheepSkin: https://www.mediawiki.org/wiki/Manual:Database_access [01:46:16] SheepSkin: https://dpaste.de/jgRq/raw I think that's right [01:46:18] Betacommand: I've combed through that, though I'm still having trouble putting 2 and 2 together (ect = ect) [01:46:53] the documentation in DatabaseBase.php is actually helpful imo. [01:47:26] SheepSkin: https://www.mediawiki.org/wiki/Manual:Database_access#Wrapper_function:_select.28.29 [01:50:33] legoktm: That sorta worked, as in functions without error but it still doesn't produce what I'd like it to. Here's my setup: https://dpaste.de/Nxub/raw [01:52:57] { $output->addHTML( $errorMessage ); <-- you're missing the closing } [03:39:38] Hey [03:40:02] I need a quick fix for an install issue that's held up a project for several days, if anyone is around to troubleshoot [04:11:27] !ask | OdinYggd [04:11:27] OdinYggd: 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. :) [04:12:16] lol [04:12:40] Okay. Installing MediaWiki 1.23.0 on Debian Wheezy, PHP 5.4.4-14+deb7u11 [04:13:03] I've got php5-mysql installed, and also tried php5-mysqlnd. It is saying that it can't find a database driver [04:13:11] Information [04:13:11] Could not find a suitable database driver! You need to install a database driver for PHP. The following database types are supported: MySQL (or compatible), PostgreSQL, Oracle, Microsoft SQL Server, SQLite. ' [04:13:50] Currently I have php5-mysql and php5-pgsql installed on this server, which is having no issues hosting a couple of forums [04:16:38] that's odd [04:16:58] check if php5-mysqli is a thing or not [04:17:27] The MyBB forums I am using are all running MySQLi, and I've got some custom code also using it [04:17:37] php5-mysqli doesn't seem to be a package [04:20:20] OdinYggd: is your website public? [04:20:31] if so, do you mind linking to a phpinfo() page? [04:20:31] wiki.rphaven.net [04:20:57] wiki.rphaven.net/phpinfo.php [04:21:15] Should be a pretty typical Debian Wheezy LAMP setup [04:21:33] I don't see mysql or pgsql enabled there [04:21:46] check your php configs [04:21:46] Hmm [04:21:52] I wondered if it might be a php.ini issue [06:15:32] I'm trying to get just a snippet of text from a wiki page using the API. What's the correct querystring params to use? [06:15:45] e.e. https://en.wikisource.org/w/api.php?action=query&format=jsonfm&prop=revisions|categories&rvlimit=1&rvprop=content|tags|contentmodel&&titles=Index:Eleanor_Elizabeth_Bourne_Papers [06:15:49] returns everything [06:59:00] Heh. http://www.editthis.info/wikimochis/ [07:57:46] hello, I'm building a map where people can add markers and write something for each marker. It shoud more or less look like this https://static.flickr.com/110/279038410_878cdd94b7.jpg I thought I could use a wiki so users can make edits and track old revisions, but I find it very difficult to integrate it with the map. Is there a simple way to do this using mediawiki (without iframes)? [09:28:58] anyone around that understands how $.fn.text works? [09:31:53] twoi: what is there to understand? [09:32:06] usually you call it as $someElement.text( 'text goes here') [09:32:40] (assuming jQuery here) [09:33:22] my confusion is why calling it to get text - $elem.text() has a couple of quirks [09:33:36] http://runescape.wikia.com/wiki/Calculator:Farming/Herbs the coins images on here, some of them are lazy loaded [09:33:44] all but the first 2 [09:34:19] if you call $.fn.text on the ones that are lazy loaded, it returns part of the img tag in the returned string [09:34:44] if it's called on either of the images that aren't lazy loaded it strip the img tag from the string [09:34:50] strips* [09:34:57] and I can't figure out why :( [09:36:31] I thought it might be something to do with the number of attributes in the tag, so I tried ramming a span tag full of bogus data- attributes, but that didn't work [11:01:45] Bonjour j'ai un souci avec la mise à jour de mediawiki 1.23.0 [17:42:20] http://en.wikipedia.org/w/api.php?action=query&prop=extracts&format=jsonfm&exsentences=1&exlimit=1&explaintext=&titles=u.S.a.&redirects= [17:42:32] ops [17:47:15] it was more on topic here actually [18:39:07] would someone be willing to help me create a quick wiki template based on the concept of timelines? [18:40:34] gwicke: the line "This article is issued from Wikipedia. The text is available under the Creative Commons Attribution/Share Alike; additional terms may apply" does not come from parsoid does it? [18:40:51] Nemo_bis: no, that's added by the skin [18:40:52] (found in Kiwix ZIM) [18:41:09] gwicke: what skin? [18:41:17] ah, in that case it's the Kiwix converter adding it [18:41:22] ok [18:41:38] So I filed my bug in the correct place. :) Thanks. [18:41:46] http://sourceforge.net/p/kiwix/other/ci/master/tree/mwoffliner/ [18:42:20] more specifically, line 43 in http://sourceforge.net/p/kiwix/other/ci/master/tree/mwoffliner/mwoffliner.js [18:47:44] (Which needs i18n.) [18:54:24] *nod* [19:06:50] Krinkle|detached or Nikerabbit, suggestions on how to i18n that variable? https://sourceforge.net/p/kiwix/other/ci/master/tree/mwoffliner/mwoffliner.js#l559 [19:26:41] is it possible to override wgLogo on a single page? or set a different skin on a single page? [19:27:40] no (although you could probably write extensions to do these things) [19:28:27] I think there's an extension already for the different skin thing [19:28:31] I think its on foundationwiki [19:28:33] are used to be [19:28:41] or use CSS to change the logo on that pag and JS to add ?useskin= in URLs to that page [19:35:42] firebus: namespaces can use different skins, i think [19:46:10] wmat - yes, but i want to do it the wrong way :) [19:46:16] bawolff, i'll take a look, thanks! [20:10:02] hmm, i can't find either of these - extension or way to configure a namespace to use a particular skin...any more clues? [20:11:21] Isn't it SkinPerNamespace or something stupid? [20:11:32] !e SkinPerNamespace [20:11:38] https://www.mediawiki.org/wiki/Extension:SkinPerNamespace [20:12:41] https://www.mediawiki.org/wiki/Extension:SkinPerPage [20:12:45] firebus: --^ [20:12:58] wah, thank you!!! [20:19:27] gwicke: the first bullet is not rendered for me on this page in the ZIM https://it.wikipedia.org/wiki/Nati_nel_397 [20:19:47] * [20:21:41] Nemo_bis: also not properly rendered in http://parsoid-lb.eqiad.wikimedia.org/itwiki/Nati_nel_397?oldid=62551540 [20:22:21] the start-of-line context is likely lost [20:22:31] gwicke: am I supposed to be able to open that link? because I'm not [20:22:36] Nemo_bis: could you create a bug? [20:22:43] ok [20:23:04] Nemo_bis: the parsoid-lb link? You are probably using HTTPS everywhere [20:23:31] in that case, try https://parsoid-prod.wmflabs.org/itwiki/Nati_nel_397?oldid=62551540 [20:23:59] it's the same service, just through a https proxy [20:24:09] ah right, sorry [20:24:22] I removed the s but didn't pay attention ;) [20:24:44] Nemo_bis: thanks for noticing this & the bug report! [20:25:47] https://bugzilla.wikimedia.org/show_bug.cgi?id=66993 [20:26:02] one more coming soon I think [20:26:43] keep them coming ;) [20:27:09] gwicke: why that blank space in http://parsoid-lb.eqiad.wikimedia.org/itwiki/SuperSport_United_Football_Club?oldid=62790091 above "Matsatsantsa" [20:28:00] I must say it's much more satisfactory to file bugs about parsoid rendering than bugs for the poor Kelson to add hacky workarounds in Kiwix. ;) [20:29:07] Nemo_bis: it seems that there are a lot of empty s above Matsatsantsa [20:29:29] could potentially be something that's normally fixed up by tidy [20:30:15] Nemo_bis: definitely better to fix issues like this at the root rather than working around them [20:30:31] ok, will report on the template's talk [20:31:07] for this kind of issue it's often useful to look at the action=expandtemplates output [20:32:15] gwicke: it's useful if one knows what HTML/wikitext is legit :P [20:33:02] http://it.wikipedia.org/w/api.php?action=expandtemplates&text={{:SuperSport_United_Football_Club}}&format=txt [20:33:24] those empty trs are actually there in the template expansion [20:41:05] gwicke: same? http://parsoid-lb.eqiad.wikimedia.org/itwiki/Palesteena?oldid=63651287 http://it.wikipedia.org/w/api.php?action=expandtemplates&text={{:Palesteena}}&format=txt [20:45:17] also http://parsoid-lb.eqiad.wikimedia.org/itwiki/Lin_Biao?oldid=65783430 [20:46:55] I'll have to see what our template gurus think... [20:47:44] Nemo_bis: that looks very similar, yes [20:48:13] I need a special:random on http://parsoid-lb.eqiad.wikimedia.org/ [20:48:23] Hey folks! How do you set the title of a special page? My extension requires the use of a special page, though no matter what i think of it appears as [20:48:46] Nemo_bis: patches accepted ;) [20:49:03] !i18n | tweet_ [20:49:03] tweet_: See http://www.mediawiki.org/wiki/Internationalisation for developer help on MediaWiki internationalisation. To translate MediaWiki in another language, please visit http://translatewiki.net [20:49:22] tweet_: Create a new system message with the key "extensiontitle" [20:49:45] tweet_: https://www.mediawiki.org/wiki/Internationalisation#Adding_new_messages [20:50:59] bawolff: Thank-you so much! Didn't know it was that simple ;) [20:51:41] It can't always be 'extensiontitle' though [20:51:54] Surely you set the message name somewhere [20:52:26] It defaults to the special page name I believe. It can be overriden [20:52:35] *nod* [20:54:02] Specificly, by overriding the getDescription() method [20:57:04] gwicke: what's the expected behaviour with collapsible navboxes? http://parsoid-lb.eqiad.wikimedia.org/itwiki/Eicosano?oldid=65471489 [20:57:29] (if it's about using mw-collapsible they're working on that) [20:59:52] and is this expected way to show alt text http://parsoid-lb.eqiad.wikimedia.org/itwiki/Eicosano?oldid=65471489 [21:00:33] Nemo_bis: is the collapsing done in CSS or JS? [21:00:42] we currently only link CSS [21:01:13] JS probably [21:01:44] re the alt text: that's a CSS issue, a fix for which was finally merged earlier today [21:01:53] great [21:02:06] should be finally fixed ~2 weeks from now [21:02:09] alt text was the thing I was special:random'ing all over the place for [21:02:12] (after deploy) [21:02:36] Anybody in here remember me and my issue with ImageMagick? [21:02:46] Nemo_bis: all those CSS tweaks are linked from https://bugzilla.wikimedia.org/show_bug.cgi?id=51245 [21:05:27] gwicke: sorry, I don't find which one [21:06:32] this particular one was fixed by https://bugzilla.wikimedia.org/show_bug.cgi?id=51245#c19 [21:06:59] ok, that's not atomic enough, I need to track it on kiwix' tracker [21:07:14] you can subscribe to the bug if you'd like to follow work in that area [21:07:54] I shouldn't be debugging this at all right now :) enough of a time sink already ;) [21:08:04] maybe if/when we decide to make a DVD or whatever of it [21:08:14] okay [21:08:30] we'll continue improving this in any case, you can just use it [21:09:04] right now the kiwix importer still does a lot of rewriting, but soon that shouldn't be necessary any more [21:10:06] I know but I like this too much, I'd never stop then ;) [21:10:41] I'm glad you like it ;) [21:36:09] I'm testing out the UploadWizard extension on MW 1.23.0 - I'm getting the error "mw.log.warn is not a function", apparently in reference to its use in mediawiki.api.edit.js in the getEditToken function. I'm wondering if it may not have been defined in the case where it's used just by the API in a frame, or something similar. [21:36:23] If I comment out the mw.log.warn, it correctly uploads the file. [21:37:21] GreenReaper: Someone was here about the same issue on friday [21:37:45] GreenReaper: I think there's a problem with the version of upload wizard in REL1_23. tgr knows the details [21:38:27] GreenReaper: REL1_23 is actually REL1_22 with the wrong label [21:38:54] I don't recommend using it, it's a year old, there might be other problems [21:39:25] you should try wmf/1.23wmf instead [21:40:37] tgr: Do you know if current master works well with 1.23.0? [21:40:47] if so, lets replace REL1_23 with current master [21:41:04] sounds scary [21:41:13] Better scary and working than not. [21:41:58] wmf/1.23wmfXX branches are whe weekly internal releases before 1.23 is released officially [21:42:28] meaning, the last one is just a few days off from where REL1_23 should be [21:42:29] It seems odd that it would be an issue in UploadWizard if the file that the error is occuring in is mediawiki.api.edit [21:42:42] It's a MediaWiki function calling another MediaWiki function. [21:43:05] tgr: so, where's the REAL REL1_23 commit hidden [21:43:26] do we need to call an archaeologist? [21:43:39] SamB: there's a bug for this [21:43:40] yeah, but its so much easier figuring out where master is then the fake wmf branchs since they're submodules and my git foo isn't strong enough [21:44:12] bawolff: those are perfectly ordinary branches AFAIK [21:44:14] SamB: https://bugzilla.wikimedia.org/show_bug.cgi?id=64157 [21:44:21] tgr: why are those branches and not tags? [21:44:23] or are they tags? [21:44:33] a submodule is just a git repo specification + a commit id [21:44:36] SamB: because sometimes things are backported to older wmf versions [21:44:46] (to fix major issues in production) [21:44:47] SamB: to backport fixes, I suppose [21:44:47] tgr: oh they are now appearently [21:44:54] are there tags too? [21:44:55] In the past I'm pretty sure they didn't used to be [21:45:01] I am not the best person to ask about this though [21:45:06] SamB: there are tags for release versions only [21:45:11] not for deploys? [21:45:13] SamB: like 1.23.0, 1.23.1 etc. [21:45:14] yes [21:45:20] you'd think that would deserve a tag too, SOMEWHERE [21:45:30] maybe not in the main repository, but [21:45:36] eh, not really [21:45:40] SamB: Why, what's so special about tags that they deserve it [21:45:51] or at least i don't see why would that be useful [21:46:48] SamB: given that the problem is that REL1_23 was created with the wrong parent, I am not sure how a wrong tag in addition to a wrong branch would help [21:47:11] MatmaRex: thanks, I see the comment right at the end states the reason that UploadWizard isn't working. [21:47:14] tgr: I'm talking about tags on deploy [21:47:52] or, well, I guess any mechanism that would both identify the commit and keep it from disappearing would work equally well [21:48:33] for example, if the branches are fast-forward-only and there's some record of which sha1 got deployed which week ... [21:49:11] SamB: there are logs, if you're determined enough to dig through them [21:49:14] !sal [21:49:14] https://wikitech.wikimedia.org/wiki/Server_Admin_Log [21:49:37] MatmaRex: are the branches fast-forward-only? [21:49:40] SamB: but the situation sometimes gets complicated when something does wrong [21:49:49] in general it is pretty easy to find out from the commit dates [21:50:03] SamB: uhm, why would that matter? [21:50:14] or you can look at the log of the same branch in mediawiki/core which contains submodules [21:50:16] SamB: if you're asking if we ever merge master into wmf branches, then no, we don't [21:50:20] etc [21:50:27] SamB: they're not technically ff-only [21:50:30] not sure how this would be useful though [21:50:54] MatmaRex: no, I'm asking if deployed commits could later become unreferenced [21:51:09] I'm trying the master version of UploadWizard. Unfortunately it seems to want me to use Bahasa Indonesia (id) or ދިވެހިބަސް (dv) as the description language. This doesn't seem to be quite right to me. (I am using debug=true if that matters.) [21:51:19] which would make them inaccessible to anyone without shell access, and eventually result in them being garbage collected [21:51:24] SamB: if they are commited to the repositories at gerrit, no, never [21:51:27] MatmaRex: isn't basically everything that's behind gerrit ff-only? [21:51:48] MatmaRex: ah, okay, so that is pretty reassuring [21:51:52] SamB: sometimes commits are created directly in the deployment environment, e.g. for security patches [21:52:38] hmm, security patches seem unlikely to be a big deal WRT trying to recover what *should* have been released [21:52:50] but i'm not sure how exactly that works, i don't have access to such things :) [21:53:04] tgr: hmm, no? merge commits get created all the time [21:53:08] because security stuff causes such a stir it'd presumably get replicated where needed anyway [21:53:15] or i'm misunderstanding something [21:53:40] I think this discussion became completely disconnected from the original problem [21:53:42] tgr: some operations repos are actually ff-only, or were, you had to rebase every patch to merge it [21:53:53] just use wmf/1.23wmf22, period [21:54:46] it is the closest to what REL1_23 should be [21:54:49] tgr: submodules kind of scare me; it sounds *very* easy for people to get confused about them and lose submodule commits [21:55:10] how is this related to submodules? [21:55:12] and it's kind of sad when someone comes to #git who has done that [21:55:31] * bawolff is going to try and submit a patch to gerrit to fix this situation. Not sure if it will work. May explode [21:55:41] I mean, use the wmf/1.23wmf22 branch of UploadWizard [21:55:50] not MediaWiki core [21:55:54] tgr: just saying that submodules don't reassure me one bit about the continued reachability of deployed versions in general [21:57:11] knowing how they are implemented does *not* make me feel warm and fuzzy about their safety in the hands of anyone but a grand master [21:57:29] or, well, still not exactly warm and fuzzy even then ... [21:58:12] anyway, "ff-only" means "you can't drop commits from the history", not "no merges allowed" [21:58:26] I'm not getting any responses over on the SMW IRC channel, so I'm hoping someone here may be able to help. I'm running into bugs with SemanticResultFormats. There was a change 23 days ago regarding a call isSpecialPage(), though it only got 1 of the 2 occurrences of the call pattern. Now I'm hitting a similar but different bug with getPageLanguage. [21:58:31] or, well, that's what I meant [21:58:33] SamB: i am positive that there are never any deployed commits that are not patch of some branch in some repo, other than urgent live fixes. [21:58:42] not part of* [21:58:54] MatmaRex: yeah, that's more reassuring [21:59:30] Line 169 at https://github.com/SemanticMediaWiki/SemanticResultFormats/blob/master/formats/gallery/Gallery.php is breaking with "Call to a member function getPageLanguage() on a non-object in SRF/formats/gallery/Gallery.php on line 169 [21:59:35] this is during SMW_refresh.php btw [22:00:10] (maybe someday submodules will actually be able to live in the SAME repository as the supermodules somehow?) [22:01:37] Ok, well https://gerrit.wikimedia.org/r/#/c/141586/ didn't create 206 patchsets, so lucky so far [22:02:17] tgr: Want to +2 https://gerrit.wikimedia.org/r/#/c/141586/ - worst case scenario, is that the REL1_23 branch is just as broken as it is currently [22:02:29] so, anyway, is there going to eventually be a 1.23.1 issued for this? [22:02:42] ... not that I actually install mediawiki or anything ... [22:02:47] SamB: Umm, no. Its not an issue in 1.23.0 [22:02:53] oh [22:03:01] of core mediawiki [22:03:15] I meant a new tarball actually [22:03:27] UploadWizard isn't in the tarball (afaik) [22:03:31] oh [22:03:38] Well, slightly less broken, anyway. I'm still looking for the reason that the description language select is messed up. [22:03:43] so, does the tarball have the right versions of everything at least? [22:03:44] bawolff: what's mergeInto123-4 ? [22:03:53] Its a merge commit [22:04:19] I'm unsure if it actually worked, but there's a possibility it will break 1.23wmf22 into REL1_23 [22:04:26] or it might do nothing. I'm not sure [22:05:06] Anyways, it can't break the branch any more then it already is [22:05:14] woah. [22:05:16] eh [22:05:23] bawolff: sure about that? [22:05:33] you can always break things more with gerrit than they are broken already :) [22:05:42] Well there's that [22:05:49] It seems that "uwLanguages": really does have just "id" and "dv" in. [22:05:59] I'm leaning towards it possibly actually doing nothing [22:05:59] * GreenReaper has a look for where to fix that. [22:06:01] bawolff: tgr: ^d can force-push ;) [22:06:11] GreenReaper: Do you have a template named "en" [22:06:28] No, I do not. [22:06:30] * ^d runs and hides [22:06:34] upload wizard is a little commons centric, it assumes templates with two letter names are language templates [22:06:37] But we do have id and dv. [22:06:53] seems to me like 1_23 should just be repointed to the right commit [22:06:54] oh, here I thought ^d was a reference to the ASCII character ... [22:06:56] How not right. :-) [22:07:06] * bawolff was vaugely following http://stackoverflow.com/questions/12840279/how-to-merge-the-gerrit-branch-to-another-gerrit-branch [22:07:22] tgr: I'd have thought so too . . . [22:07:35] you know, the one that tends to trigger EOF on a terminal [22:07:53] bawolff: shouldn't this be a fast-forward merge if it was done correctly? [22:07:55] The one before wmf/1.23wmf22 is ac2e00d69e19d1a69b2d626208a28b2dd6d010c4 [22:08:12] tgr: allegedly, gerrit doesn't like it [22:08:12] tgr: I think the force pushing is for if something gets REALLY screwed up? [22:08:34] *doesn't like fast-forward merges [22:08:55] SamB: or if you want to really screw things up :) [22:09:09] tgr: I used the --no-ff command line option to prevent fast forward (based on googling) [22:09:12] REL1_23 did get real screwed up, tho [22:09:14] tgr: well, yeah, but I was assuming the idea was to try to AVOID screwing that up [22:09:25] also when I said "ff-only" I may have been mis-speaking [22:09:48] I guess I really meant "no push -f" or something ... [22:11:21] tgr: If it doesn't work, feel free to blame me 100% of the time [22:11:35] bawolff: if the goal is to get REL1_23 in a state where it would be if the branch had been cut correctly, that's a fast-forward IMO [22:11:51] I'm sure it will work [22:11:56] tgr: Yes. According to various docs though, gerrit doesn't let you do that [22:12:03] This should have the same affect [22:12:21] I'm less sure what happens if someone fixes the branch properly and then users do a pull [22:12:25] hmm, looking at the bug, I see mention of SyntaxHighlight_GeSHi and SpamBlacklist getting the wrong version included in the 1.23.0 release tarball ... [22:13:21] it would probably let you do that if you created 206 changesets by hand :) [22:13:29] yeah, but that's no fun [22:13:37] wouldn't you script it? [22:13:42] but you are right, this seems like the least worst option for now [22:13:44] Also unit tests pass, so the commit should leave the branch in a usable state [22:14:22] SamB: it is supposedly scripted [22:14:25] well, I think the cleanest thing WOULD probably be to push behind gerrits back if that doesn't involve -f and gerrit won't get too confused about what happened ... [22:14:28] yet somehow keep getting messed up [22:14:38] we had the same thing with the 1.21 release [22:14:54] (in fact, some of the extensions included in the release tarball caused a fatal if enabled) [22:15:05] SamB: yeah, but i don't have the rights to do that. I do have the rights to do this (and someone can always force push later if need be) [22:15:08] otherwise, you might need to merge the pointless merges into other branches [22:15:12] i think that was never fixed… [22:15:40] and once you get THOSE merged you're into !rewriting-history territory [22:15:52] bawolff: I suppose mediawiki/extensions should be changed as well, then? [22:16:08] oh, forgot that was even a thing [22:16:26] bawolff: I wouldn't place a huge amount of confidence in the UW unit tests :) [22:16:27] tgr: isn't it supposed to autoupdate? [22:16:36] MatmaRex: no clue [22:16:55] tgr: Nah, but its a sign that at the very least jenkins can pull the change [22:17:09] it think mediawiki/extensions is just submodules to master [22:18:05] bawolff: I mean the submodule config needs to be changed [22:18:21] but it might be automatic as MatmaRex says [22:18:38] doesn't mw/extensions only track master branches, actually? [22:18:53] why are we even doing this? hexmode: ping [22:19:06] tgr: the config, or the submodule objects in the tree? [22:19:16] MatmaRex: Hmm, just git pull'd it, there is REL1_23 in mediawiki/extension [22:19:24] MatmaRex: IIRC the person who first reported the bug used UW via the mediawiki/extensions repo [22:19:31] ugh. [22:19:31] !git 46225cdf6db96d [22:19:31] MediaWiki development is using git, a distributed source control manager, starting on March 21st, 2012; details: https://www.mediawiki.org/wiki/Git_happens Instructions for using it: https://www.mediawiki.org/wiki/Git/Workflow To get an account: https://www.mediawiki.org/wiki/Project:Labsconsole_accounts [22:19:36] !gerrit 46225cdf6db96d [22:19:36] https://gerrit.wikimedia.org/r/#q,46225cdf6db96d,n,z [22:19:38] <^d> A repo with ~200+ submodules. What a brilliant f'ing idea that was. Who thought up that crap? [22:19:41] <^d> OH WAIT I DID [22:20:00] who thought up submodules? [22:20:02] ^d: i know that feel [22:20:14] I've had that at a smaller scale ... [22:20:21] tgr: How about we try the merge commit in mediawiki/extensions/UploadWizard first, and then see if mediawiki/extensions.git needs fixing [22:20:55] bawolff: sure, give me a moment to test it first [22:21:01] like "who made this stupid todo-list plugin for this IRC bot?!?!#@@#$" "you did, SamB!" "oh :-(" [22:21:17] there are a few unit tests for show, but I would rather actually try an upload [22:21:27] ok [22:23:37] gwicke: and how about | style="border:5px solid transparent;" | | style="width:35%; border:1px solid #a7d7f9; background:#f5faff; vertical-align:top; padding: 5px 10px 10px 8px; -moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius:10px;"| http://parsoid-lb.eqiad.wikimedia.org/itwiki/Pagina_principale?oldid=65679446 [22:26:36] Nemo_bis: not sure what's causing this [22:27:02] that's main page, I guess we must fix it in some way :) [22:27:13] *nod* [22:27:58] yay! [22:29:45] Nemo_bis: let me create a bug [22:29:59] Can anyone help with an apparent SemanticResultFormats bug? [22:32:03] Nemo_bis: https://bugzilla.wikimedia.org/show_bug.cgi?id=67007 [22:35:44] Nemo_bis: without the space between the first double-pipe it parses fine [22:37:26] tgr: Looks like mediawiki/extensions.git auto updates - see 76efd27673ec39512a7a [22:37:54] cool [22:43:48] when calling action=render on a page, how can tell mediawiki to return the CSS together with the HTML? https://de.wikipedia.org/wiki/Burg_Gleiberg?action=render [22:45:15] zPlus: You don't [22:45:24] ?action=render means don't return css [22:45:45] Which of course makes it not the most useful of actions [22:48:35] bawolff: so how can I retrieve a wikipedia article content (html+css) without the left and top bars (that are shown with the default action=view)? [22:50:25] zPlus: At the moment, you basically can't. At best you can do ?action=render and build the css links yourself [22:51:05] zPlus: Maybe you can convince MatmaRex it would be a good idea to add a null skin that killed all chrome, but still added MediaWiki:Common.css and friends [22:51:45] Or maybe we should add a new ?action=embed, that's like action=render, but includes site css/js, and it suitable for embedding in say an iframe [22:52:12] but at the moment, we don't have much support for your use case [22:53:00] bawolff: this "action=embed" would be awasome... actually I wonder why it's not there already.... [22:53:18] Its awaiting someone to do it :) [22:53:42] Also, the way that ?action=render modifies urls is super ugly, and I think everyone is afraid of having to do something similar for ?action=embed [22:55:08] I would do it but I don't have any experience with mediawiki source code [22:57:06] Well new contributors are always welcome [22:57:49] Although the modifying url issue might make such a patch get caught up in review disputes (unless someone comes up with a better way to do that)