[00:00:19] "Diff generation in PHP is slow as hell, so we use a C++ program for that (wikidiff2). However, wikidiff2 outputs (you guessed it) HTML." [00:00:25] (i don't think you can get it in any other format) [00:00:36] robertlabrie: that might not be true anymore. i actually have no idea what we use now [00:01:04] robertlabrie: MediaWiki supports several "backends" for the diffing. shelling out to `diff` is actually one of them [00:02:54] MatmaRex: Thanks. I'm playing with writing an alternate to the blame tool, I didn't want to hammer the API with 100s of requests, but not all diffs are cached, and the API will only generate the first one, the rest return "notcached": "". [00:09:15] we still use wikidiff2 [00:13:38] Thanks. FWIW I find the project fascinating. 15 years is a long time for a piece of software to hang about, you've had some serious scale issues to resolve, some old design choices come back to haunt you, and still manage to run one of the top 10 busiest sites on the web and keep fantastic uptime and response times. Well done folks. [01:32:31] Hi! I'd like to store some extra data in a wiki that can be retrieved and updated from the MediaWiki API (a list of strings for now). Could anyone tell me where to start implementing this? I'm completely new to MediaWiki [01:49:23] pavonia: you could potentially use either the Semantic MediaWiki or Cargo extensions for that. [01:49:28] !e Semantic_MediaWiki [01:49:28] https://www.mediawiki.org/wiki/Extension:Semantic_MediaWiki [01:49:33] !e Cargo [01:49:33] https://www.mediawiki.org/wiki/Extension:Cargo [01:53:59] Yaron: Does Semantic use an extra API or can all its data be accessed through the standard MediaWiki API? [01:59:19] There's #semantic-mediawiki, I guess I ask futher questions there [01:59:30] Thank you for your help! [03:49:50] help can not get to site after adding localsetting.php to main folder [04:02:17] ffpoke1: probably a php error. check your php logs [04:13:23] i got permission denied in php error log file [04:31:12] got it working their was a missing s on localsettings.php [10:50:42] why is the diff so bad? i'm sorry to say but it's painfully bad. [10:50:52] diff of edits made by wikipedia users [10:51:21] It's as if it uses the dumbest diff algorithm in existence, and never improved upon it. [10:52:53] What's wrong with it? What should be improved? [10:53:16] (Note: I'm not saying it's good/bad/indifferent) [10:59:02] RandIter: ^ [11:00:53] Reedy: As someone with articles on my watchlist, the diff patterns colored by the diff tool are frequently worse than useless. [11:01:49] If you need me to find examples to prove this obvious issue, I can find them. [11:02:18] The diff algorithm needs changing [11:02:26] You might want to open a phabricator task listing problems, examples are good [11:02:35] And any possible solutions as you see it [11:03:02] What's a phabricator task [11:03:16] phabricator is our bug tracker [11:03:23] https://phabricator.wikimedia.org/ [12:38:01] !restore [12:38:01] See http://www.mediawiki.org/wiki/Manual:Backing_up_a_wiki for information about backing up your wiki. For restoring your wiki, see http://www.mediawiki.org/wiki/Manual:Moving_a_wiki#Import_the_database_backup for more. If you don't have database access, try !grabber. [12:38:44] !package [12:38:44] Many Linux distributions provide MediaWiki in a packaged format for that distro. These packages typically contain obsolete & unsupported versions of MediaWiki; they also like to move around & change files, & do other super-counterproductive things. You'll get the best support here if you install MediaWiki directly from one of our tarballs - https://www.mediawiki.org/ - or Git https://www.mediawiki.org/wiki/Download_from_Git [12:41:31] hi guys - I know this is possibly more of a Semantic Mediawiki question, but.... got a Category page that's not rendering properly. It's got an SMW #ask query in it, and that seems to get cached for a very long period of time. Can we shorten that, or better still, disable the caching completely? [12:45:14] cm13g09: Not really. smw only re-parses when there is an event. You can enable a purge tab to refresh as needed [12:46:16] Betacommand: even if I issue a purge it doesnt :/ [12:46:53] I've got something where I've changed the "location" (which is an SMW attribute) [12:47:06] cm13g09: then its not a cache issue on that page. [12:47:09] and it doesn't update in the table for #ask [12:47:22] I can't see what else it would be though [12:47:58] cm13g09: check the page where you changed the value thru the view properties and ensure that that page properly updated the stored value [12:48:22] hey guys, currently working on a project that involved the Wikimedia API to get content from Wikipedia. Just to fully clarify, there is no limit to how many API calls I can make? [12:48:29] I have seen cases where the stored value for SMW never happened [12:48:51] domsch: depends on what your goal is [12:49:01] Betacommand: ah... I think I see the issue [12:49:11] it's on something that's moved namespace [12:49:20] well basically create an instant search of wikipedia content [12:49:49] domsch: so why are you querying the API? [12:50:09] do you think web scraping is better? [12:50:14] and faster* [12:50:15] No [12:50:54] domsch: are you compiling your own search index or just hitting the wikipedia search api? [12:50:55] what would you suggest to use then? (This is a side project btw, mainly trying to learn some more Node.js) [12:51:15] hitting the wikipedia search api is what I wanted to do so far [12:51:51] but I would greatly appreciate some input on how to create this in the best way, namely that performance is great (that holds true to the instant search) and that it doesn't waste unnecessary resources [12:52:45] domsch: if your really going to delve into different ways to search, or are making a large volume of queries I would just parse a database dump and skip the API [12:53:45] Betacommand: figured it out [12:53:49] or at least, half of it [12:53:58] Needed to set smwgNamespacesWithSemanticLinks [12:54:06] Ah [12:54:09] ok thanks for that suggestion. Do you think that using the API generally is a bad usecase for what I intend to do? [12:54:28] I can perhaps work on a prototype that uses the API and then switch over to the db dump once I want to make it go live [12:54:32] domsch: depends on the overall volume [12:54:58] however, I now have a new problem [12:54:59] and rate [12:55:07] cm13g09: ? [12:55:44] duplicated page titles in #ask results [12:57:07] alright thanks for your input Betacommand. Have a nice day [12:58:31] you might need to rebuild the SMW database [13:00:24] I cant recall exactly where the extension has the file but: rebuildData.php -f Should fix the issue [13:00:44] I ran into that when I moved a page without leaving a redirect [13:15:27] How do I create a custom skin? Manual:Skinning seems to be outdated. [13:24:01] kthx_: which part seems outdated? it should be up to date. [13:24:53] kthx_: if you're looking for practical advice, the answer is "copy an existing skin, search-and-replace all instances of its name, and work from there" ;) [13:30:36] MatmaRex: Since MW 1.25+ it seems that skins should be loaded via wfLoadSkin rather than require_once (educated guess). Since this isn't mentioned in the tutorial I figured that it's not up to date. [13:32:27] kthx_: hmm, true, i guess no one updated that. but the require_once way still works just fine. [13:33:08] kthx_: the information on that page was correct when i last looked at it ~3 months ago. [13:35:17] MatmaRex: I know that it works, but if I create a skin, I want it to be compliant to the latest MW version so I don't have to update it as long as possible. :D [14:06:01] kthx_: i updated the tutorial, thanks for pointing it out. https://www.mediawiki.org/w/index.php?title=Manual:Skinning_Part_1&diff=prev&oldid=1883211 https://www.mediawiki.org/w/index.php?title=Manual:Skinning_Part_3&diff=prev&oldid=1883412 [15:48:39] Hi, my importDump.php is not really progressing for 1h or so :-( showJobs.php shows me 4987 [15:48:45] so I guess I should runJobs ? [15:53:45] You could [15:53:55] but it probably won't speed up importDump [15:58:38] thx [15:59:04] what happens when I cancel importDump.php, will it try to reimport again all, or just check + skip if imported already ? [15:59:25] cancel reason being: so I could runJobs [16:00:07] You shouldn't need to cancel it [16:00:14] Doesn't it display any sort of progress? [16:00:36] it does: but it's hanging now for a while at: [16:00:38] 5400 (0.21 pages/sec 0.21 revs/sec) [16:00:52] and I have in total 6800 pages to import [16:00:56] look at top or similar? [16:01:12] it's not CPU or RAM loading, unfortunately [16:01:29] just, as if it ran in some kind of deadlock, feels like [16:01:41] I've got a feeling that by default it will import revisions repeatedly [16:02:01] You could, of course, just modify the xml file to remove the already imported ones to "fix" that problem [16:02:10] yeah [16:02:18] let me check how the xml file looks like [16:06:09] OK, I see the page tag encapsules each article [16:06:18] so, I can manipulate the xml file [16:29:04] what are PostEditRevision cookies for? [16:31:27] destrier: its used to show you the 'Your edit has been saved' message [16:32:35] legoktm: hmm... should they not then be deleted? mine seem to keep piling up [16:35:43] I'm looking through the code and it *should* get deleted [16:35:52] except I'm also seeing some of those cookies in my browser [16:37:28] destrier: let me file a bug about this [16:41:04] destrier: https://phabricator.wikimedia.org/T112771?workflow=create [16:42:29] ok :) [17:03:00] it's strange, the Jobqueue was decreasing at first, and now it''s increasing. Having a length higher than what I had before running runJobs.php [17:07:17] Erkan_Yilmaz: some jobs queue other jobs [17:07:45] I see. ok, then I can let my heart beat slower again [17:07:47] thx [17:46:19] I want to retire an old esxi machine that has a wiki we still use on it. I'd like to build a new VM from scratch on one of our proxmox servers, export the existing DB and import to the new server. Any gotchas or advice? [17:47:24] !moveawiki [17:47:28] !movewiki [17:47:28] For help about moving pages, see . For help about moving wikis, see . [17:47:45] Thanks! :) [17:49:26] Backup all the files on disk, backup the db and you should be in good stead for setting it up elsewhere [17:50:02] That's what I figured. Building the new server now. :) I'm going Wheezy -> Wheezy, so it should be fairly painless. [17:51:27] * crhylove does a little dance. [17:51:44] Can't wait to kill another esxi server, and have our whole datacenter be Debian based. :D [17:51:53] (almost, still a couple of stragglers). [18:01:29] hello, I'm already using oauth for authentication currently, but intend to use it to do small edits in a template on pages on commons. Would I just need the Basic Rights (writeapi) or would I need the Edit Existing Pages right (edit). I'm not sure how the write api differs from editing [18:03:03] chippy: Presumably you'd need both [18:04:46] There's also a "make changes to pages" grant https://meta.wikimedia.org/wiki/Special:OAuth/grants [18:05:05] chippy: writeapi allows things like the user being able to watch pages via the api [18:11:33] Reedy: thanks, I think I'm understanding it a bit better now [22:58:15] Success! [22:58:46] The scariest part (the SQL recovery) worked perfectly. But I was doing some dumb IP stuff, so it took me longer than it should have. :/ [23:43:08] crhylove :-)