[02:05:23] umm, you could definitely write some js in MediaWiki:Common.js to do so [02:05:30] I don't know if there is a config option [02:05:36] i actually thought it was off by default [02:06:37] oh, i guess that changed in T222953 [02:06:38] T222953: Make "move subpages" checked by default on Special:MovePage - https://phabricator.wikimedia.org/T222953 [05:00:53] Hello, could you help me, please? I'd like to update MediaWiki (it installed from docker images). Where Can I get the update instructions ? [05:28:18] !upgrade [05:28:18] http://www.mediawiki.org/wiki/Manual:Upgrading [05:28:44] has at least the normal instructions. I'm not familiar with the docker images, but its probably pretty similar [05:28:58] bawolff: Yeah I kinda figured that was going to be the case. I just asked for the sake of telling the staff "I checked." I don't honestly know why they would want it off by default anyway. [11:51:34] Thanks for the merge James_F [12:17:42] RhinosF1: Happy to help! [12:50:48] Although why has CI taken an hour to merge [12:50:54] For https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1055600?usp=email James_F [12:50:59] 18 jobs still pending [12:56:44] there is just too much activity. it will catch up in the evening [13:09:40] Yeah, sorry about merging so much. [22:32:00] howdy folks, got a fun one. i've been running a mediawiki since before the 1.15 days, and one of our extensions is super old: https://pastebin.com/izBxsK8v ... unfortunately i think one of the "recent" (yes, yes, i know) versions around 1.35-1.38 removed support for this type of ancient extension. [22:32:22] since i'm a decade late to the party i'm not sure how to migrate this one. it's pretty simple, my brain's just fried. [22:33:14] that extension type is still supported, however the exact code is not [22:33:35] yeah that's what i mean [22:33:38] https://www.mediawiki.org/wiki/Extension:YouTube [22:33:45] just use that one as a replacement [22:35:43] i will have to do some bashing on this one to make it usable, but i suppose it works [22:35:57] it looks to be a direct replacement? [22:36:12] mine is not the base youtube extension, it has a few small changes [22:36:43] well that's just setting yourself up for failure if you're not able to keep up with dev changes [22:37:23] if the changes are useful in general I'd suggest submitting patches to the extension so it can just be part of the base one and then maintained as MW APIs change [22:37:37] i feel as if it may be worth pointing out that, in this case, the "failure" took about... ten years? i am not particularly concerned on that scale. [22:38:09] otherwise if the changes are just things like styling then you could use e.g. TemplateStyles to accomplish that instead via on-wiki templates [22:39:56] anyway, see https://www.mediawiki.org/wiki/Gerrit for info on getting patches upstreamed [22:40:03] still something to consider imo [22:40:36] it is ok to make ad-hoc changes to things sometimes. i find this very weird considering that the changes i made to the original extension largely just added two additional (optional) attributes, which just allow you to specify preset resolution names ("nes", "snes", "gb" etc.) that auto-set the width/height, and a "double" attribute that simply doubles the resolution specified [22:40:52] i don't think these patches would be very useful upstream nor worth implementing an entire new bespoke template or other system to replace this [22:41:51] i will just download the extension and make a simple patch. thanks for pointing out that the new version of the base extension, as i had not realized ours was forked off of it since, well, i think it has been over 12 years at this point. maybe more. [22:43:02] the first one definitely wouldn't, no, but I think would be achievable via TemplateStyles without any code edits needed [22:43:09] there have been many YouTube extensions over the years. I think the current one's pretty usable, but as its maintainer I'm slightly biased :-) [22:44:03] as for whatever issue you're having, I think it's at most a few lines of changes but I'd really recommend instead upgrading to a maintained extension (like mine, linked earlier on :P) and tweaking it as needed and submitting patches upstream - happy to try to review 'em :D [22:44:06] (if the generated iframe comes with width/height attributes defined even if you don't specify any then TemplateStyles might not work, and if it supports some tag to give it an HTML class name that'd be even better) [22:44:21] it looks like the required changes will mostly just involve nuking the height/width_max clamps and moving the size parameter parsing further upwards, and adding a new check for new $argv keys [22:44:40] fwiw don't use $argv [22:44:51] unless it's just a regular variable that was misnamed that [22:44:55] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/YouTube/+/refs/heads/master/YouTube.php [22:45:21] i am merely looking at what the current code uses [22:45:26] ok yeah the second case then [22:46:28] (PHP provides a global variable named $argv as well and that one is a lot less useful here, hence my comment) [22:47:34] also heh, our youtube extension is a single file, the one in the pastebin [22:47:50] the days before sprawling folders and hundreds of packages [22:48:12] ashley: you should probably remove the flash player support from the ext given that no longer exists :P [22:48:53] heh, indeed :P [22:49:18] i don't even remember when youtube last offered that style of embed [22:49:32] also the width/height fallback code. it makes it a lot harder to style via templatestyles/common.css [22:49:34] even before flash fully died they had transitioned to the iframe ones [22:49:43] Xkeeper: well technically even the simplest extension would be an extension.json file + main PHP class these days, so two files, and when you add in the i18n stuff you get...a whole lotta more files. and then CI stuff and all on top of that <.< [22:51:03] aye. (remember, most of my wiki work as back in the 1.15~1.25-ish days) [22:51:45] honestly the biggest pain in the keister atm is that on 1.34 there's some damn bug with the translation plugin that causes a translatable page that gets moved to get "stuck" [22:52:13] i fixed it once before (at least in the sense of unlocking it, not actually moving it) but forgot what i did [22:53:57] "This page is locked because the translatable page is currently being moved." [22:57:24] that's one of the things stopping an upgrade too since i'm not sure if this problem will get hosed during an upgrade... i have another wiki that's even older and it has some weird error on the suppress page that doesn't make any sense [22:58:00] you're using Extension:Translate? oh dear [22:58:03] "... /w/index.php?title=User%3AXkeeper&action=revisiondelete&type=revision&ids%5B49463%5D=1 Wikimedia\Rdbms\DBQueryError: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading or after adding a new extension?" [22:58:41] ok, so the first wiki i am running is one that is a little popular [22:58:50] what's the more precise DB error? :D [22:58:52] https://tcrf.net/Special:Version [22:59:19] aaa, TCRF is great :) [22:59:27] this is the one with the translation extension locked page error. and yeah :( i am not sure if there is a better one these dyas [22:59:44] the second wiki with the db error is https://datacrystal.tcrf.net/wiki/Special:Version - i'll get the full error in a sec. [23:00:08] https://pastebin.com/ZdRFEi2S [23:01:08] this one is a real headscratcher because on its surface it seems trivial: "key doesn't exist in table". ... except it quite clearly does! [23:01:26] but the query itself contains this: [23:01:29] ... `wiki_log_search` IGNORE INDEX (ls_log_id) ON ((ls_log_id=log_id)) ... [23:02:15] I mean...I think you need to ask yourself a bunch of questions regarding the workflow an' all. E:Translate was developed by and for Translatewiki.net for translating MediaWiki and other such projects; it...works for that use case (though some people, myself very much included, prefer the simplicity and versatility of editing raw PHP/JSON/whatever files over slow and tedious edits to on-wiki pages via wiki UI). I'd argue that for *most* use cases you don't [23:02:15] want E:Translate and some regular templates and doing the translation work manually will be a far more superior choice, but if you want certain management features etc. like automatic marking of outdated content then you'll need E:Translate [23:02:17] i tried all the various maintenance upgrade scripts in case one of them somehow didn't get run, but nothing i tried had an impact, and i haven't seen anything else that obviously errors out yet -- only suppression. [23:03:11] our use case involves translating the actual content of pages, rather than just interface elements... so to that end i think we do need it [23:04:54] https://tcrf.net/Paper_Mario:_The_Thousand-Year_Door is an example of a stuck page [23:05:25] it's been frozen for a few months now 😬 augh. [23:06:35] MediaWiki.org has had it installed for several years and perhaps it's just my experience but the whole "translation unit" stuff and the tedious process of having to use the special page UI and translate things bit-by-bit instead of e.g. translating a single page in a single go has ensured I won't bother translating anything; again, I'm biased but I encourage you to conside *why* you (think) you need E:Translate instead of manually translating the content [23:06:35] and sticking a nice language chooser template on top of said pages [23:07:09] (also I'm not a huge fan of partial translations, whether wiki content or software UI strings -- you'd really need like 80-90% or more translated for things to...make sense) [23:07:46] maybe moonmoon has some ideas re:the failing query? I'm not sure why the DBMS would say "key doesn't exist" if it does >.< [23:09:13] it is, best i can tell, because the query explicitly says to ignore the existence of the key. i have no idea why it is doing that [23:09:59] and yeah, the translate thing is definitely something that's... rough. it was a decision made likely a decade ago, and i'm not sure how doable a total change would be [23:15:08] was the wiki recently updated? [23:18:09] the wiki with the db error was last updated in january, though the error has likely persisted since then and just wasn't noticed. it is a very, very, *very* old wiki. [23:18:25] Xkeeper: anyway, for the first one it looks like an index got nuked by accident and ls_log_id doesn't exist (the index, not the column, they're different things) [23:18:32] ( September 8, 2005‎ ) [23:19:07] you can fix that via CREATE INDEX ls_log_id ON logsearch (ls_log_id); [23:20:17] er, sorry, should be log_search not logsearch [23:21:36] ah, that fixed it. i was fooled because that column is part of the primary key, but not a key on its own (PRIMARY KEY (`ls_field`,`ls_value`,`ls_log_id`)) [23:21:43] thanks. [23:39:44] i suppose that just leaves the translation extension locking pages problem to solve, though worst case i can see if an upgrade fixes it (though that will take a good amount of time, blug) [23:55:32] Xkeeper: what are you using for your main cache type? [23:55:53] i.e. redis, memcached, just the objectcache table in the db? [23:57:22] whatever you get when there is none defined in localsettings [23:57:24] eh I guess it doesn't matter [23:57:49] there's a maintenance script called eval.php, go run it [23:57:59] then paste the following lines into it: [23:58:56] $cache = ObjectCache::getInstance( CACHE_ANYTHING ); [23:58:56] $cache->delete( $cache->makeKey( 'pt-lock', sha1( 'Paper Mario: The Thousand-Year Door' ) ) ); [23:59:30] that'll force the lock to break [23:59:42] (you can get out of the eval.php script by typing exit; and hitting enter)