[05:28:02] got a bit of an out there idea but it might give us a fighting chance against fandom’s SEO [05:28:43] All ideas are welcome. 🙂 This is a group project, we're only constrained by our resources (funds and people-hours) [05:33:01] [1/2] so I’ve noticed that most search engines tend to rescan sitemaps more often and with higher priority if the sitemap is registered in the webmaster console. these sitemaps will also often work across subdomains, even subdomains verified to other accounts (that’s why sitemap stuff on static linked to on a wiki works and is recognized). if you add both miraheze.org and stati [05:33:01] [2/2] c.miraheze.org to, let’s say, google search console, and then register the global sitemaps on both domains, the global sitemaps will (or at least should) get more frequent indexing [05:33:44] this is purely conceptual, I haven’t done any actual testing [05:34:06] but based off what I’ve seen previously in similar examples there’s no reason why it shouldn’t work [05:39:21] Definitely a big reason I push the WikiSEO guide (and registering sitemaps for individual wikis in GSC) whenever possible [05:40:05] Registering the globals is an interesting idea, but I'll need to defer to our technology team on whether that's already being done/what problems that might encounter [05:41:13] sounds good [05:41:42] as I said there shouldn’t be any problems but I do suggest asking tech about it beforehand, you can never be too certain [05:56:13] TheresNoTime: you there? :3< [05:56:34] oh wait it's like 7 am in the uk [10:40:05] what nexttide.org? [10:40:39] extra mirabeta domain it appears [10:53:51] trying to figure out how to get the miraheze subdomain in MirahezeFunctions challenge [10:54:01] ($wi->server is the custom domain for wikis that use those) [10:59:09] $wi->server is always the domain of the wiki your on [10:59:17] Irregardless of whether its a custom domain or not [10:59:47] oh neat [11:00:14] i wanna fetch both the *.miraheze.org (+ friends) and custom domain though [11:00:34] Unsure what you mean? [11:00:36] since i wanna add both of them to be allowed for templatestyles [11:01:06] basically, i want to allow https:///w/img_auth\.php/.+ for urls in sanitized css [11:01:21] Theyre not all stored in MirahezeFunctions or anything like that [11:01:23] wait nevermind i think i'm overthinking this [11:01:30] am i? [11:01:34] no i don't think i am [11:01:44] > [17/09/2024 21:01] Theyre not all stored in MirahezeFunctions or anything like that [11:01:45] oh? [11:02:40] The allowed_domains is the closest you will get to dynamically getting the domains [11:03:21] $wgUrlShortenerAllowedDomains? [11:03:56] or initialise/MirahezeFunctions.php: public function getAllowedDomains(): array { [11:04:55] That just gets the domains from the array at the top of the file [11:05:03] Which only has miraheze and nexttide [11:05:09] what do you mean by allowed_domains? [11:05:12] there's two [11:05:49] There is an array at the top called allowed_domains [11:06:07] oh, ALLOWED_DOMAINS [11:06:18] GetAllowedDomains just reads from that based on whether your on beta or not [11:07:31] > [17/09/2024 20:59] $wi->server is always the domain of the wiki your on [11:07:49] so it basically more or less functions like $customDomain ?: $mirahezeSubdomain? [11:08:25] Huh [11:08:41] that's (most likely) not how it's implemented [11:08:50] but i just wanna make sure i know what it does [11:09:15] is it the custom domain if it exists, and the subdomain if it doesn't? [11:09:24] $wi->server just reads from PHP server globals [11:09:31] or by "the domain of the wiki your on", is it effectively the Host response header? [11:09:36] request header* [11:10:35] Its the url in the address bar? [11:10:50] Irregardless of whether you are on a wiki that has a custom domain or not. [11:11:00] oh okay [11:11:24] Which is compared with the cache file to figure out which database name we are on [11:12:11] (Or if there is no url in the cache file for that wiki, we try the subdomain and append wiki, if we find something then that wiki exists, if not, then it doesnt) [11:12:53] Pretty sure it happens in reverse order actually there but [11:13:55] hmm how do i get the current wiki's custom domain? [11:16:28] [1/3] You can try either [11:16:28] [2/3] - get the current database, and search the cache file for the database name, if there is an url in there for that database, its the custom domain; if not and the url is blank, it uses a mh domain. [11:16:29] [3/3] - not sure theres anyway to get it from ManageWiki because ManageWiki is really poorly designed. [11:16:46] Ideally youd be able to do Wiki::getDomain or something but i dont think thats possible [11:18:13] [1/2] Oh actually looks like you can call getServer on a wiki object [11:18:14] [2/2] https://github.com/miraheze/ManageWiki/blob/master/includes/FormFactory/ManageWikiFormFactoryBuilder.php#L152 [11:19:07] interestingly, https://rainverse.miraheze.org/wiki/Special:UrlShortener states rainverse.wiki [11:20:48] urlshortener domains are set here: https://github.com/miraheze/mw-config/blob/915c9873b6faf6f6c1d5bd89c48fd216012262af/GlobalSettings.php#L551-L570 [11:21:47] That seems largely just the same as getting it from ALLOWED_DOMAINS in MirahezeFunctions tho? [11:22:31] yeah, but how does it know to use the custom domain? [11:22:42] s/use/allow/ [11:22:43] What url shortner? [11:22:50] Special:UrlShortener [11:23:04] uses custom domain even if you're on a *.miraheze.org: https://rainverse.miraheze.org/wiki/Special:UrlShortener [11:23:18] Line 568 merges the current url with $wgUrlShortnerAllowedDomains [11:23:21] i wish i could do some dynamic testing >_< [11:23:39] yes, it uses $wi->server [11:23:58] but i queried it with rainverse.miraheze.org, and rainverse.wiki is allowed [11:24:17] so i think $wi->server would be rainverse.wiki here? [11:24:41] If the wiki has a custom domain, yes it will be. [11:25:18] but didn't you say that $wi->server is determined by the url sent by the browser? [11:30:53] [1/2] I dont really know how to explain it. The url in the browser is used to get the database name, which is read from the cache file to see if we have a custom domain, if so, we set wi->server to that, if not, we manually construct it based off the database name. [11:30:53] [2/2] I think i made it more complicated than needed. [11:31:34] I think potentially you can rely on wi->server to getnthe custom domain if one is set because if not it will resolve to the Miraheze subdomain for that wiki [11:31:41] okay thank you [11:32:31] It would probably be better if the database file just listed all of the domains for each wiki instead of manually trying to generate them at runtime. [16:59:12] Sorry took me awhile to reply to this. But yeah, I want some sort of public list in git even if we can fully automate with using CF API somehow, still being in git is a good idea for me to keep that there. [17:00:08] This could have quite a bit of unexpected caching issues is my main concern with that. [17:02:48] it shouldn't do [17:14:52] At the very least, I think we could serve a "This domain is not configured properly" page rather than the landing as that's cryptic [17:15:07] Yeah [17:15:31] also use the opportunity to incorporate more funny bee mascots into error pages /j [17:15:35] mediawiki will serve wiki not found page i think [17:15:42] yep, it does [17:15:50] but that's also not intuitive enough [17:16:01] we could add a link to RequestSSL [17:16:05] Yes I think we should serve something else then the landing but not necessarily MediaWiki as in a wiki which I thought you meant. [17:16:18] unless MW can detect when a non-miraheze.org domain is server and changes the error accordingly [17:16:20] cause if it's auto approve then it'll be quick to do [17:16:26] If you mean a MediaWiki error page then yes we should. [17:16:26] it should be able to [17:16:37] ye it'll be a domain / wiki not found page [17:16:41] not like a random wiki [17:16:52] Okay makes more sense lol [17:16:59] no no, I actually like the idea of serving a random wiki 😆 [17:17:08] i just want mediawiki controlling it so we can automate easier [17:17:19] saves having to wait for NGINX to rollout the config etc. [17:17:45] which means custom domains are instant not 30 minutes [17:18:04] Sorry, this wiki doesn’t really exists. In other news, here’s a totally unrelated wiki for you! [17:18:12] Sounds familiar [17:21:27] we could invent Special:RandomWiki [17:21:38] sends you to Special:Random on a random wiki [17:22:28] [[Special:RandomWiki]] [17:22:30]

[17:22:40] Done [17:22:44] oh well [17:22:45] I invented it [17:22:53] /j [17:22:54] I advise to not do that lol [17:23:35] i forgot that exists [17:23:42] you could have a random page button too [17:23:55] that goes to Special:Random instead of Main_Page [17:23:56] Wiki roulette [18:24:56] how long for the localisation issue to solve? Is a matter on finding the cause or is being deployed already? [18:41:07] No idea [18:41:57] thanks