[03:40:55] anybody know how to set up cloudflare r2 using the AWS Mediawiki extension? [03:41:49] keep getting this error: /var/www/html/extensions/AWS/s3/AmazonS3FileBackend.php on line 1172 [03:48:32] should ask this in the mediawiki discord, not here [04:11:55] Yeah I have [04:12:04] think they might be busy [09:25:31] Well you copied the least helpful bit of the error message there [09:25:59] Since you didn't actually copy the eye error just the line it was thrown [21:20:54] [1/11] I forked FlowThread (a commenting extension) and made some changes to it (https://github.com/lihaohong6/FlowThread): [21:20:54] [2/11] 1. Use `tables.json` instead of raw SQL table creation statements. [21:20:54] [3/11] 2. Some CSS changes to accommodate dark mode. [21:20:55] [4/11] 3. Replace deprecated functions such as `setPageTitle` and `Xml::fieldset`. [21:20:55] [5/11] 4. Format both PHP and js using MediaWiki conventions. [21:20:55] [6/11] 5. Replace `array()` with `[]`. [21:20:55] [7/11] Some stuff I haven't done: [21:20:56] [8/11] 1. Integrate with UserProfileV2. Comments are generated entirely using js in the front end (an odd choice but I guess it makes sense since pagination support becomes easier), but UPV2's API can only retrieve a single profile picture at a time. Either @originalauthority can implement a batch profile picture query api on UPV2 or I can create one on FlowThread that calls UPV2 fun [21:20:56] [9/11] ctions in the backend. [21:20:56] [10/11] 2. The outstanding security vulnerability mentioned in [T14323](https://issue-tracker.miraheze.org/T14323) that only @redmin0 knows about. Not sure how long we want to wait before fixing it ourselves... [21:20:57] [11/11] 3. Anything else that needs to be modernized. The extension seems to not be well written, so if anyone wants to take a cursory look at it and point out some issues that'll be greatly appreciated. [21:25:24] Funny timing lol, I just emailed the CommentStreams maintainer like 2 minutes ago so we can hopefully get those patches merged soon; but I can take a look at FlowThread as well [21:26:24] FlowThread should at least require 1.43 based on the class aliases it uses [21:26:49] I think I got a lot more interested in it once @honoka55 noticed that we can import comments from both CommentStreams and Fandom into it. [21:27:43] I don't like how the extension stores state in globals (), that is definitely something that could be fixed [21:29:19] Bumped version requirement. I may have to branch it at some point too since development would be done against the version of MW Miraheze is using in prod. [21:30:17] UserProfileV2 avatar handling is in need of a major major rework [21:30:17] and the rest of the extensions should not pollute the global namespace (I think it does, I'm not 100% sure how the JS is loaded based on the configuration in extension.json) [21:30:20] its fucked beyond words [21:31:17] Ah that's right. I remember there being multiple ways configs can be loaded. I suppose I'll use `MediaWikiServices::getInstance()->getMainConfig();` instead. [21:31:34] (prolly want a separate config object rather than mainconfig) [21:31:42] MainConfig should be used for core [21:31:45] I found the vulnerability mentioned btw, assuming there are not multiple [21:31:59] Config variables still shouldn't be used to store state [21:32:21] Not sure what would be a better way but it doesn't feel like a good solution rn [21:32:33] It's done by `$output->addModules( 'ext.flowthread' );` so it probably does pollute global nemspace. [21:33:31] ImgTag uses it to store the config (https://github.com/lihaohong6/ImgTag/blob/8be9c1df48be905be3d2fa8aef348ea81d0c49d2/includes/ImgTag.php#L81). I think I copied it from some other extension... [21:34:06] Thanks. That's good to know. I guess I copied from the wrong ext. [21:34:06] That's a different thing, the code in ImgTag is storing the config, not storing data in the config [21:35:04] Oh I see. You are referring to `$wgTriggerFlowThreadHooks = false;` which changes the config at runtime? [21:35:06] what is wgTriggerFlowThreadHooks actually used for? there are no docs? [21:35:30] FlowThread should also declare Echo as a dependency [21:35:49] [1/2] This is not great for ManageWiki [21:35:50] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1435382052651401376/image.png?ex=690bc335&is=690a71b5&hm=77dc9b2b35d732cbc2c3fcc5131d2c64eb8b92baf2aacb996fb403339887dddf& [21:36:16] (An alternative is to use the config object which you can call `->set()` on it to overwrite the config for the request [21:36:34] but you probably actually want some kind of object which you can call `::disable()` on or something [21:37:15] there are multiple vulnerabilities btw [21:37:23] no, but its doable if we alias some custom config variables and set them in GlobalSettings [21:37:31] It seems that one use of `wgTriggerFlowThreadHooks` is to disable the spam filter when importing comments (i.e. no comment should be blocked by the spam filter during the import). [21:37:32] that's still not great [21:37:36] if we fork it we should fix it [21:38:39] Ah that's a good point. I think we can just change things around in the extension. We don't have to maintain backward compatibility when the fork is not used anywhere yet. [21:38:40] yeah probably some kind of class you can just `::disable` and then check `::isDisabled` or something like that before running the checks [21:39:07] Tbh considering the code quality we should probably rewrite half of it [21:39:40] Yeah that's what I'm tempted to do as well lol. [21:39:54] [1/2] like this for example [21:39:54] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1435383078498336778/image.png?ex=690bc42a&is=690a72aa&hm=8bab4d257878cbad6e15144ee53869cb9c37b72a0c57bfea99e5878f8ee3b2f0& [21:40:12] @abaddriverlol has flowthread got any connection to flow code base wise? [21:40:19] Don't think so [21:40:26] [1/2] https://github.com/lihaohong6/FlowThread/blob/1ee0fae903c5f76aa84365763e0843be1480119f/includes/SpamFilter.php#L197 [21:40:26] [2/2] Screaming crying throwing up [21:40:53] Does everything with flow in the name have to be messy code then? [21:41:04] apparently lol [21:41:12] the code quality of CommentStreams at least is way better than this [21:42:26] I was gonna write my own comment extension maybe now is the time [21:43:09] also exists btw though idk if that's intended for use by third parties [21:43:11] Maybe we should just go back to the drawing board: we need a commenting extension that has all the basic features while allowing comment imports. [21:43:12] too busy breaking QT and C++ though [21:43:23] https://xkcd.com/927/ [21:43:24] Exactly how dangerous is deploying this extension? https://gitlab.the-qa-company.com/FrozenMink/batchingestionextension/ [21:43:50] I agree but [21:43:51] It's incompatible with MW 1.44 so it would break wikis [21:44:13] Huh, guess I can’t upgrade MW on Librarybase [21:44:28] If you do make such an extension my life would be a lot easier lol. [21:44:35] ( was the first thing I saw) [21:45:12] I was mostly planning to write my own because I wanted to replicate some kind of messagewall system too and to utilise the same editor for both [21:45:20] i hate talk pages with a passion [21:45:36] Bawolff wrote an inline comments extension once [21:46:09] ? [21:46:10] not the full class littered with reflection properties [21:46:13] interesting [21:46:26] why would anyone want that though? [21:46:41] if you want that functionality, use google docs? [21:46:53] What if they want to use MediaWiki instead [21:47:03] that argument can be applied to 1000 other extensions as well [21:47:04] using the wrong software for the job [21:47:15] unfortunately some people want to use MW for everything [21:47:27] https://tenor.com/view/panicking-gif-22262539 [21:47:31] I don’t see how in-line comments are anathema to wikis [21:47:50] Hmmm. Maybe I should start using Fandom for the sole purpose of trying message wall: perhaps it has some redeeming qualities. [21:48:04] [1/2] This kinda reminds me of discussions on OSM and this sounds like a cool idea tbh [21:48:04] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1435385133351043104/InlineComments_reply_or_resolve.png?ex=690bc613&is=690a7493&hm=707bd3783392d237f763475bae7309db4145324a1d8019e185d7f4a3b48f37d2& [21:48:18] It's easier to discuss individual sentences/areas of the article this way [21:48:21] erm, it doesn't really [21:48:26] because the editor sucks [21:48:28] no wikitext [21:48:41] the old message walls were significantly better when they ran MW [22:25:52] Maybe I should just let ChatGPT rewrite the code. Whatever it comes up with will be better than the current state of FlowThread... [22:26:17] Please not [22:32:59] @abaddriverlol was it you I was going to find that article on ChatGPT and secure code? [22:33:12] No. No. No. And if it wasn't clear no. [22:33:36] do you mean the thing you wanted me to remind you about yesterday? [22:33:38] (I forgot myself) [22:33:43] Yes [22:33:46] Ah [22:33:49] See if I remember tomorrow [22:33:56] lol [22:34:23] The premise of the article is AI is terrible at writing secure code but it also explains why. [22:35:02] AI is terrible at most things tbh [22:35:05] I wonder what percentage of our deployed code is AI-generated [22:35:10] probably not a lot (yet) [22:35:21] all my mistakes are human :3 [22:35:22] It's a predictive model, it's not understanding what it's doing [22:35:39] Just guessing the next pixel or charecter [22:35:49] AI trying to write text in images is fun [22:35:52] It can't do it [22:36:17] AI is good at helping me fix some of my human errors if you ask it to talk you through debugging it [22:36:21] I think whatever ChatGPT is using to generate images can generate text now [22:36:29] It's slightly more useful than just asking a rubber duck [22:36:30] I've seen AI images with decently readable text [22:36:42] ChatGPT is awful [22:36:54] you should see what my teachers are doing with notebooklm [22:37:06] There was an image going round on X that grok said was real that was ChatGPT [22:37:10] Very recent one [22:37:21] grok is this true\ [22:37:21] And the text was one of many very big giveaways [22:37:22] Depending on VE is not ideal, but it seems to be at a much better state than FlowThread. If forking is on the table I think I might as well try to fork it instead of FlowThread. [22:37:40] The amount of people that do that on X is painful [22:37:53] Elon should ban every twitter user that posts that [22:38:08] hahahahahahahahaha that's the exact opposite of what he wants [22:38:16] anyway I should sleep [22:38:19] Office tomorrow [22:38:31] a mind subservient to LLM slop is easier to control [22:38:33] So I have to look awake [22:38:38] good luck with that [22:38:41] sleep well [22:40:19] :trout: [22:41:03] Maybe I'll expedite my plans to create an alternatice [22:41:10] Maybe I'll work on that tonight [22:46:22] That will be great lol. I can work on the things that I'm good at instead. [22:46:56] I haven't had a deep dive into that one so not really 100% sure if the semantics but how exactly does importing comments work? Is it by a special page, maintenance script? [22:47:15] I'm assuming it gets the comments from the API though [22:47:18] Maybe I'll just check lol [22:48:17] That does not sound like a great solution [22:48:37] Ideally you don't want import functionality like this to depend on the extension that created the original data [22:49:11] Huh [22:50:11] [1/2] It's done on a special page where the user can upload a json file containing the comments to be imported. The intended way for it to work is to export comments on a wiki and then import them on another wiki, but nothing prevents people from converting comments from one extension (e.g. Fandom's proprietary extension) into the format used by FlowTh [22:50:12] [2/2] read. [22:52:52] [1/2] https://issue-tracker.miraheze.org/T14323#286915 [22:52:52] [2/2] The json file format is quite odd imo. The fact that the comment id also encodes the timestamp feels wrong to me.