[04:12:18] [[Tech]]; 70.66.16.93; /* "Watch This Page", "Permanent" */; https://meta.wikimedia.org/w/index.php?diff=20685478&oldid=20682668&rcid=16710904 [05:09:54] [[Tech]]; AntiCompositeNumber; Undo revision 20685478 by [[Special:Contributions/70.66.16.93|70.66.16.93]] ([[User talk:70.66.16.93|talk]]) rvv; https://meta.wikimedia.org/w/index.php?diff=20685635&oldid=20685478&rcid=16711132 [05:39:12] I'm importing various images from enwiki to commons, and selecting the 'delete this image from enwiki in the process' option, and three consecutive images (from two separate sources) have given me "The file could not be deleted automatically on en.wikipedia.org. Please return to the original file and delete it manually." [05:44:32] ... and that's 0 for 4, from 3 different sources. The first three images, I renamed in the process of moving, but the fourth one, I left with its original name. And the automatic deletion still failed. [05:46:35] 0 for 5 [06:03:03] also, when I move a file to Commons and change its name in the process, and it's in use on a page, and then I edit the page to reflect the new filename, I'm getting redlinks. Even when I just copypaste the new name over the old one. [13:19:03] Hi, does anybody know if there's been some recent change to ResourceLoader? I'm getting lots of 404s for skin images on my local wiki [13:19:48] It seems to be treating the path as an URL, which doesn't work, because it becomes e.g. https://pedia/resources/src/mediawiki.ui/components/images/checkbox-checked.svg [16:09:18] I am trying to use maintenance/fetchText.php to get the text of an old revision [16:09:53] however I get random results when I provide an old id or address [16:10:42] the manual says it should work: https://www.mediawiki.org/wiki/Manual:Text_table "The fetchText.php maintenance script can be used to retrieve the text of a given old_id" [16:13:19] but when I run echo "172894097" | /usr/local/bin/mwscript maintenance/fetchText.php --wiki frwiki [16:14:06] expecting https://fr.wikipedia.org/w/index.php?action=raw&oldid=172894097 [16:14:10] I get something else [16:20:54] and if I use a blob address it founds nothing [16:27:21] so oldid to index.php... is "The id of a revision" [16:27:58] passing a number to the script, will result in it trying to find a blob called tt:172894097 [16:28:32] called/at that address [16:29:08] if we look at `select * from text where text.old_id = 172894097;` [16:29:15] old_text is DB://cluster27/202621 [16:30:04] I guess the script should probably use the DB to resolve the blob, but it doesn't... for whatever reason [16:30:21] oh, that is confusing [16:30:45] I can workaround that if I can find a way to translate an old_id to a revision id [16:31:01] but looking at the tables, it takes a lot because there are no indexes in that direction [16:31:14] CREATE TABLE /*_*/text ( [16:31:14] -- Unique text storage key number. [16:31:14] -- Note that the 'oldid' parameter used in URLs does *not* [16:31:14] -- refer to this number anymore, but to rev_id. [16:31:15] heh [16:31:17] but mediawiki must be able to do it, because I get it instantly [16:31:45] yay, unintuitive parameter names! [16:31:53] and renamed/reused... :D [16:31:53] ok, I am getting lost [16:32:01] so oldid in urls is rev_id? [16:32:19] https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#Page_revision_or_version [16:32:22] yes [16:32:30] ok, that fixes it for me I think [16:32:49] however, the script may need some patches for documentation [16:32:55] I may take care of that [16:33:21] * AntiComposite wonders when we'll ever rename those url parameters [16:33:29] however, I just realized I was doing it right [16:33:36] but still get bad results [16:33:52] actually not, it just just that fetchText is useless to me [16:34:08] is there a "fetchRevisionText"? [16:34:35] I guess I can query the db and get it myself [16:34:46] maintenance script? I think not. There's getText, but that's current/newest revision [16:35:01] The API would probably be able to provide it too [16:35:01] last night I described an issue which may be in your scrollback, re: automatic deletion of files from enwiki after importing them to Commons; I've just tested it, and it's still an issue [16:35:14] "The file could not be deleted automatically on en.wikipedia.org. Please return to the original file and delete it manually." [16:35:31] Reedy: sadly I cannot use the API for this [16:35:38] at least not the public api [16:38:31] 7 [16:38:38] * jbond42 ignore wrong window [16:38:51] depending on how much I am bitten by this I may send a fetchText update :-) [16:39:25] Reedy: thanks, confirmed this worked [16:39:39] :) [16:40:01] I did "select content_address FROM slots JOIN content ON content_id = slot_content_id WHERE slot_revision_id = 175702850", probably there is a function that does the same, but this works for me :-D [16:40:12] haha [16:40:23] yeah, you can almost certainly do it via eval.php... but yeah, you're a DBA... SQL is probably easier ;) [16:40:32] yep [16:41:07] it may actually be useful for more complex retrievals [16:41:50] It shouldn't take too much to write a maintenance script to do this too, so might be worth at least filing a task if you don't want to write it [16:41:59] yes, that was my plan [16:42:26] write it, I mean, I don't want to add more unnecesary backlog to others [16:43:37] Dragonfly6-7 sorry we ignored you- I would suggest searching that string on phabricator, and if you don't find other reports, write one yourself [16:44:22] although it it shows you a nice warning, it may be on purpose (unsure)? [16:45:24] jynus - oh, I assume you were asleep when I mentioned it last night, that's okay. As for using phabricator, that would involve climbing a new skill ladder that I really don't have time for [16:45:53] basically, I wanted to make sure that the relevant people were informed [16:45:58] er [16:46:01] * Dragonfly6-7 shakes head [16:46:03] 'skill ladder' [16:46:26] not sure that's the phrase I want, but you get the idea [16:46:38] sadly, I don't know much about commons uploads and how that is handled :-( [16:48:02] Reedy: I need to up my game so using mw php is faster than bash + sql :-/ [16:48:12] haha [16:49:48] I wouldn't necessarily worry about adding to others backlogs. don't ask don't get... And you don't necessarily need to put it on a teams workboard for that reason if it's not blocking you [16:50:03] it's the sort of thing one of a handful of other volunteers would likely take up [18:36:45] I know Composer support isn't meant to be a topic here but I wonder when running for example 'composer update mediawiki/some-extension --no-dev -o' the process just gets Killed? This happens when running composer 1.10.17, while if I use composer 2.0.7, I get the error: "Cannot update only a partial set of packages without a lock file present." These errors happen whether I'm logged in as... [18:36:46] ...root or any user. [18:37:26] composer 2.0 isn't supported by mediawiki, so what it does or doesn't do is irrelevant [18:39:28] Okay. Got it. [18:42:25] if the process is getting "killed", it sounds like something to do with your server.. [18:42:33] https://stackoverflow.com/questions/20667761/composer-killed-while-updating [18:46:54] Yes, probably. It's only broken on the server where I have MediaWiki. I managed to package the Maps version 5-6.0 extension on my localhost with Composer 1.10.17 and send the resulting files up in the extensions folder on my MW 1.27.1 (which Maps version 5.6.0 should work with). [18:47:34] Thanks for the StackOverflow info. I will check. [18:48:44] Only problem Maps won't work because I get these errors: [18:49:33] Warning: Unsupported declare 'strict_types' in /usr/home/wiki/extensions/Maps/vendor/param-processor/param-processor/src/ParameterTypes.php on line 3 [18:49:34] Parse error: syntax error, unexpected 'const' (T_CONST), expecting variable (T_VARIABLE) in /usr/home/wiki/extensions/Maps/vendor/param-processor/param-processor/src/ParameterTypes.php on line 26 [18:50:37] Yet, Validator, which uses ParamProcessor should be compatible with my MW 1.27.1. [18:52:59] You'd have to look at the syntax itself and see [18:53:05] it's possible it doesn't support your PHP version though [19:04:20] Yes, maybe. Thanks for the feedback. [19:06:03] If you're running a different PHP version on your local and remote, that might happen [19:06:12] Or the supported versions in the libraries are wrong [19:33:30] I realise I have been trying to install a too new version of Maps for my PHP 5.6 on the server. [19:35:19] that'd probably explain it [19:40:43] I wanted to use Kartographer, which I installed, but realised map data is not available outside MediaWiki's projects, WikiPedia, Vokovoyage. [19:43:05] You just need to find another tileserver, there are some available [19:43:33] Zebu: https://wiki.openstreetmap.org/wiki/Tile_servers [19:49:35] Thanks, as mentioned, I managed to install Kartographer and it appears to work without error. I just haven't been able to find out how to enable the tile servers in relation to my installation so-far. I think I would prefer Kartographer since it appears less reliant on Google's services which can change at anytime. [19:54:37] why should we have documentation for $wgKartographerMapServer [20:09:20] I did not know that was all that was needed :-)