[02:11:22] howdy ho - anybody awake? I've got an ancient wiki I'm trying to upgrade to current and need to know the deets on upgrading such an old version, (1.23.6) to current. I've downloaded a 1.34.1 install, I'm just worried about the database. [02:14:12] is it as simple as running the install script? [02:27:38] it wasn't for me. I ended up cloning it into a scratch site, then downloading every .0 from there to here and runnign that. I had an issue where it kept creating users with no name, and then complaining they existed [02:28:43] I'm not gonna say that's normal. but I don't try it on your live site. dump the db into a VM and give it a spin. [02:29:33] hmmmmmm [02:29:53] were you able to at least open the articles? [02:31:55] I don't think I tried. I ran upgrade.php and it complained about null actors [02:33:16] maybe I'll just downgrade my PHP and pull everything over article by article [02:36:56] try it the right way first. just do it on a backup. a) you don't break live, b) you make sure you have functional backups [02:40:38] somehow my mysqldump got mismatched... [02:40:44] bleeeh [02:42:35] I'll flat out admit I'm not sober enough for good advice right now, it's 3am. but get your backup working first. if all else fails you should be able to go there. once it's working, deploy it to a site and upgrade it. if that fails, nothing lost. [02:42:48] without that, the only option you have is to torch live. and that's not a good place to spend Monday [02:43:28] heheh [02:43:51] well, it's just a personal project anyway [02:44:21] i'm gonna down grade php to get it back running and I'll create a new one on my desktop [07:11:06] Hi there, I asked a few days ago about things not updating automatically, even categories are not being added to automatically (and it only has one thing in it) [07:11:17] I'm looking at the job queue, it seems to have never had anything deleted - or attempted [07:11:29] Everything has job-attempts: 0 [07:29:15] Oops wrong chat [07:29:15] I justran the jobs script - rebuilt the HTML and links, then edited a page, it's shown up in categories AND some links have changed from red to blue [07:29:16] But not on a non-namespaced page [07:29:16] It's jsut sitting there in the jobs list [07:29:16] Is there some default I messed up? [07:29:29] It is VERY much a stock fresh wiki [07:29:44] I added a namespace, added PDFs to allowable, changed default timezone weeks ago after a page existed [07:29:52] That was it [07:30:36] When I ran jobs I got no errors [07:30:59] If the wiki doesn't have enough traffic, jobs may not run fast enough in the default configuration [07:31:02] !jobqueue [07:31:02] The Job Queue is a way for mediawiki to run large update jobs in the background. See http://www.mediawiki.org/wiki/Manual:Job_queue [07:31:39] https://www.mediawiki.org/wiki/Manual:$wgJobRunRate - In theory a job runs on every page request [07:31:56] Vulpix: I've refreshed and browsed a few pages - and also it's not been running jobs for weeks when I checked the table just now [07:32:28] There is no mention of job rate in my LocalConfig file, so surely the default? Did that get changed to 0 or smething? (that'd be absurd?) [07:32:39] The only bit that seems newish is: [07:32:40] # MySQL table options to use during installation or update [07:32:40] $wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=binary"; [07:32:40] # Experimental charset support for MySQL 5.0. [07:32:41] $wgDBmysql5 = true; [07:32:45] That I don't remember seeing before [07:32:54] Jobs are removed from the table once they have been completed [07:33:21] Yeah I can tell from the IDs (and id 1 was in there) that it never did any [07:33:29] Until I did runJobs [07:33:37] Brand new wiki as I said [07:34:15] Still red - I don't get why some pages updated but this didn't (maybe the job that run on the submit request?) [07:35:06] Note that your bowser may have the page cached. Hitting F5 may get it from your browser cache and not hit the server at all [07:35:11] I've had watch and wget running every 45 seconds on the main page to give it ample opportunity. [07:35:17] Nope ruled that out, cleared the cache, tried wget to be sure [07:35:57] Also remember: no jobs ever run, I've been purging the few pages there are but then when that didn't work on categories.... [07:36:39] You can try to temporary set a debug log and see if there's something weird going on (like some error or whatever) [07:36:43] !debug [07:36:43] 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 [07:37:34] Vulpix: api.php?action=query&meta=siteinfo&siprop=statistics&format=jsonfm <--- this says jobs=0 [07:37:43] there's 1 job in the table. Related or just an iffy estimate? [07:38:18] I'd rather try rebuilding all pages (there a maintenance script for that?) before going that route! [07:38:30] historically the job count was an estimate to avoid to scan the entire table. I'm not sure if it's still the case [07:38:58] refreshLinks.php is probably what you want [07:39:04] Just to say it again: 0 attempts were made on all (before I did runJobs) and also this one job [07:39:21] I used refresh links, do jobs and rebuild all [07:39:27] That job is just sitting in the queue though [07:39:55] 2020-04-27 07:39:45 htmlCacheUpdate Part:Kaysen pages=array(3) rootJobSignature=5d155c21dfe596e4da0444bc583a0aa25ed2e57c rootJobTimestamp=20200427072445 STARTING [07:39:56] 2020-04-27 07:39:45 htmlCacheUpdate Part:Kaysen pages=array(3) rootJobSignature=5d155c21dfe596e4da0444bc583a0aa25ed2e57c rootJobTimestamp=20200427072445 t=2 good [07:39:59] Oh now it's gone [07:40:03] WTF is it doing? [07:40:27] And like magic, the link is blue [07:40:40] Vulpix: is there any recent history of a retarded default for the run jobs rate? [07:40:47] This is brand new, low traffic [07:41:28] No, the default job run rate is 1 [07:42:41] Caching can impact this, of course. I'm not sure if you set up file cache, if it would also skip the run if the page is cached [07:42:53] There is no cache [07:42:56] It's a tiny brand new wiki [07:43:29] Just to avoid being wrong (but I can read _NONE): [07:43:29] ## Shared memory settings [07:43:30] $wgMainCacheType = CACHE_NONE; [07:43:30] $wgMemCachedServers = array(); [07:44:04] Vulpix: there is an extension with no name showing up [07:44:13] *ParseHooks [07:44:16] on Special:Version [07:44:16] [no name] 1.0.8.11-wmf1 [07:44:33] But otherwise I just ticked things from the install, nothing added even [07:45:48] This looks like SyntaxHighlight extension [07:46:05] Actually a pretty old version [07:46:12] That's showing up as SyntaxHighlight – Licence Provides syntax highlighting using GeSHi - Generic Syntax Highlighter Brion Vibber, Tim Starling, Rob Church and Niklas Laxström [07:46:37] But could this even be related? [07:46:45] How did you get MediaWiki? And what version? [07:47:18] Vulpix: thanks for your time on a Monday morning of all things, I can't stress enough though how little has been done to this wiki, which is why I've bothered to come here, I wouldn't expect you to guess at what thing I screwed up if I had any such things to screw up [07:47:22] Vulpix: 1.24.6 [07:47:43] !1.24 [07:47:43] Old MediaWiki versions may have bugs and security vulnerabilities, we don't recommend you to use any release older than 1 year. See http://www.mediawiki.org/wiki/Version_lifecycle for details. [07:48:03] Yeah I know but there's nothing there about "we botched the job system badly" [07:48:17] I understand if the version number lets you go "not my problem" though [07:48:30] Your wiki may have more serious problems than jobs not running [07:49:27] There may have been a more serious problem introduced since that I happen to not have. I know it's an old version, there are reasons, however at the moment it's had none of those reasons applied because the jobs thing doesn't work and I didn't get round to it [07:50:31] I promise you again though: if it wasn't stock, not a plugin added or anything, I wouldn't come here [07:51:01] If you see history of job queue, on those versions it was a little funky [07:51:22] The only thing I would recommend is setting this to false: https://www.mediawiki.org/wiki/Manual:$wgRunJobsAsync [07:51:24] I've got other 1.24s that work fine (they're a little older) [07:51:59] But also if there was a massive cockup RE jobs in 1.24.x I'd expect it to be noted [07:52:20] Apart from that, you won't get any support from old (not supported) versions, even if they're stock [07:52:49] Thanks [07:52:52] Why might this work? [07:53:23] As in "why might the HTP access work fine for some sites, but not this new one" [07:53:35] Also: "Even if $wgRunJobsAsync is set to true, if PHP can't open a socket to make the internal HTTP request, it will fall back to the synchronous job execution." [07:54:11] I said to set this to *false*, The default was true in those old versions (and very buggy) [07:54:36] I've set it to false - let me try it one moment [07:55:09] There were like a thousand ways it could fail, that's why it was changed to false [07:56:40] Vulpix: that seems to have worked, I'll let you know more (from "yeah fine" to "no, I just used an even older version and imported the few pages") when I know more [07:57:50] How do you get the next AUTO INCREMENT Value in PHPmyAdmin (it's a part of show create) [07:57:51] One sec [07:58:05] In fact, it was me who sent the patch to make it default to false :) [07:58:06] Vulpix: it seemed to work 57 was created and run [07:58:58] Vulpix: on that note, with the whole PHP5.6 to 7 thing (that change happened FAST) what exactly is wrong with the 1.24.x series? It seems .6 works but .1 does not, is it just something I could fix myself? [07:59:06] My attachment to 1.24 I assure is rooted in reality. [07:59:47] You can take a look at the release notes [07:59:58] I will, thanks. [08:00:18] And thanks again for not going "lololol fuck you" when you found out the version [08:01:58] I had some experience about the job queue changes, otherwise I would have done that indeed [08:02:22] Me too probably, what luck [08:05:44] Vulpix: it seems to be doing 4 at a time, so it's working. Thanks very much [17:32:31] ymoisan: https://github.com/wikimedia/mediawiki/blob/master/docker-compose.yml#L22-L23 [17:34:19] Reedy : thanx. Those creds do not work but I'll investigate. [17:34:37] I did not use compose [17:35:21] Did you use https://github.com/wikimedia/mediawiki-docker ? [17:36:54] https://github.com/wikimedia/mediawiki-docker/blob/2dea40647eb85d6e0fc607904e0779644cf869c9/dev/README.md#extra-configuration-options [17:36:59] admin/rosebud [17:41:10] Reedy : yes; doens't work either [17:41:16] * Reedy shrugs [17:41:23] Reedy : yes; doesn't work either [17:42:08] I note "official" isn't so official [17:43:45] I'm using the SQLite version; any chance I could see plain text creds in there ? [17:44:43] Reedy: sorry someone else modified it on our side; sorry for the trouble [17:45:42] and thank you [17:47:19] :) [17:47:51] working now :-) [17:48:00] can't wait for 1.35 [17:48:03] cheers [21:15:20] Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. [21:15:21] Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. [21:15:21] Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. [21:15:22] Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. [21:15:22] Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. [21:15:23] Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. [21:15:33] Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. [21:15:34] Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. [21:15:35] Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. [21:18:25] ** Warning: if there is any bot in #mediawiki which should be exempted from Sigyn, contact staffers before it gets caught ** [21:19:20] let's see if it's passed [21:19:53] Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. [21:19:54] Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. [21:19:55] Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. [21:19:58] nope [21:20:04] :( [21:20:29] hm, shouldn't Sigyn have picked up on that? [21:20:45] Has to be trained to it, I think. [21:22:01] (there's a global ban on unregistered users for now) [21:27:27] Hey guys. Super techie squestion. It was possible for me in 1.29 to make Vector the default and ONLY skin while also making Minerva the default and ONLY skin for mobile. In other words: No Minerva for desktop, mobile only. [21:28:03] Since upgrading that doesn't seem to work anymore, I guess because these "require_once" things are too old, now....? Is there a way to make it happen again? :( [21:28:20] Why does it even bother me? I customised Vector for desktop personally for ads and I would like to not do this again for MinervaNeue >__<" [21:28:41] Most (all?) of the require_once's will need to become wfLoadExtension() or wfLoadSkin() [21:29:01] How did you do it previously? [21:29:43] require_once "$IP/extensions/MobileFrontend/MobileFrontend.php"; [21:30:05] It was perfect. Vector was the only choise in preferences on desktop. While Minerva was the only skin for mobile. [21:31:26] Mario-WL: when upgrading mediawiki, you'll need to also upgrade every skin and extension you used as well [21:31:52] consult the documentation for each of them for details on how to load them. As Reedy mentioned, most of the time it's just a matter of replacing the require_once with either wfLoadSkin() or wfLoadExtension() [21:32:14] I actually already updated both, MinervaNeue and MobileFrontend :( [21:32:29] but okay, I will try to swap require_once...... :/ [21:32:50] !extension MobileFrontend [21:32:50] MediaWiki has been built so it can easily be customized by adding extensions. This is usually a simple process. See http://www.mediawiki.org/wiki/Manual:Extensions for instructions to install extensions, as well as for writing them. See http://www.mediawiki.org/wiki/Extension_Matrix for an overview of known extensions. [21:32:54] bleh [21:33:28] https://www.mediawiki.org/wiki/Extension:MobileFrontend#Installation -- note how the instructions state to use wfLoadExtension for that extension [21:33:55] It won't fix your bug though [21:34:35] the reason it doesn't work the same is because Minerva is now actually a skin [21:34:51] oof. [21:45:37] changed everything to wfload. [21:46:02] doesnt work. Maybe Sky2042 is correct and I am now officially f********* and need to adjust MinervaNeue for ads all over again :D [21:46:15] brb downgrading to 1.29 again, haha . . . . . [21:47:02] "doesn't work" [21:47:11] We don't support downgrading ;) [21:47:33] it# [21:47:41] * Sky2042 laughs [21:47:44] *it's not my fault when an older version is better >.<" [21:48:33] thanks anyway for trying to help! i just stick with it and hope noone will see minervaneue in their preferences^^" [21:52:03] $wgHiddenPrefs[] = [21:52:11] $wgHiddenPrefs[] = 'skin'; maybe? [21:52:13] !wg HiddenPrefs [21:52:14] https://www.mediawiki.org/wiki/Manual:%24wgHiddenPrefs [21:52:26] Mario-WL: ^ [21:52:39] oh wow, need to try that! :O [21:56:35] oh my god [21:57:16] legoktm you are a genious! the only downside that .. lol in preferences now it doesnt show any skin at all XD but that doenst matter because it still uses vector and vector ONLY on desktop, now is possible" [21:57:22] you're my hero, in full honesty [21:57:48] happy to help :)) [21:58:15] it's technically possible to switch to minerva on desktop still I suspect using the useskin parameter, but that's usually only used for testing or getting around dumb behavior in certain skins (looking at you Timeless + VE) [22:00:36] I don't think so [22:00:57] https://gerrit.wikimedia.org/g/mediawiki/core/+/9a939d38d0b13d8f0ca03d1d0e7a17a8ec4e7379/includes/context/RequestContext.php#411 should be the relevant code, it appears to check $wgHiddenPrefs before looking at &useskin= [22:01:08] looks like even ?useskin=fallback doesnt work anymore lol, becazse hiddenprefs is too powerful XD [22:01:20] :O