[03:27:19] doesn't it mainly affect very-new OS versions? while most servers run something that is intentionally a little older? [04:07:47] <.labster, replying to serverlessharej> Yes, new OS versions only. I was surprised to see Wikibase on the list of servers affected though. [08:41:48] <.labster> [1/2] ```> php -r 'echo in_array(-1, ["foo" => true]);' [08:41:48] <.labster> [2/2] 1``` [08:44:18] <.labster> [1/2] ```> php -r 'echo in_array("saddams WMDs", ["Iraq" => true]);' [08:44:18] <.labster> [2/2] 1``` [08:44:53] <.labster> Okay, this language is officially crazy. [10:39:11] That is the case [12:40:52] Its because the keys are converted to integers [12:41:18] You should use "array_key_exists" rather than in_array where the keys are non integers [12:42:22] I don’t get it [12:44:03] So basically [12:46:04] [1/2] "Saddams WMDs" is converted to an integer, which is 0 in this case. [12:46:05] [2/2] The in array function is therefore asking "does a key at position 0 exist in this array" (it doesn't care what the key is, just that it does). Since arrays start at 0 in php there is a key at position 0 (which is Iraq) so regardless of whether the strings match (because they are both typecast to integers), the result is true. [12:52:55] (This behaviour only happens with key => value arrays which is weird [16:52:05] @bluemoon0332 when you've got time I've updated the PR [17:38:37] Nice, LGTM [17:39:58] well, almost [17:40:04] spotted a small mistake with the logs [18:51:16] @bluemoon0332 fixed. also, are you sure https://github.com/miraheze/CreateWiki/pull/500/files#diff-eae0ed68e7a72ff2942f1c6f3cf7bf4cfef53572c68194794b12fc48d0eb7b48R145 is right? that's the thing I was most uncertain about as I tend to make some mistakes with OR logic [18:51:34] otherwise if it's good to go after the log fix we should test it with one of us creating a wiki request so we can see if notifs work [18:59:51] Looks like your passing the type as comment instead of moredetails so that does nothing and the moredetails notification wont ever be used [18:59:55] L253 [19:04:54] oh I see right, I copied from onhold but on hold doesn't have a custom notification [19:04:55] fixing now [19:04:59] does it look good otherwise? [19:07:53] One more thing, the icon, request-moredetails doesn't exist [19:08:20] Choose a different one or add a new one I guess [19:08:57] https://github.com/miraheze/CreateWiki/blob/e37033e67321b02a114dbbc537c2610209e77aed/includes/Notifications/EchoRequestMoreDetailsPresentationModel.php#L11 [19:11:35] I suggest using either 'global' or 'chat' [19:11:57] sure! heh, there's so many small things like that that can be missed [19:12:22] yup [19:13:39] Which reminds me does anyone here have a good understanding of the ManageWiki form (factory).. flow? I think thats the term. Have a question for curiosity sake mainly since I doubt ill be making a patch anytime soon [19:14:10] ..feel like I shouldn’t ask to ask [19:14:37] Think the support bloke would have thought of that anyways um let me find the file [19:15:08] I wrote a lot of the more modern version of it so yeah. Its not the best code for sure... I made an effort to rewrite and cleanup but eventually felt futile, so my new stuff ended up the same poor code lol [19:15:54] I was mentally making a idea for a patch a while ago [19:15:57] forgor the T num [19:16:23] it was to send a confirmation are you fucking sure warning when removing any managewiki-* rights from a group [19:18:19] [1/2] beyond knowing fucking php the two blockers in my head were how to raise a warning and cancle the whole operation and send an alert to the UI from the part of the code that handles right changes that I cant find rn in a restaurant and how to include a confirmation check to be read but only show up when that alert shows up. If that makes sense. If not fair and ill try my to clarify ho [19:18:20] [2/2] pefully [19:19:14] I added the basic support for that years ago when I added the preview dialog, and the confirmation to close window with unsaved changes stuff. I just never finished that part but its a good idea lkl [19:22:14] Ooo may br able to use that [19:22:25] i need to learn extensions first obvi but uh all in due time [19:22:56] did start learning the night before i left for spring break and am gonna get back soo lets see [19:23:36] https://github.com/miraheze/ManageWiki/blob/master/modules/ext.managewiki.oouiform.reviewChanges.js is what I planned to use something extremely similar to that to check if the changes and then show the confirm similar to https://github.com/miraheze/ManageWiki/blob/master/modules/ext.managewiki.oouiform.confirmClose.js [19:24:18] I wrote those yesrs ago but forgot the final part lol [19:24:51] I would like managewiki to eventually not depend on ManageWikiExtensions.php eventually and I have an idea of how to do that to some degree [19:25:11] this is going to be a radioactive mess that will make any mediawiki dev cry into their soup 👍 [19:25:14] But agreed that the code for managewiki is erm....think of a word [19:25:52] will check it out once I find a few more spare brain cells😄 [19:26:44] You mean the config version or the Helper insifr ManageWiki? [19:27:05] Oh the github version [19:27:52] Like being able to add extensions that can be enabled on wikis from Meta [19:28:57] You actually don't need to know PHP to do it either, it can be done entirely in JS, then just adding the module in extension.json to ext.managewiki.oouiform basically. I don't like relying on JS to much but for things like this using JS is usually a bit better... [19:29:33] well the logic of “are they removing a manage wiki group” [19:29:45] well that coooould be JS maybe [19:30:13] not much better as JS… but i have a phd in bullshit sp [19:30:28] _still doesn't know how to use JS with OOUI._ [19:30:51] But i like to just do it all in php anyway so 😛 [19:30:57] [1/2] This could be a security risk. It would provide less of a confirmation or approval to add extensions before they undergo full security review if I am understanding correctly, its not a horrible idea just depends how it works. Because you could also cause issues if you add new extensions before in mediawiki-repos, mwdeploy --extension-list snd the ex [19:30:57] [2/2] tension itself... so it is a bit tricky. [19:31:43] JS OOUI has more features than PHP, seeing the PHP OOUI is just a wrapper ontop of JS basically. Even PHP won't fully work if JS is disabled. [19:32:21] It could be yeah. [19:32:44] checking the checkboxes [19:33:12] then a sort of pre on click before php gets to wrok [19:33:35] should probably get my own extension idea first t get the hang of it [19:33:45] [1/3] How so? My idea is envisioned as such: theres a page on Meta that lists all the extensions available for enabling. SRE can add an extension, and must input the extension name, folder, etc. [19:33:45] [2/3] The form would do two checks: if the extension folder actually exists in /extensions, and if present in extension-list.json. if so, it can be added. [19:33:45] [3/3] In my head its basically the same as the current process, no? But on Meta instead of on GitHub. [19:34:15] need to figure out how to do color picker special pages(easy maybe with js) and to apply css globally (pre load hook?6 [19:34:57] onBeforePageDisplay is your best bet for JS loaded before the page load. [19:35:28] resource loader will handle that for the most part, if you use packageFiles its even better. [19:37:17] I need to figure that out myself lol, I've been trying to do that to finally complete the ThemeDesigner for Cosmos but haven't been able to yet lol [19:37:40] I suppose it could work. It depends on the implications. [19:37:46] *implementation [19:37:55] darn autocorrect lol [19:38:10] I have a food for thought example that works at the minute ill share when im back at my keyboard [19:48:35] shit what did I just do lol [19:54:21] @bluemoon0332 maybe we should add some checks so you can't accidentally mess up the global wiki by accidentally changing the meta custom domain lol [19:54:28] Is that before or after Common.css? [19:55:30] im just gonna make one for simple stuff like link colors and uh ill get back to you on what else [19:55:33] ¯\_(ツ)_/¯ [19:55:48] stuff that works on all skins [19:56:19] oooo maybe patrolled button [19:56:30] Not sure if it is loaded before or after. [19:56:53] eh whats the worst that could happen™️ [19:56:58] Especially since all I did was go to instead of and ended up changing metawiki lol [19:57:08] that shit is criminally small [19:57:26] @cosmicalpha maybe we could have a huge warning that says "You are about to change the global wiki. You probably don't want to do that. Check again!" [19:58:03] add a trout for good measure [19:58:32] Yeah that wouldn't be a bad idea... [19:59:29] for the picker was thinking smt like https://coloris.js.org wheres its a num/text box underneath but js picker and restricted possibe valued [19:59:38] idk if this library would work [19:59:43] itnwas first on google [20:01:50] @pixldev I just read that Discord is introducing a new feature called "Voice Emoji" where users can record short voice clips to use as reactions in chat. [20:02:13] Sounds like fun :ThinkingHardMH: [20:04:13] It's been a thing for a while [20:04:23] Well idk it's been a thing with the soundboard [20:04:54] What is Soundboard? 😮 [20:05:50] [1/2] This thing, you can use it as well a soundboard in vc (blacked out the names that have juvenile humor for obvious reasons) [20:05:51] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1224087281036693648/image.png?ex=661c371e&is=6609c21e&hm=d57c931f1143600db0223f7ac0d9b7ba5846eb85858c6b54e65717c69ed791cd& [20:06:43] Never even heard of it. But hey, I am 50+ I can [20:07:02] I swear if you do a swatch in ooui it has a colour picker [20:07:08] Lol yea idk if it's in all servers or not [20:18:44] 😂 [20:20:25] Sure [20:21:28] This was bound to happen sooner or later tbh [20:21:56] MW should ask for the dbname when doing interwiki ManageWiki changes, that's what I think at least [20:22:59] it does, but not from the default sidebar link [20:23:00] Btw for anyone available, I still need help with this [20:23:04] given the name that ManageWiki/core has in Meta, it should therefore always ask for a dbname when there [20:23:38] (at least it does form Special:ManageWiki) [20:24:00] I have my JS setup to add an extra link to that [20:24:11] yeah, the problem is as you said it doesn't do that if accessing through Special:ManageWiki/core on the global wiki [20:28:15] name in the sidebar, I meant [20:29:47] If https://meta.miraheze.org/wiki/MediaWiki:Managewiki-link-core hadn't been updated, the target would be acurate [20:33:58] updated it to be more acurate [20:35:03] you may find it useful to add something like https://meta.miraheze.org/wiki/User:MacFan4000/common.js#L-25 to your common.js [23:14:27] [1/2] Incorrect actually. When `in_array` is used on a keyed array, it only checks if the needle is in the values, not the keys. So in this case, it is actually searching for `"saddams WMDs"` in `[ true ]`. This converts the string to a bool, which pretty much always evaluates as true. It's still pretty weird behavior, but that makes a whole lot more sense. Pr [23:14:28] [2/2] obably. [23:51:49] <.labster> [1/4] ```~> php -r 'echo "saddams WMDs" == true;' [23:51:50] <.labster> [2/4] 1⏎ [23:51:50] <.labster> [3/4] ~> php -r 'echo "saddams WMDs" === true;'``` [23:51:50] <.labster> [4/4] it's because of equality behavior underneath [23:56:50] loose type checking my beloathed