[08:14:38] @MediaWiki Specialists: any reason we can't rewrite \.miraheze.org/1.41/\ to a single host [08:14:54] at least the powered by mediawiki icon always gets the asset from the local wiki [08:15:00] splits cache for no reason [08:15:10] and something from Vector [08:20:48] might save up to 60,000 requests a day [08:21:07] which is about 1% of what the backend serves [09:03:44] Sounds like an SRE question [09:07:09] I can do it. I just want to know if anyone knows why not. [09:07:54] which is more of a question of mediawiki setup [09:42:53] What's SRE? 😄 [12:03:40] [1/2] Modern name for system administrators [12:03:41] [2/2] Essentially tacking on duties of software engineers [12:38:09] it was a joke, a few days ago we decided to no longer be called SRE but instead "Technology" [12:46:15] It was a joke indeed. Hence the laughing smiley. OA still in automatic gear writing SRE instead 😄 [12:50:13] _is glad SRE is gone_ [17:11:21] everything from that folder _should_ be the same across wikis since it is just downloading stuff from /srv/mediawiki/1.41, so it _should_ be fine [17:14:50] however I don't know 100% for sure [17:21:47] Good, I haven't gone insane [17:21:50] We should try it [17:48:45] @cosmicalpha https://github.com/miraheze/puppet/pull/3848 [18:22:53] Merged. And sorry if my little technical nitpick correction was completely unnecessary lol. [18:23:15] don't worry [18:25:55] I mostly said it because when I was making a script a couple years ago and trying to run like that and needed $0 it took me a while to realize why it returned `-bash` lol [18:46:54] @bluemoon0332 if you ever have time for that cloud URL task for ID it would be nice. For example https://issue-tracker.miraheze.org/T12112 (mediafire) would've worked directly with a CURL so if we had that we could've avoided the need for a task [18:48:28] we could probably even tell people to use mediafire links as it seems you can upload a lot for free and get a link [18:48:33] Hehehehe [18:48:38] How much? [18:48:40] and we can also expand that to images of course! [18:48:50] says 10GB I think [18:49:21] Considering if it’s zipped that seems like more then enough [18:49:43] wikipedia wiki dump 1 link cracked 110% legit mediafire moment [18:49:43] If not [18:49:52] Well um why are you using Miraheze [18:50:49] I've been manually typing out the words importDump.php and importImages.php for too many years now heh [18:50:53] I think internet archive support in particular would be good [18:51:05] I’d need to investigate if we can curl that [18:51:10] I mean basically it would support any links except google drive/dropbox at the beginning as that would be more complicated [18:51:12] we can [18:51:36] people could even directly link from Fandom's Special:Statistics links to the dumps [18:51:51] so no more need to download from there and then reupload to MH [18:52:06] True but for images wikiteam can make both do [18:52:28] Google drive is fairly easy if the link is public tbh. [18:52:39] IA would probably be used more considering what we’ve been talking bout in mod chat [18:53:01] yeah I mean it's not super complicated, but it would probably need an extra if domain like google drive = different command [18:53:10] Gotta love the sea of blue [18:53:28] If no one gets to it I might try it myself but me and dev work usually doesn't end well heh [18:54:00] Me coded 😆 [18:54:20] Better then me at least [18:54:39] I wouldn't think so 😄 [18:54:54] Well yeah but I think there is some composer package we could use for most of this to be in a clean way. I don't want random curl commands in ID itself. [18:56:05] oh really? I didn't know you could do that with composer [18:56:12] Eh at least definitely in extensions [18:56:18] Idk bout python🐍 [18:56:51] https://github.com/TBETool/google-drive-manager is what I was looking at and started some local work with. [18:57:04] whoops wrong message reply but you get what I mean [18:57:33] oh, that looks interesting. Would there be something that would also work for direct links? [18:57:38] How far are we with the constant logouts? [18:57:57] Parsing the ID from a link then using that to download the file. [18:58:14] I'm always so terrified of using these kinds of packages, I don't want to be the next one to get supply chained [18:58:37] we can probably just get users to unzip but it'd be nice to have a package to unzip files too [18:58:53] It's unmaintained for 6 years so probably would fork it and modernize it a bit but better then in ID itself [18:59:07] But it does still work [19:03:27] Also https://github.com/TBETool/dropbox-php @reception123 [19:04:01] [1/2] How far are we with the constant logouts? [19:04:01] [2/2] Do we still report? ⬆️ [19:06:19] @bluemoon0332 [19:08:01] It even happens to me at the WMF wikis so I'm not certain if we can do much about it, it happens to me a lot less then it used to here though. [19:09:28] https://discord.com/channels/407504499280707585/1237261898521645089 [19:10:16] @reception123 the issue with supporting these links tbh is if we support zip or other archives it becomes a lot harder to verify security which means we would also need to build some sort of sandbox around extracting the files before uploading, then check the extracted integrity and security. It's pretty complicated. [19:11:52] So at first I would say only support direct XML not compressed archives. [19:24:04] yeah that's definitely fine [19:26:45] Plain zips should be mostly okay if we resource limit the scanning on them. It should be possible to virus scan them. Encrypted ZIPs are a no. [20:34:31] Fandom's XMl dumps are compressed tarballs that you have to unzip, most wikis have image storage over 5 GBs. not compressing would take forever to upload or transfer [20:40:03] Assuming it's a single layer zip (not a zip inside a zip), not password protected / encrypted in anyway then it'll pass a virus scanner fine [20:40:27] If it's password protected / encrypted, we'd need to open it to virus scan it so probably a no [20:40:35] Double layer zips are a bit more risky [20:40:47] They'd probably need to go through some middleware [20:42:05] I'm also fine with clamav being used [20:42:19] With my security hat on [20:42:49] That is what I plan to get setup eventually. [20:44:59] It should also be resource limited [20:45:12] To mitigate zip bomb style things [20:45:52] can someone explain to me why we need [[[Extension:UnlinkedWikibase]]](https://mediawiki.org/wiki/Extension:UnlinkedWikibase) when https://www.mediawiki.org/wiki/Extension:Wikibase_Client exists [20:45:52]

[20:48:13] unless @rodejong is the wiki your using UWD already a wikibase site? [20:53:27] I have it enabled, but haven't had time yet [20:53:44] Men Labster has it working I believe [20:53:48] No I mean is the wiki already linked to something else [20:54:27] haven't had time yet to figure that out [20:55:34] Did you use wikibase on this wiki before [20:58:00] well usually I generate a tar.gz to save on space. some wikis can have a super large amount of images that can exceed 15 GBs so...that would be rather difficult to send over [21:05:27] [1/2] That's what I said. It's enabled, but haven't had time to figure out how it works 😄 [21:05:27] [2/2] 😄 [21:05:39] ah mb [21:05:47] so both wikibase and unlinked wikibase [21:06:06] Yeah. [21:11:28] Pretty sure tar.gz can be virus scanned fine [21:11:31] ok [21:11:54] I know a .zip inside a .zip can cause issues [21:12:31] yeah, zip bombs...though I doubt anyone serious would try that as that earns an instant ban and the wiki request denial [21:12:52] though in any case, having discussed previously with Labster in here that pertained to ToS so no easy way to obtain those [21:13:18] what pertained to the ToS [21:18:51] automatic means to grab images, in relation to fandom's ToS [21:19:25] though the fork policy could be interpreted as permission to take a copy of the wiki per CC license [21:19:44] that said, 2 of their api endpoints state "Go away" [21:20:28] would be nice if more people knew about Miraheze and started here rather than fandom [21:20:56] Amen [21:20:57] oh ye [21:21:07] We can't tell you to scrape fandom [21:24:05] honestly, there would be no need to api scrape if database [user, actor, extension tables truncated] + image dump were provided [21:33:56] Which endpoints are those? [22:27:58] omg PIXL STOP USING PYTHON CONDITIONAL SYNTAX IN PHP PLEASE [22:28:01] istg [22:31:37] When I was making the relay bot and working with the CVTBot in C# then tried to move back to Python and PHP I kept trying to use C# code lol [22:31:44] lmao [22:32:17] Speaking of which relay bot could use an update [22:32:59] also https://github.com/miraheze/CreateWiki/blob/02e0f298f8d35155c39aa74193cb7b867432c5b8/includes/RequestWiki/Handler/RestWikiRequestsByUser.php#L47C3-L84C5 on line github dont wanna show me are we pretending request with visibility level 3 dont exist or treat is as just level 2 [22:33:45] "on line github"? hmm I'm confused lol [22:36:48] [1/2] github dont wanna show me the exact line number [22:36:48] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1237533620973863003/Pes2qav.png?ex=663bfe7f&is=663aacff&hm=d24ac3e166fa6945f5c4de27d7b01cf39f53c857d31b4d6f07991fa6b7332ce5& [22:36:49] ¯\_(ツ)_/¯ [22:45:43] some crtl c crlt ving later(thanks OS) think I got smt [22:45:44] [1/23] public function getUserRequestCount($user, int $viewLevel) { [22:45:44] [2/23] $visibilityConds = [ [22:45:45] [3/23] 0 => 'public', [22:45:45] [4/23] 1 => 'createwiki-deleterequest', [22:45:45] [5/23] 2 => 'createwiki-suppressrequest', [22:45:46] [6/23] ]; [22:45:46] [7/23] $requests = $this->cwdb->newSelectQueryBuilder() [22:45:46] [8/23] ->select('cw_visibility') [22:45:47] [9/23] ->from('cw_requests') [22:45:47] [10/23] ->where([ [22:45:47] [11/23] 'cw_user' => $user->getId()]) [22:45:48] [12/23] ->caller( METHOD )->fetchResultSet(); [22:45:49] [13/23] $count = 0; [22:45:49] [14/23] foreach ($requests as $req) { [22:45:50] [15/23] $wikiRequestVisibility = $visibilityConds[$req->cw_v]; [22:45:50] [16/23] if ( $wikiRequestVisibility !== 'public' ) { [22:45:51] [17/23] if ( !$this->getAuthority()->isAllowed( $wikiRequestVisibility ) ) { [22:45:51] [18/23] continue; [22:45:52] [19/23] } [22:45:52] [20/23] } [22:45:53] [21/23] $count += 1; [22:45:53] [22/23] } [22:45:54] [23/23] } [23:00:30] WikibaseClient is way more complex [23:02:48] what isn't this is mediawiki [23:08:05] is anything related to mediawiki not complex [23:25:53] WikibaseClient is part of the core implementation of Wikibase and intended more or less for Wikipedia (and Wikidata itself). Wikibase is notoriously complex in its engineering, arguably unnecessarily so. UnlinkedWikibase is more a quick fix to get a wiki to hook in to another Wikibase. MDWiki.org uses it [23:27:16] MDWiki? [23:27:33] [1/3] also [23:27:34] [2/3] > notoriously complex in its engineering, arguably unnecessarily so [23:27:34] [3/3] ..so average mediawiki software?