[14:06:54] Omega, you around? [14:11:05] Blackwolfe, something I can help with? [14:11:45] No, just wanted to check in with Omega about the dpl3 issue on phab, that was apparently connected to the upstream extension or something. [14:11:52] Since omega is maintaining dpl3 [14:12:10] Unless you have any info on the subject [14:12:12] Blackwolfe, oh, yeah. Sure, no problem. I know he's been working on DPL stuff lately yeah [14:12:17] heh nope [14:12:40] Universal_Omega, can you give Blackwolfe a status update on the ^ when you get a chance? [14:13:22] I made a ticket on his dpl3 github page as well. Our wiki relies very much on dpl3, so all dpl tables suddenly being empty was quite the shock 😛 [14:27:30] oh [14:28:04] Yeah, pretty bad 😛 [14:29:18] At least I put a top notice about it on https://idleon.info/ but ofc, people don't read things on the internet so people ask about it on the idleon discord. [14:29:19] [ Legends of Idleon Wiki ] - idleon.info [14:41:25] @dmehus, working on it at this very moment. @Blackwolfe, if you want, you can create an issue on the github for the extension and I'll definitely fix it *today*. Thanks! [14:42:08] I did, but not getting any error messages or anything like that so it is not very detailed. [14:42:33] Only knew about the upstream thing because I found the phab ticket you closed. [14:43:01] Shame you left, but. eh.. it is what it is. [14:43:11] At least there is the relay. [14:43:15] Hmm. Interesting. Looking today. Can you explain the error a little bit @Blackwolfe? [14:43:38] It's basically.. all dpl tables are empty [14:44:05] Every single dpl table on the entire wiki. [14:44:52] (I dunno what the upstream thing does but I assume it is responsible somehow?) [14:44:56] @blackwolfe. Hmm. DPL doesn't have any tables of its own. Oh... I know what happened. Give me a moment. It's not a bug. It's something I did yesterday. [14:45:04] Ah [14:45:53] Whoops. I did a config change in LocalSettings.php but I forgot the way the setting was unset all other configurations in the extension, causing what you now see. [14:46:06] Well no tables of its own, but it does populate the tables (and some other stuff) on our wiki. [14:46:28] It pulls from other tables and in the more advanced features modifes them yes. [14:46:59] So, tables using dpl 😛 [14:47:46] DPL using core tables is more accurate. Anyways, let me go and fix this now. [14:48:04] More like "causing what I don't see", hehe. Thanks! [14:49:23] I did look in managewiki but I suppose those things can't be changed normally on miraheze. [14:50:01] @Blackwolfe reopen that phabricator task I closed yesterday if you want. It is a valid task and a wrongful close [14:50:21] So, not invalid after all? [14:50:38] Nope [14:50:45] It was a Miraheze issue [14:51:21] lemme see if I can find it again. [14:53:13] bleh, got no phab account, sec [14:57:28] There [14:57:34] @Blackwolfe https://github.com/miraheze/mw-config/pull/3723 should fix. [14:57:34] [ Fix DynamicPageList3 by Universal-Omega · Pull Request #3723 · miraheze/mw-config · GitHub ] - github.com [14:58:31] So, just wait for Miraheze to update the extension then? [14:59:11] No just wait a few minutes and see if it fixes. Once I merge that. [14:59:16] Ah, cool. [14:59:47] ❤️ [14:59:59] Can't wait to see it working properly again [15:01:29] Yeah sorry about that. Should update within 2 minutes. If it still doesn't work then, let me know please. [15:01:48] Of course. 🙂 Thanks! [15:03:43] Borks happen inevitably at one point or another. [15:04:06] It works! ❤️ [15:04:20] Great! [15:04:34] Thanks so much! [15:07:13] No problem! Again, sorry for the mistake. [15:08:33] Eh, it happens. I'm no coder but I know enough to know that even the simplest of changes can produce unwanted results. [15:13:19] Yeah. I'll update the whole config format of DPL3 probably. I don't like the way it is now. I accidentally unset all configs, and am really surprised it didn't give you errors also. [15:13:57] It apparently gave the other person in the phab ticket errors at least. [15:14:53] Yeah, checking the pages they mentioned doesn't seem to anymore though. Which is why I was surprised you didn't get errors. [15:15:55] Did they use or {{#dpl: ? [15:16:10] I mean, it shouldn't really matter. [15:16:34] That wouldn't matter, no. It's probably the functions of DPL they were using. [15:16:45] Quite possibly. [15:17:32] Ah, great. Glad you got it resolved. [15:29:29] Hi dmehus , check your DMs with me [15:35:57] !ops Can you please delete "frwiki"? It pretty surprisingly got created when the subdomain was "wikiwars" and the language was "fr" in a wiki request that I approved. [15:36:56] R4356th: req number? [15:37:14] 16673 [15:38:15] Universal_Omega: ^ why that happen? [15:38:23] but Reception123 can probably drop [15:39:03] RhinosF1: no idea. [15:39:08] JohnLewis: any ideas why that would happen? [15:42:16] Universal_Omega: I see PHP Undefined Offset twice in logs on that request [15:43:27] Universal_Omega: then I see a bunch of connection errors to db11 [15:44:02] By the way, the wiki had "fr.wikiwars.com" as the subdomain at the first place but the requester changed that later. [15:44:09] *wiki request [15:48:26] We could just delete `frwiki` on-wiki and it'll drop when we next run the wiki deletion script [15:48:48] dmehus: it doesn't make sense why it was created [15:49:06] Weird [15:49:11] ^ which is why I requested this here [15:49:30] JohnLewis: why does managewiki not log changes to wiki requests? [15:49:36] well createwiki [15:49:40] Looks like someone hit approve instead of adding a comment [15:50:04] Which comment are you referring to, dmehus? [15:50:16] dmehus: R4356th is saying it created using the old dbname when it had been changed [15:51:13] If it was created accidentally before subdomain was changed, then yes, the wiki request can be reapproved and created on the new subdomain [15:51:26] what's the wiki that was approved and created the second time? [15:51:29] wikiwars? [15:51:34] Regarding logging changes to wiki requests, back in June when I joined MH, updates to requests were logged but it was removed later. [15:51:40] dmehus: yes. [15:52:10] But the problem is that it was created with a wrong DB name. [15:53:19] R4356th, that was changed when we started logging approvals and declines. Before we logged only updates to wiki requests but not declines. Now we log approvals and declines. Could log updates as well, but might be a bit overkill [15:53:58] Yeah, still, it's not a bug. It was created accidentally by you clicking approve with `Comment given by R4356th at 07:23, 16 February 2021` that action. When the subdomain was changed, it was created a second time [15:55:20] That made zero sense. Have you read my comments on the req? [15:57:19] dmehus: R4356th is saying the subdomain was changed when they created it the first time [16:00:47] RhinosF1, the comments show the request was approved as `frwiki`, though. It's possible R4356th inadvertently hit approve before the subdomain was changed, instead of adding a comment? [16:02:07] Personally, I think we should disallow entering custom domains in the wiki request, though. [16:02:36] dmehus: we did [16:02:41] No, I noticed that it was changed to "warwiki" after submitting that comment. [16:03:16] Create a blank field for the subdomain and have ".miraheze.org" appear to the right of the box in plain text, so a user cannot accidentally enter non-miraheze subdomains/custom domains [16:03:40] RhinosF1, we may have, but with the CW revamp, I have seen non-miraheze subdomains in RequestWiki that I've had to fix [16:03:47] RhinosF1: Um, no... The request had a custom domain at the first place. [16:03:58] ^ yeah [16:05:11] There's likely a bug here that needs to be resolved, and I wonder if the reason it was approved was because CreateWiki created it with the part before the first period (being `fr`) in the custom domain? [16:06:24] That's my guess but does CW cache stuff? [16:06:39] Not sure, probably? I know ManageWiki does [16:06:49] CreateWiki does subdomain splicing to get dbname, and it seems that it doesn't check if it's on a miraheze.org subdomain. So that can be fixed probably. [16:07:51] Yeah, that's what it seems like, Universal_Omega. I think we should make it a field that disallows all non-alphanumeric characters and have ".miraheze.org" appear in a non-editable field / text area to the right of the editable subdomain field / area [16:08:14] Not a bad idea. [16:08:26] Ah but that does not tell us why it chose "fr" instead of "warwiki", however. [16:09:14] True, we don't have a definitive answer for that, yeah, though our speculation that it ignored all text after the first punctuation mark seems reasonable? [16:09:49] (y) [16:09:56] Anyway, I've deleted `frwiki` so it'll get dropped the next time we run the wiki deletion script after this month (currently scheduled to be run in the next few days by Reception123) [16:09:59] Because fr was the subdomain? If they used fr.wikiwars.com it doesn't know wikiwars.com isn't miraheze.org, and gets confused, so it takes the fr portion of it. [16:10:14] yeah, that's what I was thinking [16:10:21] maybe I didn't explain it that well [16:10:37] Hi dmehus - please read my Dms [16:10:52] BurningPrincess1, I'm kind of busy. Is it urgent? [16:10:58] No [16:11:07] Ping me hwne you have time [16:11:11] oh ok, will reply later today, not to worry :) [16:11:14] will do [16:11:16] :_) [16:11:37] Universal_Omega, but the requester changed the subdomain before I approved the request. [16:12:22] Unless they didn't actually change it in time, or they thought they changed it [16:12:33] Link to request? [16:13:40] It's possible that because of how they used the custom domain at first, that because the new subdomain just included past domain, that CW didn't detect a change and safe their update to subdomain. [16:13:42] https://meta.miraheze.org/wiki/Special:RequestWikiQueue/16673 [16:13:47] [ Wiki requests queue - Miraheze Meta ] - meta.miraheze.org [16:13:57] *save [16:14:50] Also, remember if the requestor adds a comment at the same time as changing their subdomain, only the comment will be added and the change ignored [16:15:01] You have to update request first, then add a comment [16:15:19] Also from the time you asked them to update it, to the time you said it was updated, there was no comment saying request updated, so it seems it wasn't? [16:17:15] And yeah, request was definitely approved twice. There are 2 comments saying it was. [16:18:55] When I started writing my review, the request updated comment was not there. I noticed it after I posted my comment (which took some time as I was doing something IRL in the midst). [16:19:34] Regarding your ( Universal_Omega 's) second comment, yeah, two comments were posted... [16:21:18] Yeah you must've accidentally approved it twice? Which would explain why that happened. [16:21:21] Yeah, there were a lot of updates / comments from the requestor and wiki creator, so it's really hard to say with certainty. It's quite possible it was a requestor/wiki creator conflict, and possibly there was some caching involved [16:23:03] Well, I can at least say it clicked the approve button only once. *shrugs* [16:23:10] *I clicked [21:22:54] Note: Upstream metrics indicate higher than average latency on requests to mediawiki app servers due to php issues. There may be impact on loading resources from wikimedia sites. Miraheze hosted content will still work. [21:25:44] dmehus: might affect some of the user scripts that you load from wikimedia sites [21:54:51] Note: The situation should be stable but please let us know if things are sluggish and from Wikipedia [21:54:57] Wikimedia*