[03:53:57] Hi. [03:54:22] I was looking at [[Extension:UrlShortener#API]] [03:54:44] As I understand, it should be a POST request. [03:55:38] I was trying it out on a REST client, and I got a warning which said: A POST request was made without a \"Content-Type\" header. [03:56:39] In the API parameter, I specified the format to be JSON -- so should it still be expecting a content type? [08:44:51] Hey, is it possible to get a dump that would include links between wikipedia pages (hyperlinks) and also which wikipedia pages redirect to which pages. I wouldnt want to download the whole database to get these :) [08:54:34] Hello everyone. Who can help with creating links to translated pages in the sidebar? [11:46:51] hola, I wrongly created an account on mediawiki.org. I know it is not intended to be done but can this account be deleted by anyone? It's a fresh empty account which is not going to be used is future. [11:49:49] seb_hasAQuestion: It can't be deleted. Best you can do is remove the email (if any) and set a random strong password, and forget about it [11:50:19] If the user name contains private information, maybe we can hide it from account creation logs [11:54:43] That would be very kind. [12:12:22] Krinkle: What was the fix for https://phabricator.wikimedia.org/T210449 ? We're updating ShoutWiki to REL1_34 (core + GlobalPrefs) and we've now run into the issue. [13:05:53] Lcawte: Seemingly it stopped appearing [13:06:36] That's... nice - for the WMF. [13:06:49] Well, if we can't replicate it... It's hard to fix it [13:07:19] paladox hasn't reopened it to say it's still happening for them either [13:09:37] Lcawte: Reopen if it's still an issue for you [13:10:58] We haven't had that issue reappear yet, i think that was fixed. [13:11:44] Lcawte: see https://phabricator.wikimedia.org/T238466 [13:12:18] Lcawte: it happened in CI on patches that cause MW to initialize too early while it is itself mid initialization [13:12:38] So my guess is you have an extension that is registering an early hook doing the same [13:12:58] Well, we were getting the issue vs 1.34.1 and GlobalPrefs REL1_34. We've now turned the extension off (temporarily) [13:13:08] Anyway, the underlying issue is real and is being fixed in master [13:13:50] Yeah it would be good to look through your stack trace and rule out a genuine bug [13:14:19] But if not then you'll have to wait or help with the fix in master as it never worked right in that scenario afaik [13:14:36] If it worked in earlier versions I suspect the trigger is in another extension. [13:15:32] Whats the new ETA on REL1_35? [13:15:46] Peace on earth ? [13:15:52] Was it June or something? [13:16:35] * Krinkle doesn't know [13:17:43] I thought June was the original ETA [13:55:35] So if we ran migrateActors.php in 1.32, why is update.php trying to run them again in REL1_34? [13:56:18] You ran the script manually? [13:56:43] That also happened to me. I think that was because I ran it with --force [13:56:45] migrateActors? Yeah... so update.php wouldn't run them. [13:56:54] What did you run with force? [13:57:02] migrateActors.php [13:58:13] Hmm [13:58:15] A quick look suggests if there was any errors, it won't have put an update_log row in place [13:58:20] So it would run it again [13:58:25] updatelog [13:59:05] So it'll keep running until all the errors have been dealt with? [13:59:58] It'll keep running until there's a row in updatelog to tell it not to run [14:00:38] Of course, you shouldn't need to keep running update.php anyway [14:01:04] About 1.35, there was this announcement https://lists.wikimedia.org/pipermail/wikitech-l/2020-March/093248.html [14:01:20] how it is vs. how it should be are often two separate things :P [14:02:41] ashley: We never run update.php in WMF prod [14:02:45] And we don't have any issues [14:02:46] * Reedy coughs [14:03:03] We've got 13k wikis and 30635678 users (damn spambots) [14:06:07] Reedy: so why are we telling people to run update.php, then?! ;) [14:06:24] because your wiki will break [14:13:42] In fact, in one of my wikis apparently I had to run migrateActors.php twice to get it to update_log, while others didn't have to. Maybe there was some error there that the second run fixed itself [14:15:04] So it seems there were some wikis in 13k that did have some errors... not surprising, but, some finished cleanly... which means update.php isn't going to take three weeks or something to run through. [17:38:11] Reedy Question, if a wiki is running 1.34, they do not need to run the migrateActor script right? (e.g if a new wiki is installed under 1.34) [17:38:36] In theory not, depends on the config [17:38:49] thanks! [17:39:54] apparently wgActorTableSchemaMigrationStage was removed in 1.34, so i guess actor is the default now [17:40:53] Aha, yeah [17:41:00] That sounds like the config I was thinking about [17:41:21] My thought being if it was set to something other than default in a shared config, a 1.34 wiki could potentially need migration [18:21:09] Hello there. I just tried to access my wiki and got an error page about setting $wgServer.in local settings? [18:23:17] What's the error? [18:23:33] "$wgServer must be set in LocalSettings.php. See https://www.mediawiki.org/wiki/Manual:$wgServer. " [18:23:46] I looked at that page, but I'm afraid I'm a bit of a neophyte, so I'm not clear on what to do next [18:24:22] Is your wiki public? What's the url? (makes it easier to tell you what to put in it) [18:24:46] http://adventure.shoutwiki.com/wiki/Main_Page There's the link to it [18:25:05] I imagine you can't set that yourself then... [18:25:07] Lcawte: ^ [18:26:05] Hmm, okay. Two secs. I thought we caught all of those. [18:26:06] Is it an internal error on Mediawiki's side, then? [18:26:25] Not meaning to blame, just understanding [18:27:18] Uhhh, more, the wiki being before CreateWiki actually started writing $wgServer out (a while back), there was about 1000 of them. 1.34 seems to demand you have it set (which it never used to) [18:27:42] Lcawte: RTFM? :P [18:27:43] >MediaWiki formerly tried to autodetect the name of the server, however this was vulnerable to cache poisoning attacks, and informally deprecated in 1.18. It was fully removed in MediaWiki 1.34. [18:28:11] Talyn: No, it's ShoutWiki technically not reading the docs and updating their config accordingly ;) [18:28:18] *nods* Well, is there anything I need to do, or is this some adjustment on your end? [18:28:30] uhhh... its fixed, and has been for an hour or so? [18:28:31] I was able to access it earlier this week, even. [18:28:48] Um, still can't. Just tried. [18:28:52] Hard refresh, too. [18:28:58] Talyn: We've had a global notice up (on the top of every page) warning you we were going to break stuff today... [18:29:05] Oh, hey, new error screen. [18:29:13] 503 service unavailable now. [18:29:26] Alright, so should just be an outage and should be back up again later? [18:29:45] *also global notice doesn't help when I can't actually get to my wiki to see the global notice* :P [18:30:58] Talyn: Yep, updates are on our social media channels. [18:31:20] The GlobalNotice has been up all week, fyi. [18:32:18] Hm. Well, if it's just an outage, that's fine, appreciate the notice. Sorry to bother, then. Any current ETA on completion? [18:32:49] You're near the start of the alphabet, so you'll be readable again soon. [18:33:01] Yay A [18:33:20] *makes up for all those years where he was always in the middle for having a 'L' last name* [18:33:48] Anyway, my smartassness aside, thanks. Will leave you to work, then! [18:36:15] Reedy: Sorry, my default position is expect there to be an incomplete/out of date manual from a WMF change ;) [18:38:32] https://github.com/wikimedia/mediawiki/blob/REL1_34/RELEASE-NOTES-1.34#L88-L91 [18:38:48] I suspect it should've been called out in https://github.com/wikimedia/mediawiki/blob/REL1_34/RELEASE-NOTES-1.34#L118 [18:41:55] Yes, okay, I missed it. I also forgot we had a group of legacy from years ago (1013/13334) [18:42:16] They don't normally ask for all the bells and whistles so I don't need to go into their settings and spot these things. [18:42:37] :) [18:42:39] Shit happens [18:43:36] I'm also guilty of not reading release candidate notes... :/ [19:46:41] Hey all, I have an issue with the nginx configuration I'm testing. Most everything seems to work with my test configuration except one thing, going to wiki.example.com (i.e. base server name with no file/path) doesn't redirect to /wiki/Main_Page (or the language equivalent), but going directly to that page or any other is working fine. [19:47:10] Here's a gist that shows two example wiki server configs and the snippet they include. https://gist.github.com/justinclloyd/2642e36408101807571b8d9044bbda4e [19:50:07] FWIW this is my first real attempt at configuring nginx for my wikis, and while I've worked with nginx in the past to varying degrees, this is by far the most time I've spent learning it and planning to delve much more into it as I migrate away from apache (we use nginx heavily elsewhere as well so it's good I'm finally really digging into it). [19:52:21] # Explicit access to the root website, redirect to main page (adapt as needed) [19:52:22] location = / { [19:52:22] return 301 /wiki/Main_Page; [19:52:22] } [19:52:59] That didn't work [19:53:34] which is why it was commented out but left in to show I'd tried it [19:54:11] Can't really glean that though [19:54:22] It outwardly looks like it doesn't work because it's commented out :P [19:54:47] ah sorry, I should have added a comment to that effect, sorry for the confusion [19:55:23] updated the gist to reflect that [19:59:17] update.php says, User name "President" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation. [19:59:28] Is there a way to create an anonymous actor for a user name through the site? Neither cleanupUsersWithNoId or migrateActors is doing anything for me (trying to upgrade to 1.33) [20:10:04] Completed migration, updated 0 row(s) with 0 new actor(s), 157 error(s) [20:17:18] seanc: The only way a "user name" can be anonymous, is if the user is actually external (imported). In theory you should specify a prefix when running cleanupUsersWithNoId.php to mark them as external [20:17:54] How does one do that? [20:21:54] I have just 13 users [20:23:50] Upgrading from 1.30 to 1.33 caused about 217 (out of 525 total) pages to lose their content. [20:24:18] "There is currently no text in this page. " [20:44:15] Update log indicates the trouble is happening in tables 'revision.rev_user and revision.rev_user_text', 'archive.ar_user and archive.ar_user_text', 'image.img_user and image.img_user_text', 'oldimage.oi_user and oldimage.oi_user_text', and 'logging.log_user and logging.log_user_text'. [20:46:01] seanc: did you run update.php? [20:46:27] Yes, that's the log info I'm referring to. [20:46:55] What trouble? [20:46:57] It complains about anonymous actors in all of the above listed tables. [20:47:47] This wiki has no anonymous users. Not sure if that's the same thing. [20:48:09] Did you ever import pages from another wiki? [20:48:44] Or do you use some extension that does weird things with users, like Extension:UserMerge? [20:48:54] Well, this wiki has only been my problem for less than a year, but not in that time. [20:49:18] running | php maintenance/cleanupUsersWithNoId.php --help | gives this option: | --prefix (-p): Interwiki prefix to apply to the usernames | [20:56:59] But how does one determine the prefix to apply to the usernames? [20:57:12] Is any arbitrary string ok? [20:57:43] Or will I find it in a database table somewhere? [20:59:12] you determine it. Put what you want in it. The "users" that have no user id, will have this prefix in contributions, logs, etc. [20:59:30] Instead of "User" it will display as "prefix>User" [20:59:35] ah [20:59:47] if prefix is a valid interwiki, it will link to that wiki [21:00:36] For example, if you set prefix to wikipedia, and wikipedia: is a valid interwiki, they'll be displayed as "wikipedia>User" and they'll link to their Wikipedia userpage [21:01:11] Interesting. Not needed in this case, but interesting. [21:01:12] Otherwise, they'll have no link to userpage, will be displayed as plain text in Special:Contributions and similar [21:01:36] I'm pretty sure none of the 13 users have a user page right now. [21:01:47] If you don't know where those buggy users came from, try something generic as a prefix, like "invalid", "imported" or similar [21:03:26] Completed cleanup, assigned 0 and prefixed 0 row(s) [21:04:48] No change [21:05:00] I wonder if I'm barking up the wrong tree... [21:06:06] I ran php cleanupUsersWithNoId.php --prefix=XXX --force [21:06:27] Then php migrateActors.php [21:06:38] Then ./update.php [21:06:46] Same same [21:07:23] did you get any errors running those, or the only problem is text has disappeared? [21:08:03] I see the "cannot create an anonymous actor" errors in the output of update.php [21:08:21] Where else can I look for errors? [21:09:32] do you get a stack trace of the error? [21:09:47] Where can I find a stack trace? [21:10:38] Can you post the output of the command on https://dpaste.de/ ? [21:15:36] :Vulpix https://dpaste.org/WGG6 [21:18:06] I think 1.33 may have some bugs in the cleanup script fixed in 1.34 [21:20:25] Or maybe not, at least not looking at the latest commits [21:21:00] I can paste the output 1.34, but it looks just like 1.33 [21:21:30] Aha https://phabricator.wikimedia.org/T224854 [21:23:03] yep, saw that [21:23:28] Looks like you'll have to do manual database intervention for those users [21:23:29] Hadn't quite figured out how to make sense of it [21:24:34] The script cleanupUsersWithNoId.php fixes users on tables where there's a valid user_name (not an IP) but user_id = 0 [21:25:09] but doesn't handle rows with non-zero values [21:25:26] however, in your database, there are users with valid user_name and user_id > 0 but that user_id doesn't exist in the user table, (or maybe it corresponds to a different user name?) [21:25:36] exactly [21:25:46] That needs manual intervention [21:26:03] UPDATE revision SET rev_user = 0 WHERE rev_user IN (?????, ?????); [21:26:24] I just need to figure out the rev_user numbers for my case, right? [21:26:33] So, for example, the user "Willkrantz", exists in the user table? [21:28:44] yes [21:28:47] Hmm... [21:28:52] it appears he does not [21:29:43] SELECT user_name FROM user WHERE user_name = "Willkrantz"; [21:29:45] Empty set (0.00 sec) [21:30:04] I counted 13 users, but only 4 names are in that table. [22:11:27] I have a generic PHP question and was stuck on a project..not sure where/ whom I could ask, and hence I'm asking here [22:11:39] I wanna make a PHP call from my MW [22:12:21] So, I wanna autologin users to a different part of my site. That auto login is done by going to forums.xyz.com/login [22:12:24] in my MW [22:12:46] I wanna hook to UserLoginComplete that can basically call forums.xyz.com/login [22:12:56] and then that page will handle the autologin stuff [22:13:42] If that is not possible..basically what going to forums.xyz.com/login does is redirect to MW's UserLogin with some parameters. How do I get those parameters from my hook function? [22:20:07] Anyone here who can help me out? [22:46:10] phpUrlHelpGuest9: all url parameters are available via methods on the WebRequest object; MediaWikiServes::getInstance()->getRequest() to get it [22:46:39] That being said, note the limitations on the hook's documentation page, you may wish to consider writing an AuthManager plugin instead (although those are significantly more complicated) [22:59:24] Thanks Skizzerz