[03:01:09] Hey guys, having some issues with my wikis job queue. Was wondering if anyone could assist. Not too sure whats going on but jobs are piling up, trying to run runJobs.php manually does nothing. [03:03:32] https://i.imgur.com/zrHgMTw.png is a pic of what showJobs lists is available. [03:12:18] mwprobs: abandoned means the job failed...are you logging errors? [03:13:24] I'm not sure if errors are logged. I did the initial wik isetup then someone else took over. I was asked to help fix issues now that they let them pile up. [03:14:49] !debug [03:14:49] For information on debugging (including viewing errors), see https://mediawiki.org/wiki/Manual:How_to_debug . A list of related configuration variables is at https://mediawiki.org/wiki/Manual:Configuration_settings#Debug.2Flogging Also see https://mediawiki.org/wiki/Manual:Errors_and_symptoms [03:15:42] ^ you should enable that and then check back after a some more jobs run and see what the errors are [03:17:32] Thanks, added wgDebugLogFile entry, will see if anything populates soon. [03:17:50] Is there anything I can do about the 600+ jobs that are still stuck? [03:18:14] Anyway to try to force them to re-run and perhaps get logged errors for those afterward? [03:27:25] mwprobs: I'm not sure if there's a way to get them to re-run without doing some hacky stuff... [03:31:29] I see some dbg output if I try to runjobs again, it seems to specifically look for things under 3 attempts. [03:31:44] As well as timestamps. [03:34:14] Is there a better detailed page about runJobs.php? The current docs lacks a ton of helpful info on each sub command and such. https://www.mediawiki.org/wiki/Manual:RunJobs.php [03:55:16] So someone just made a small edit to a page, there is a new job 'htmlCacheUpdate' as the job_cmd. It is also now stuck in the job table and not being handled properly. Nothing in the debug log for it. [03:56:09] It has a job_token showing it was claimed. But it seems the job has either not ran or is not finishing. [03:56:42] (this is all on: 1.29.1) [06:32:36] I am confused about a mediawiki API [06:33:28] in the example here https://www.mediawiki.org/wiki/API:Revisions#Example the revision's content is returned under the "content" key, but if you follow the API request link in the example, you get it under "*" instead [06:33:49] I've also tried two other mediawiki wikis and I'm getting the same thing [06:33:56] is this a mistake in documentation or am I missing something? [06:35:21] chek: add &formatversion=2 to your query [06:35:56] I see, that has done it [06:36:56] if you're writing new API code you should always use formatversion=2 in general, it produces more sane output than the original version [06:37:29] I'm also hitting wikia which appears to be forked from a significantly older version of mediawiki [06:37:40] I've even had to use query-continue [06:38:14] yeah, Wikia is about ~6 years behind now I think [06:38:17] but this does answer my question [06:38:19] it'll be very different [06:38:20] thanks [06:38:23] np :) [14:37:14] hi, is there a way to search mediawiki's search results by the article updated_at time? [14:37:39] woops, i meant, sort* the search results [14:43:59] Hallo comrades, [14:44:37] I use MediaWiki for my site. In the footer there are Description link, and Policy link, and License link. [14:44:46] How can I change the order of these links? [14:51:15] Hallo people, I use MediaWiki for my site. In the footer there are Description link, and Policy link, and License link. How can I change the order of these links? For example, to set Description before Policy? [15:07:10] PMZ_: Put this in your LocalSettings.php: https://de.pastebin.ca/3886611 [15:08:52] eddiegp: why use a global function? :P [15:08:59] It will change the third with the second item in this example. How exactly you're goint to reorde that array depends on the order you want to achieve. [15:09:08] Reedy: https://www.mediawiki.org/wiki/Manual:Footer [15:09:13] :P [15:09:42] fixed [15:11:13] Okay, it's https://de.pastebin.ca/3886616 then ;) [15:15:45] I see, thank you, eddiegp ! [16:20:17] Hello and thanks for the awesome wiki engine [16:20:35] I have an installation that is a bit old. it is 1.28.0 [16:21:48] That's still supported [16:22:53] Should I upgrade to 1.28.2 or go for 1.29.1 ? [16:23:02] Depends [16:23:07] Certainly go to at least 1.28.2 [16:23:19] 1.30 should be out "soon" [16:30:42] How / when do I upgrade the extensions? [16:31:08] Usually in a point release, you shouldn't need to update extensions [16:31:33] but if I want to go for 1.29.1 ? [16:33:13] I'd reccommend updating your extensions then, yes\ [16:33:57] hi there [16:35:16] I moved the directories around and I'm getting [16:35:17] [166d9417bf374b17c7374469] 2017-10-12 16:41:26: Fatal exception of type "Wikimedia\Rdbms\DBQueryError" [16:36:05] !debug [16:36:05] For information on debugging (including viewing errors), see https://mediawiki.org/wiki/Manual:How_to_debug . A list of related configuration variables is at https://mediawiki.org/wiki/Manual:Configuration_settings#Debug.2Flogging Also see https://mediawiki.org/wiki/Manual:Errors_and_symptoms [16:42:16] running update.php all seems to be good at http://wiki.study/regarding/Special:Version [16:43:15] Due to a server malfunction I only managed to do a simple mysql db dump of the mediawiki db. I restored the database in it's entirety and I moved the existing mediawiki install (from a few years old at least) to a new server. From what I understand locations are hardcoded in the database (like for stored images)? I'm also getting error with php7. It appears the version I've been using isn't fully compatible with php7. [16:43:40] how would I manually upgrade to a new mediawiki install and update the appropriate database locations? [16:43:46] !upgrade [16:43:47] http://www.mediawiki.org/wiki/Manual:Upgrading [16:44:22] at least the webbrowser method of upgrading will not work [16:44:48] I'll painstakingly have to worry about merging a new version of the wiki into the directory with the existing assets or the other way around [16:44:53] and then update the db in some way [16:45:07] is php7 fully supported? [16:45:33] "How do I upgrade from a really old version? In one step, or in several steps?" [16:45:36] this might be helpful [16:46:05] It's pretty much the same process [16:46:07] Backup the files, backup the db [16:46:10] Replace the files [16:46:13] Update the db [16:46:58] the server is no longer functional, though - so I cannot redo the dump if I made a mistake. [16:47:38] But you've restored it? [16:47:41] the db has been restored via mysql from the dump and the files are in a new location [16:47:45] So make a backup from where it is now? [16:47:47] I'm getting some php7 errors [16:47:54] on what version of mediawiki? [16:48:08] moment, I will check that [16:48:11] I wouldn't expect anything less than 1.23 (or probably even 1.27 at this point) to work on PHP 7 [16:48:37] it's from 2014 I think? [16:48:41] or 2013 [16:49:06] 1.19-1.22 then possibly [16:49:42] 1.21 [16:49:45] so exactly in the middle :D [16:57:09] Ok.. http://develop.consumerium.org/wiki/Special:Version is now 1.29.1 .. how do I easiest upgrade all the extensions ? [17:47:38] legoktm: Maybe a combination of that with all the recentchanges purging [17:47:57] although it is weird as one would think wait for slave would have prevented issues [17:52:46] bawolff: yeah, unless the deleting of 500 row itself was too slow? [17:55:42] It was just a little increase though, but an increase to > 6 seconds. Which seems like really a lot for just deleting 500 rows [17:56:36] that would though explain why the issue immediatly stopped after 3 hours, since if it was the wikidata rc stuff i would expect it to still be ongoing [18:23:34] legoktm: The thing that confused me, was if there was so much slave lag that commons went into read only mode for a large portion of a 3 hour period, shouldn't that have triggered lots of alerts in #wikimedia-operations ? [18:23:48] yes [18:23:54] well, that's what I would have assumed [18:49:22] is it possible to simply extract assets from an existing installation, move them to the latest version of mediawiki and use the old db? (while going from version 1.21) [19:01:22] Surkow: what do you mean by assets? and what do you mean by using the old db? [19:01:30] what is it you actually want to achieve? [19:02:16] I'm looking at upgrading an old installation that is no longer functional. I dumped the database and on my new host the installation does not function due to php7 [19:02:36] I've been reading about upgrade scripts, manually editing configuration files and the like [19:02:50] and all I have is a database with text, users and a bunch of images stored in the mediawiki directory [19:05:30] You can install a new version of mediawiki, replace the new database with the old one, make sure your config is correct for the old db, and then run the update script. [19:05:58] but... which installation does not work because of php7? the installation of 1.21? Just install 1.29 then. [19:06:15] yes, the backup I made was version 1.21 [19:07:01] the database is already operational, with the correct user/pass [19:08:16] the problem is that you don't have a working config file for 1.29 if you don't run the installer [19:08:30] I'll give that a try [19:08:34] so... run the installer for 1.29 on a *different* database [19:08:40] I'm still reading through what a normal update is supposed to do [19:08:42] ah [19:08:43] once that is done, edit the config file to point to the old database [19:08:51] now that is a nice approach [19:08:53] then run maintenance/update.php [19:09:09] and I suppose I just copy the image directories back in the new install? [19:09:16] (after all is working correctly) [19:09:29] and then I'll probably have to update the database with the new image locations [19:09:39] since I moved the location to /srv/ from /var/www [19:09:43] it's a bit silly. the underlying problem is that the web installer can't do the db update. it would take too long. it would not be nice if it aborted in the middle, because the browser timed out... [19:09:54] yeah, I can image [19:10:14] Surkow: no image locations are stored in the db. only the file names. the rest comes from config. [19:10:20] so yea, just copy them over [19:10:27] that sounds promising :D [19:10:28] thanks [19:10:46] MediaWiki is indeed designed to be tollerant against being moved around. [19:11:24] as long as the web path doesn't change, you don't need to do anything. if the web path changes, you have to change a single config var. that's it. [19:12:31] the public facing path/domain etc will stay the same [19:12:44] * Surkow reminds himself to update mediawiki more often [19:13:12] * DanielK_WMDE has a 1.16 running somewhere [19:13:32] * DanielK_WMDE had a 1.16 running somewhere. seems to be dead now. [19:15:24] my condolences :P [22:01:41] Hello, was in here yesterday asking about issues with mediawiki's job queue. It seems MW is failing to process any jobs. They get claimed and then never finish or clear from the db. No errors in the error log either about any of the jobs either. Just typical queries showing stuff being done etc. but no actual errors. [22:02:59] My wiki is up to 667 jobs sitting claimed but failed now in the db. [22:05:06] I'm running debian jessie 9.1 on a BBB. I would like to use a gateway/wireless cape. is this possible? it seems the TI Sitara SDK hasto be run in place of debian and I would lose signifigant funcionality. [22:06:46] PhillipB hi, is that a mediawiki question? [22:06:54] or router / debian question? [22:07:34] i was linked here from the TI wiki [22:10:44] mwprobs: see https://www.mediawiki.org/wiki/Manual:Job_queue for some hints and possible problems in older MediaWiki installations. In 1.29 it should just work with the default values [22:11:06] I am using 1.29 [22:14:14] If I run runJobs.php myself nothing happens either. No output at all from it. Debug log shows the queries it does, no errors or any other useful info. [22:27:11] mwprobs: what if you run runJobs.pph with error_reporting( -1 ); ini_set( 'display_errors', 1 ); ? [22:27:19] s/pph/php [22:27:32] Same thing, no output or errors. [22:30:46] This is all that the debug log gives when manually running it: https://paste.ofcode.org/Kijqznr7ikhkqNNCbsqir8 [22:32:06] wgShowSQLErrors, wgDebugDumpSql and wgShowDBErrorBacktrace settings are all set to true for this at the moment as well to try and help figure out whats wrong. [23:04:44] I adjusted the mw_job table so that the jobs would re-run. MW 1.29.1 appears to be leaking job info onto the main wiki pages (at the bottom) when a page is requested. [23:05:32] https://i.imgur.com/m2BY5Qg.png [23:38:07] Ok all fixed.. someone else apparently logged in trying to fix this before and messed up one of the job scripts, reverted to original and things are working ok again.