[01:58:41] qchris: Can you help with another repo too? https://phabricator.wikimedia.org/diffusion/ETWI/ should be mirrored to GitHub. [06:04:18] hello [06:06:34] on self_hosted http://listourne.info/ I reinstalled apache2, and on all the wikis, I get the same empty page with just run(); [06:31:17] hello. after having reinstalled apache2 on my server, none of my mediawiki does work anymore. http://listourne.info/al/index.php/Spezial:Version gives a 404 error, and http://listourne.info/al/index.php/ an empty page, I don’t know what is missing. [12:05:49] hi, I was looking at enwiki dumps - https://dumps.wikimedia.org/enwiki/latest/ I just want a dump of reivision histories and nothing else. Is there a specific dump that caters to this? [12:07:31] what I really want are the revision histories for the past 6 months having non-bot edits. Given the large number of edits, it timed out on quarry. Hence I think api also wouldn't be a suitable option [15:00:04] How easy is it to search in MW based on info like changes to Entries by a particular user or all the Entries which have not had a change since $DATE? [15:11:47] all changes by a particular user can be done by looking at that user's contributions [15:11:58] and then applying filters to it as necessary [15:12:24] latter seems a bit harder but might be doable via the api [15:15:40] Skizzerz: Thanks. [15:32:01] I am trying to put my logo in to infobox on the right. Everything shows up in the box but the logo. [15:59:42] Hey. Just updated our MediaWiki from 1.23, and we've got a custom skin. I see the "tooltipAndAccesskeyAttribs" function was deprecated, and the call to it is causing a fatal error; Is there a simple replacement for this function? [15:59:58] Mine googling is sparse for results on the matter. [16:24:47] Or.. maybe it wasn't deprecated? But it's just undefined anyway. [16:27:04] * Skin::tooltipAndAccesskeyAttribs was removed (deprecated since 1.21). [16:29:11] sgtlion: just swap Skin:: for Linker:: [16:29:34] Oh, right, removed from that class and in another. That makes a lotta sense. [16:32:16] It's been in Linker since 1.16 :P [16:32:46] So, where I've got a "$skin->tooltipAndAccesskeyAttribs". I-Is there yet another simple way around? [16:33:04] I never understood dang pointers. [16:34:21] Oh, same dealio. [16:34:27] I think I see it~ [16:41:01] sgtlion: Yeah, swap $skin-> for Linker:: [16:42:36] Dang extraneous $this'es too, throwin' me off. Alrighty..~ [16:53:36] Well, that's stopped PHP complainin' about it, so I'll take that as a positive. Thank you <3 Now just to deal with these other goshdang errors.. [18:02:42] Hm. Well. Fix'd everything else and the wiki now actually displays. But the theme doesn't appear to be loading whatsoever, yet I hath no error messages. [18:02:44] Such cruelty. [18:09:07] How do I properly uninstall Scribunto after having it in use? [18:09:15] MWUnknownContentModelException The content model 'Scribunto' is not registered on this wiki. [18:10:31] Either delete the pages before uninstalling, or change their content model [18:27:45] Reedy: the page erroring is Special:WhatLinksHere/File: [18:28:08] I can't change the content model for the special page and I tried changing the content model for the file page. It said it worked but I still have the reception [18:28:18] Exception* btw the file page itself does not error [18:28:52] PuppyKun: heh you pinged me :P [18:29:10] Oops hi [18:29:50] Hi :) [18:30:32] PuppyKun: It seems to be doing a lookup of the pages that are editable, to add an edit link [18:30:42] // if the page is editable, add an edit link [18:30:42] if ( [18:30:43] // check user permissions [18:30:43] $this->getUser()->isAllowed( 'edit' ) && [18:30:43] // check, if the content model is editable through action=edit [18:30:44] ContentHandler::getForTitle( $target )->supportsDirectEditing() [18:30:46] ) { [18:30:50] Is it for all images it fails? [18:30:55] Or just some specific ones? [18:32:28] I navigated to it from special:wantedFiles [18:32:47] Out of the 7 wanted files that's the only whatlinkshere that errors but I've also seen it for normal pages [18:32:59] Very weird the special page is the one that errors. None of the file pages or normal pages [18:33:28] Probably because it just doesn't do anything with it [18:33:40] Also I should maybe point out that the page in question was a file page with no matching file. I tried deleting and recreating the file page (Not uploading the file) didn't help [18:35:49] Reedy: possibly related, on Special:WantedPages the last 32 pages (Out of 44) just say "invalid title in result set: " And don't hyperlink [18:35:55] Ugh what did I do [18:36:51] *enables scibunto* [18:36:53] Why did you uninstall Scribunto? [18:38:37] Because I was importing a bunch of templates from enwiki and mwwiki that use it but I'm cleaning up the pages so they don't actually require scribunto and I'm not intentionally using it anywhere [18:38:50] It was during my cleanup efforts I noticed the issues [18:39:27] It's a wiki for work with a bunch of people who don't know anything (myself included) so I'm trying to keep the list of extensions down to like ~10 we actively use [18:44:18] Reedy: this is going well so far I think. Any way to easily find all pages with the scribunto content model? [18:44:36] SQL query? [18:44:45] I guess, technically anything in the Module namespace [18:45:38] well that namespace probably doesn't exist anymore without Scribunto [18:45:57] which would also explain the WhatLinksHere exceptions; there's a backref to some page from a namespace id that no longer maps to a namespace [18:47:03] I re-enabled scribunto and deleted like 40 pages that were in the module namespace. I'll double check there are no moee [18:47:29] Can stuff outside of that module have that content model? (Idk why it would) [18:48:03] don't think so [18:48:14] the nukeNS.php maintenance script can automate deletion of every module [18:48:44] Oh cool I will look at that script (assuming it's in /maintenance/ And has --help) [18:49:08] yep to both [18:49:37] you'll need to know the namespace ids though (not names) according to the documentation [18:50:12] looks like module is 828 and module_talk is 829 [18:53:34] nukeNS returned with no output (besides an unrelated php notice). Nothing in recent changes either [18:53:46] I guess I bad already hit them all with deleteBatch.php earlier [19:35:23] hi, is there any specific dump that can get me only the revision history of articles? I'd like to avoid downloading and processing the additional page-content as i just want the revision table [19:44:23] Harrum. I'm guessing my skin issues are stemming from a use of "data ); ?>", as that was throwing up fatal errors, despite seemingly not being changed since 1.23. I don't suppose there's simple enough replacement for this..~ [19:53:20] codezee: Only? [20:01:19] sgtlion: Replace it with Skin::makeVariablesScript I think [20:04:32] codezee: -stub-meta-history ? [20:04:35] I dunno if that's just for stubs.. [20:17:49] Reedy: wouldn't stub meta-history have revisions of stub articles? [20:18:06] I don't know which stub it is [20:18:22] Whether it's stub in terms of MW (but that's a construct inside the wiki) [20:18:47] https://dumps.wikimedia.org/testwiki/20180720/testwiki-20180720-stub-meta-history.xml.gz [20:18:51] 14.2MB [20:18:52] let's find out [20:19:50] ~52K [20:20:04] https://test.wikipedia.org/wiki/Special:Statistics [20:20:11] codezee: Seems like it's exactly what you want [20:20:23] looking... [20:20:46] It's a list of revisions [20:20:50] Text replaced with text ids [20:22:04] Reedy: what tool did you use to investigate the dump so quickly? [20:22:14] Downloaded a small one [20:22:15] Extracted it [20:22:18] Opened it in a text editor [20:22:21] Scrolled down [20:22:27] oh, okay :) [20:22:42] Rather than the multi GB that it would be for enwiki :P [20:25:58] Reedy: if it contains all revision info for all articles I fail to see the difference b/w this and -pages-meta-history [20:26:16] probably stub-meta-history has some first few revisions? [20:27:38] It's half the size for testwiki [20:27:43] let me see what the one for testwiki has [20:32:55] Hi, I'm adding {{uc:{{{status}}}}} inside a template. I would like the uppercase to apply to the content of what gets put in the status. If I write it like I do now, it just converts to {{uc:{{STATUS}}}} when I save the template. [20:33:22] can you help me write this so the {{uc applies later? [20:33:38] {{uc:{{{status}}}}} [20:34:07] Reedy: it has page content too thats why the bigger size, and pages-meta-current must be only for current version [20:35:09] Hmm, thanks, looks simple enough Reedy [20:36:58] -stub-meta-history for enwiki is 59GB... :P [20:37:18] There's a fucking lot of revisiions [20:38:08] haha, I'm really concerned with just say past 6months or 1year revisions and that too for main namespace pages. Since it seemed heavy for quarry I thought of using a dump [20:38:25] I'll filter these when extracting using mwdumper [20:48:12] Reedy: so going by testwiki stats, the stub dump should have 355k edits right? [20:48:37] I guess.. [20:49:58] it has 279k [20:50:21] there is *some* difference [20:56:12] It's a little vague what some of the dumps actually include [21:04:03] found a useful line here - https://meta.wikimedia.org/wiki/Data_dumps/Dump_format [21:04:18] "In addition, 'stub' dumps with filenames like stub-meta-history.xml.gz, stub-meta-current.xml.gz, and stub-articles.xml.gz, contain header information only for pages and revisions, omitting the actual page content." [21:05:13] so this stub is the real one, not the "enwiki" stub articles :) [21:33:58] Hello