[06:30:52] hi) [06:32:04] need help with the visual editor when to edit a page, only the main one rules [10:17:22] Reedy: can confirm the patch totally fixes the deadlock issue, zero deadlock errors since I added it on the main wiki (11+ hours now) while the other, not patched yet, wikis get them (once a day since they are very low use) [10:18:11] next one I will try to find and devise a patch myself (ERROR: date/time field value out of range: "20190520222641" at character 715 and similar ones in IndexPager::buildQueryInfo etc.) [10:19:19] ohh this might need to_timestamp() for postgres [10:24:10] found a corresponding old issue [13:00:34] So I'm still searching for a way to correct my database so that I can edit MediaWiki:Common.js ... I imported and upgraded from 1.27 to 1.32 and somehow ended up with empty slots and slot_roles tables. This produced a fatal error on nearly every page access (I think some special pages worked). I found that if I populated the slot_roles and content_models tables that the wiki worked again. However, what I didn't notice at that time [13:00:34] was that I couldn't edit MediaWiki:Common.js because it thinks the revision content model is CSS and the current page content model is Javascript. [13:00:34] I've tried using Special:ChangeContentModel but it doesn't offer the option to change the page content model to JS because it already thinks the page is JS. [13:00:35] I've tried to look at the latest revision content model [13:00:51] SELECT slot_revision_id,slot_content_id,slot_origin,slot_role_id,content_size,content_sha1,content_address,content_model [13:00:52] FROM `wiki_fr`.`slots` INNER JOIN `wiki_fr`.`content` ON ((slot_content_id = content_id)) WHERE slot_revision_id = '26157'; [13:01:06] (content model = 2) and then ensure that content model 2 is JS: [13:01:15] update wiki_fr.content_models set model_name = 'javascript' where model_id = 2; [13:01:27] but without success [13:01:38] Q. Why didn't I immediately roll back on the failed import/upgrade? [13:01:38] A. It worked at first. The fatals mysteriously began later [13:01:55] Q. Why not reimport and re-upgrade; step-wise? [13:01:56] A. The DB is huge and most of it works (11 wikis) plus new edits have been made on the working wikis; and the time and money put into the upgrade can't be conjured from thin air. [13:04:10] Does anyone know how I can re-align revisions, slots, content_models etc. so that revisions to MediaWiki:Common.js are seen as Javascript? [13:05:48] duesen: ?? [13:49:17] I also tried setting $wgContentHandlerUseDB = false to get 'page's content model is then derived solely from the page's title.' [13:49:17] but that produced a fatal [13:57:27] hi all [13:58:16] I've set a wiki-family with Puppet, so my Localsettings.php is managed by P, so there is no need to use the install of mediawiki. But is there a way to just call the DB creation ? [14:01:06] I see the install.php, but it seems this will touch the LocalSettings.php which is not something I want of course [14:13:47] i can maybe do something with install.php and writes a useless LocalSettings.php somewhere that i'll not take care of, but install.php seems smart enough to detect I already have a LocalSettings.php defined (even if I took care of using --conf --confpath parameters) [15:44:12] debugging question: how do I force mediawiki to go to a code path like IndexPager::buildQueryInfo? I enabled verbose logs + DBQuery error logging but I cannot get it to happen again [15:45:45] oh [15:47:07] or not :\ [16:29:38] Reedy: I am wondering if it might be a good idea to wrap $offset in a DB connection timestamp() call in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/tags/1.32.1/includes/pager/IndexPager.php#401 [16:30:58] something (that Wget crawlers seem to hit) generates UNIX timestamps for the URLs, and this throws an error for Postgres [16:31:15] wait, not even unix [16:31:54] ERROR: date/time field value out of range: "20190510074846" at character 715 [16:34:43] Remilia: anything that does paging should hit IndexPager::buildQueryInfo. You may wish to use [[Special:AllPages]] for that purpose [16:35:31] Skizzerz: exactly, but something on the wiki that builds URLs makes these offsets in this format [16:35:50] your quoted value "20190510074846" is a standard mediawiki timestamp [16:36:00] yeah, and buildQueryInfo passes it as is [16:36:05] and postgres throws errors [16:36:24] sounds like a bug in the postgres schema then [16:36:32] if I edit this to 2019-05-10 07:48:46 it works [16:36:54] and *everything* else uses timestamp() wrapper on DB calls [16:37:00] except this [16:37:32] see T195807 for example [16:37:32] T195807: Fix failing MediaWiki core tests on Postgres database backend - https://phabricator.wikimedia.org/T195807 [16:37:33] some field is likely set up as a datetime or timestamp column, when mediawiki really just expects it to be a character field [16:37:52] it *is* a timestamp comparison [16:38:22] AND (rev_timestamp>='20190520222641') ORDER BY rev_timestamp [16:38:31] this generates errors [16:38:43] hello wikifolk, i've got a little problem with the svg -> png conversion [16:38:44] RecentChanges etc. properly generate Postgres-compatible timestamps [16:38:46] right, but mediawiki internally never uses datetime/timestamp columns in the main (mysql) schema, it does character strings. So, schemas which try to turn those into proper datetimes run into issues [16:38:58] your suggestion seems likely to work though [16:39:11] Skizzerz: it's why timestamp() exists I think [16:39:38] quoting the task, [07:43:30] All the timestamp failures are someone hardcoding a timestamp (assuming TS_MW) instead of using $db->timestamp(). [16:39:39] (well, you'd have to detect in your suggestion whether or not the field actually is a timestamp before calling timestamp() on it) [16:39:52] they aren't being rendered correctly: [16:39:52] https://www.apocrypha.ovh/wiki/T%C3%ADbet#/media/File:Tibet.svg [16:40:08] original: https://www.apocrypha.ovh/images/7/7c/Tibet.svg [16:40:21] is imagemagick too old or something? [16:40:48] because in your link, $offset may not necessarily be a timestamp. It could be a title prefix like "Abc" to say "Show results starting with the name Abc" [16:40:51] Skizzerz: this is IndexPager's buildQueryInfo, for a particular $offset, can it really not be a timestamp D: [16:40:59] oh [16:44:33] Skizzerz: so it should be converted in SpecialContributions.php instead, I am guessing? [16:49:19] Krusher: gñap. Some implementations of imagemagik / librsvg may render buggy PNG files depending on the complexity of the SVG file. You may try upgrading librsvg and/or imagemagick [16:49:37] gñap :D [16:50:00] alrighty i'll try to static compile imagemagick [16:50:06] debian package is kind of old [16:50:25] and librsvg tries to install a lot of stuff [16:50:41] Remilia: nope. ContribsPager.php -- https://github.com/wikimedia/mediawiki/blob/master/includes/specials/pagers/ContribsPager.php#L184 [16:50:54] that should be wrapped in timestamp [16:51:45] Remilia: should be relatively straightforward to write a patch against that. Do you want to do that or should I? [16:52:04] I'd rather test if everything works first [16:52:10] ok [16:52:12] like, whether it will break something else [16:52:17] that line should be $this->mDB->timestamp( $offset ) [16:52:47] if you want to try that out, let me know how it works [16:53:13] I already edited it yeah [16:53:13] thank you [16:53:30] er, typo [16:53:30] mDb though, with a small b [16:53:33] $this->mDb [16:53:34] yeah [16:53:44] :) [16:54:57] yeah that breaks it :D [16:56:37] I should make less mistypes and remember PHP better. [16:57:27] Skizzerz: seems to work for contribspager, I also edited MobileFrontend's pagers today lol [16:57:52] There's probably fixes like this that need making all over the place [17:00:07] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/+/REL1_32/includes/specials/SpecialMobileHistory.php#46 and https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/+/REL1_32/includes/specials/SpecialMobileContributions.php#189 [17:00:39] these are straightforward though because they are plain obvious SQL [17:04:55] next up on my debugging schedule is the behemoth called Cargo :( [17:06:11] Lol. Good luck :P [17:08:49] bawolff: I already reported some bugs/proposed patches to its author, but there is still work to be done lol [17:09:43] like: ERROR: column "_pageid" does not exist at character 181 HINT: Perhaps you meant to reference the column "cargo__table_name._pageID". [17:09:53] it does not quote identifiers [17:19:50] has someone managed to compile a REALLY static imagemagick? [17:19:53] with delegates and such [21:30:20] is there an easy way to delete 20K users? [21:31:36] exportdump all pages; import into new wiki [21:31:46] rip [21:32:52] there might be an extension to merge a user with another. this could be done with a script.. so only one user remains. not an easy way [21:33:30] tried block and nuke but it fails :/ [21:35:09] https://www.mediawiki.org/wiki/Extension:UserMerge i was referring to that. but it has no api and no maintenance script i guess