[00:00:24] [1/2] Doesn't happen for me either, must be a WMF thing [00:00:24] [2/2] https://cdn.discordapp.com/attachments/407537962553966603/1413312775241076736/Screenshot_2025-09-05_at_01.00.07.png?ex=68bb7997&is=68ba2817&hm=96924ab6414ac13d3bd955b96835fd0f0435ba868d6a67085a8cf9890a068d83& [00:00:37] presumably they're running a newer version of Parsoid than everyone else [00:01:00] oh thats legacy [00:01:05] LOL [00:03:07] We did this because Lighthouse was complaining mostly [00:05:18] [1/20] On Undertale Wiki I see [00:05:18] [2/20] ``` [00:05:18] [3/20] Self link [00:05:19] [4/20]

[00:05:19] [5/20] /p [00:05:19] [6/20] /span/th [00:05:20] [7/20] ``` [00:05:20] [8/20] On Wikipedia I see [00:05:20] [9/20] ``` [00:05:20] [10/20] Self link [00:05:21] [11/20] /a

/a [00:05:21] [12/20] /p [00:05:21] [13/20] /th [00:05:22] [14/20] ``` [00:05:22] [15/20] On Wikipedia with Parsoid I see [00:05:23] [16/20] ``` [00:05:23] [17/20] Self link [00:05:24] [18/20] /a/th [00:05:24] [19/20] ``` [00:05:25] [20/20] Parsoid only generates the `` tag without the extra paragraph. [00:05:52] It seems that parsoid's handling of self-links is different and you can click on it. [00:06:42] yeah why are they adding a href [00:07:03] _over a decade in development, going really well_ [00:07:48] Well, I hope I don't have to deal with the MW parser. I've heard of plenty of bad things about the legacy parser and plenty of bad things about parsoid. [00:08:37] I don't necessarily think the idea of Parsoid is bad; it fixes a lot of issues with the legacy parser, it's just not being implemented very well [00:09:08] just like Codex/Vue [00:09:16] Well I guess this would've solved our Lighthouse issue as well [00:09:16] also a half baked solution [00:09:45] Codex is so much better than OOUI though [00:09:53] is it though? [00:10:03] you loose infusion right out the bat [00:10:37] Yeah Lighthouse complaining about self-links not being real links with a href is very annoying. [00:10:40] Yeah I developed a few scripts with it and it took 0.5x as much code for the same thing as on Fandom [00:11:00] I don't disagree in principle, but the lack of components is shocking [00:11:14] [00:11:51] Granted a Vue developer would 🤮 at this code but [00:13:02] I've worked with OOUI dialogs and I've worked with Codex dialogs and Codex is so much more intuitive [00:13:25] And they had a component for pretty much everything I needed [00:13:39] fiar [00:13:45] Even page search which I didn't know I needed [00:13:53] can't spell I'm trying to read money heist subtitles at the same time lol [00:14:43] It would've been great if they'd speed up with the components, it takes them about a year to develop a simple component [01:39:27] Is there an in-depth tutorial on mirahaze? [01:45:35] Not really, we have help pages on topics, and thi sserver to ask any general questions [02:11:09] Also that are so many types and structures of a wiki that an "in-depth tutorial", is simply not possible to make [03:41:15] Always feels like such a jumpscare to see people who are Miraheze volunteers have visited my wiki, even when I should've expected it bahaha [03:41:38] i should go and meow on-wiki [03:47:04] Sounds fun, do it [03:59:25] Is there any way to add something to a template that makes it only transclude once, and not recursively transclude? [03:59:47] Namely for templates like "This article is a stub" headers [04:00:31] / ? [04:00:34] Is there something I can put in the template that still allows it to appear on an article page, but it won't carry over if the article itself is transcluded or hyperlinked [04:00:39] [1/2] Essentially this [04:00:39] [2/2] https://cdn.discordapp.com/attachments/407537962553966603/1413373235990364301/image.png?ex=68bbb1e6&is=68ba6066&hm=15fb7dfd705e5fd07f32ab1551e81d522b6c6bef5643e6264b589c4fe25341d7& [04:00:48] hm [04:00:59] ooh I'm not sure this is possible. I've tried to look into it before [04:01:22] although I'm not sure why you would need it for a stub template [04:01:53] I just picked that as an example for a random header that might be at the top of an article [04:02:04] you could maybe use parser functions so it renders `Content here/noinclude` when transclued, to kinda defer that down [04:02:29] On B, use `{{C}}/noinclude`. [04:02:44] Well yeah, thats the easy and smart way lol [04:03:07] this is a hack if you need to have it work just with {{C}}, not wrapping things around it [04:03:08] [04:04:11] So this would be something that I apply to the actual article pages, and not something I can put on the template itself, correct? [04:04:18] Not ideal but certainly doable [04:13:34] What's the best way to swap the file names of two files? (Especially with a large set of such pairs) [04:16:56] We do be spookin' about in the infrastructure [04:17:25] Yeah. This is probably the easier solution (though a bit tidious). [04:56:32] @posix_memalign can next month's MM be about roblox wikis :pleadingsoggy: [05:04:41] We meet again :trout: [05:06:41] [1/2] The current plan is to feature IRWA wikis on IRWA's 1-year anniversary (February 2026). With the number of Roblox wikis we we have, I'm not sure if we can pull it off in one issue, though. [05:06:41] [2/2] If you'd like, you can write a short intro of UTG on [the suggestion page](https://meta.miraheze.org/wiki/Talk:Miraheze_Monthly/Wiki_highlights). Ideally it'll target a general wiki editor audience since most readers are not familiar with Roblox or IRWA. We'll try to incorporate it into an issue one way or the other. [05:07:58] that's nice :D I'm also making a wiki about a Roblox game [05:08:34] wait thats kind of nice to feature when irwa's one year old 🥹 [05:08:51] I'd imagine a conversation will happen in #volunteering as some point about this. When we try to say non-trivial things about featured wikis in August's issue, the column got pretty long with only 3 wikis. [05:10:28] I think @pixldev suggested that. It was a really good idea. [05:19:15] Low long have you been volunteering if you don't mind me asking :ThinkerMH: [05:23:36] [1/3] Wiki editing: October 2021 [05:23:36] [2/3] Editing on a MH wiki: November 2023 [05:23:37] [3/3] Volunteering for MH: August 2024 [05:28:25] Wow [05:29:41] [1/5] Wiki editing: mid 2020 in any serious capacity [05:29:42] [2/5] MH editing: Aug 2022 [05:29:42] [3/5] MH volunteering: Nov 2022 [05:29:42] [4/5] WT board: Jul 2023 [05:29:43] [5/5] It's been a hell of a ride [06:06:50] what i missed [06:09:34] [1/6] does anyone know why this script doesnt seem to work? [06:09:35] [2/6] ``` [06:09:35] [3/6] if (mw.config.get('wgCanonicalNamespace') == 'User') { [06:09:35] [4/6] mw.loader.load("https://tagging.wiki/wiki/MediaWiki:Mastoblox.js?action=raw&ctype=text/javascript"); [06:09:35] [5/6] } [06:09:36] [6/6] ``` [06:09:45] the code in the url works but not the snippet above [06:13:53] [1/2] I think it's working. I get an error indicating the script has already been loaded. [06:13:53] [2/2] > Uncaught SyntaxError: Identifier 'mastodonLinks' has already been declared [06:18:07] thats weird [06:18:33] hmm, maybe if it's loaded twice? [06:18:36] it's not in an iife either [06:19:07] my user page on [tagging.wiki](https://tagging.wiki/user:stackd) shows its working but not [fischipedia.org](https://fischipedia.org/user:stackd) [06:20:19] ever heard of CSP [06:20:23] It'll get blocked by the CSP if the load something from tagging.wiki [06:20:37] ooo yeah [06:20:43] tagging.miraheze.org >:3c [06:20:50] (or what the actual subdomain is lol) [06:21:01] ((unless you have redirects on, in which case, sorry ^^;) [06:21:13] yea they do and utg.miraheze.org [06:21:35] still, changing tagging.wiki to utg.miraheze.org in the js snippet here wouldnt work [06:22:22] i think putting it in devwiki is acceptable [07:11:52] i left tablet after that and went to bed, now i check the tab again and it was saved, peace and love on planet earth [09:18:32] [1/3] pretty sure I've asked before but probably got unnoticed, about disabled talk features [09:18:33] [2/3] because i have a scuffed forum solution I've made w/ custom namespace and DiscussionTools on my wiki [09:18:33] [3/3] the public spaces like talk pages and comments stayed, does that mean "forums" are fine too? or I'll have to nuke this all? [09:19:25] although my wiki is obscure and forum got used only once (when it was on Flow long time ago) [09:32:52] @blankeclair thanks for the help [09:35:02] yw :3 [10:07:52] Yup [11:48:58] the problem comes when it classifies as private messaging [11:49:10] if it's a public setup it is not even in consideration [11:49:41] aight thanks [11:50:12] yeah, had to replace mentions of Special:Contact w/ bsky link [12:32:58] [1/2] I’m looking to help the first 10 people interested on how to  start earning $100k or more within a week, but you will reimburse me 10% of your profits when you receive it. Note: only interested people should send a friend request or send me a dm! ask me (HOW) via Telegram username @tradesensible [12:32:59] [2/2] Or The Telegram Link in my bio [12:33:34] Hi all, I hope everyone is doing fine. [12:34:06] @Discord Moderators [12:34:14] hi there [12:34:56] I have a support request. Currently the link to the Miraheze wiki with the domain seems to be broken https://permanentfuturelab.wiki/ [12:35:00] https://permanentfuturelab.miraheze.org/wiki/Permanent_Future_Lab_Wiki is the wiki [12:35:24] Maybe because it was closed? But normally there is some time to reopen it. I am not aware the domain linking will get stuck due of this [13:19:37] why doesnt my fandom imported infobox doesnt work on miraheze?? [13:21:13] Did you enable the Portable Infobox extension? Other than that, you are gonna have to give a little more info (ideally, if you wiki is public, a link to the Infobox page, and a page where it is used) [13:45:44] Unlike Fandom, where templates and modules are transcluded to your wiki, on Miraheze you need to have all templates and modules on your local wiki. Miraheze does not transclude them from our [[dev:]] to your wiki. [13:45:45] [13:46:22] And a link to your wiki is indeed apreciated, if it is a public wiki [14:43:56] Thanks [14:44:06] Where do I give this information? [14:47:32] A question: My wiki is currently small. It’s not allowed to "advertise" a wiki, is it? [14:53:30] normally you would advertise it in the relevant communities [14:54:42] it's probably unlikely you'll get many people interested in a general server like this [14:58:18] @brycebits do you still edit the tower heroes wiki? [15:07:32] yup [15:07:43] ots that im still not active [15:07:47] i edited a bit there [15:08:05] o, dats cool [15:08:07] oh yeah could you add the current changelogs in that page [15:30:46] Not sure what you mean? [17:36:25] <__regal__> [1/2] Do you see the silhouette? what is it? [17:36:25] <__regal__> [2/2] https://cdn.discordapp.com/attachments/407537962553966603/1413578530578759842/image.png?ex=68bc7118&is=68bb1f98&hm=06ef251ed301c6a58c19377091c144f50c953e5c777467ecb1ad7ebe9c12ce07& [17:39:08] $wgTimelessBackdropImage [17:40:03] <__regal__, replying to pskyechology> aha thanks [18:16:01] An ugly circle 😻 [18:17:43] do you have "people" doing editions of lorem ipsum in private workshops? (don't know the name in english, in spanish is "Taller" and is a private space for testing [18:24:08] Did you disable wikimedia commons integration or is the server down again? [18:24:36] Why isn't templatestyles declaring CSS variables? [18:24:43] I have templatestylesextended enabled [18:24:53] https://skibiditoilet.miraheze.org/wiki/Template:Abilities_Header/styles.css [18:25:46] <__regal__, replying to progeest> bro [18:26:16] https://www.mediawiki.org/wiki/Extension:TemplateStylesExtender#Note_CSS_Vars [18:26:28] > Currently using :root selectors won't work due to template styles prepending .mw-parser-output. [18:26:44] 😢 [18:26:48] Ofc it won't work [18:26:52] Damned [18:28:06] Ok wait I have an idea most ingenious [18:28:08] just scope them in a different selector [18:28:16] yeah was about to do that [18:28:45] :root has somehow become the convention, but it isn't even necessary for styles like this, and it's better to not bloat the entire document with more variables [18:33:19] The entire thing is going over my smooth brain for some reason, could you just edit the thing yourself and make it work? [18:33:36] [1/2] Currently testing it here [18:33:37] [2/2] https://skibiditoilet.miraheze.org/wiki/User:BitByte10/Sandbox?debug=2 [18:43:47] ugh nvm will just do it without CSS vars [19:16:54] the easiest way to solve it would probably be to have one class that all elements created by the template are using, and then scope the variables into that a selector for that class [19:17:19] there should probably be a way to scope variables into .mw-parser-output, but I think that's not possible right now [19:45:49] [1/2] https://phabricator.wikimedia.org/T320322 [19:45:49] [2/2] Just gotta add oneself to the list of subscribers and pray someone finally implements it. [19:51:17] Now it's complaining that is returning null instead of Title [19:51:23] ```[4b691b9ed77242c49982ac47] Exception caught: PortableInfobox\Services\Parser\Nodes\ParsoidMediaNode::getImageAsTitleObject(): Return value must be of type MediaWiki\Title\Title, null returned``` [19:52:17] Do you have a media tag that isn't being used? [19:52:42] I only have tags [19:52:44] That bit is taken from the legacy Parser implementation so I wonder if Parsoid handles it differently [19:53:07] But yes the image is not specified as you probably already saw [19:53:11] Maybe the legacy Parser one didn't have type hinting hmm [19:53:30] Yeah it didn't [19:54:20] Ok when I change Title to ?Title it works [19:55:36] Well it still has the bug and doesn't load PI styles but the editor loads and can edit some fields [19:56:25] I wonder why this isn't being thrown on my local install [19:56:33] wdym it doesn't load the styles? [19:56:46] https://cdn.discordapp.com/attachments/407537962553966603/1413613852947517470/image.png?ex=68bc91fe&is=68bb407e&hm=6ddffae09d396dbf5392151fde16e5357544ebc4a714feb4eaaab141462e1644& [19:57:06] Wiki styles are there, PI styles apparently are not [19:58:12] [1/2] `mw.loader.load('ext.PortableInfobox.styles')` and it looks fine [19:58:12] [2/2] https://cdn.discordapp.com/attachments/407537962553966603/1413614211430613113/image.png?ex=68bc9253&is=68bb40d3&hm=a4660d604f48e3f410497db27e57f770978ee116042ed2391f18fc39288f5392& [19:59:11] interesting https://github.com/OAuthority/PortableInfobox/blob/parsoid-patch/includes/Parsoid/InfoboxTag.php#L50-L51 [20:10:09] ContentMetadataCollector is such a meaningless class name [20:17:42] Does it work on your side, are you loading VE on the same page that the styles have already loaded on or on an entirely new page [20:18:50] well I can't load VE atm but last time I checked it worked [20:19:00] [1/2] i've got some persistent erorr thats preventing ve from loading [20:19:01] [2/2] VisualEditor failed to load: Error: Failed dependency: ext.visualEditor.core.utils [20:19:07] and nothing I do fixes it lol [20:21:10] Extension version mismatch? Which commits are for core and VE [20:21:58] The problem with the `format` tags is that the frame isn't being passed, which is a bit of an issue and what held it up the first time. They had so-called solved this but I don't think they have (atleast not on 1.44) [20:22:56] [1/2] > Which commits are for core and VE [20:22:56] [2/2] huh? I'm using 1.44 for both [20:30:26] I suspect what is happening here is that the styles etc al are being returned by adding them to the Parser output, which is obviously not being returned by the API. And if you're not running Parsoid for reads I guess that's never called? I can't think of another way to get it to work unless we just add them in the onBeforePageDisplay hook [20:30:59] Yeah I guess that makes sense [20:31:33] I can patch this into a gadget I think [20:32:00] Until we inevitably switch to Parsoid and it just starts working I guess [20:32:40] I'm trying to think if there is a way that the format tags can be fixed. We already have access to all the params, so we can simply do a replacement of the parameters I guess before it's parsed, but I'm worried about what would happen in the instance that the stuff in the format tag is more complex than simply accessing the data variable for that row [20:32:46] I don't know if that makes sense but it does in my head [20:36:17] Do you think it might be because replaceVariables is a noop on Parsoid [20:41:55] Though replaceVariables doesn't seem related to so probably not [20:45:24] Maybe but I didn't see it get called when I went through the legacy with xdebug, it was passing the frame to Parser::recursiveTagParse which does have a replacement method of its own that maybe needs to be replicated in this instance [20:49:57] Mm yeah MediaWikiParserService gets created with a PPFrame but the Parsoid one does not [20:57:07] Wait, so you're doing the entire parsing in the post-processing stage [20:58:16] Yes [20:58:44] Because it's the first time Parsoid makes the template arguments available [20:59:07] It's an ugly hack [20:59:26] [1/2] one thing i pray you to do [20:59:26] [2/2] change the url to towerheroes [21:00:31] We don't get any of the arguments etc until we reach this stage and return them https://github.com/OAuthority/PortableInfobox/blob/parsoid-patch/includes/Parsoid/InfoboxTag.php#L55 [21:00:56] Which at that point is too late to do the work in the main parsing function so we have to discard that and just take from it what we need in the post processing phase [21:21:53] I'm not seeing any arguments in `$options['frame']->getArgs()->dict()` at the top of wtPostprocess, am I missing something [21:24:10] No, that's the whole issue - the frame is empty which is the problem [21:24:47] So then... where are we getting the arguments from anyways [21:25:09] Oh wait it's replacing the arguments during the parse stage isn't it [21:27:08] [1/2] The arguments aren't available in the `sourceToDOM` bit which is why it can't be done there. Once this function returns, the arguments are added to the `data-mw` attribute of the HTML which is where we grab them from [21:27:08] [2/2] https://cdn.discordapp.com/attachments/407537962553966603/1413636592559456256/image.png?ex=68bca72b&is=68bb55ab&hm=5dff4e6f76b66fc1fa1a85c633bc00f00dae33b0096f22c2a0e70d2a085adffd& [21:27:37] Oh [21:27:50] https://github.com/OAuthority/PortableInfobox/blob/parsoid-patch/includes/Parsoid/PortableInfoboxDOMProcessor.php#L31 we snatch them from here [21:28:13] but it looks like at that stage Parsoid isn't doing anything with tags [21:28:15] Yeah I see that [21:28:47] Do you think injecting these arguments back into the frame would help [21:32:48] I have no idea; I've been trying to see what other extensions are doing but there's only a few and none of them are doing something as complex as magicking params out of thin air like PI is doing [21:34:19] [1/2] It's going really great for everyone else [21:34:19] [2/2] https://cdn.discordapp.com/attachments/407537962553966603/1413638400304484402/image.png?ex=68bca8da&is=68bb575a&hm=5ce1b128fe65f525bc21edf9fe85c9f706653d9b829f515e39d313c2d06b9124& [21:38:39] its laughable [21:40:27] Fandom evidently has solved this issue though so it is clearly possible [21:53:32] When I change into {{#tag:infobox}} it works... hmm [21:53:59] yeah that was the suggested fix by WMF in the first instance [21:54:11] Yeah [21:54:24] not sure I like that but if all else fails thats what people will have to do Ig [21:54:56] (but I don't understand why that works and using a doesn't [21:55:01] if anything it seems like poor design [21:55:54] I mean without your patch {{#tag:infobox}} doesn't work either but [21:56:16] oh [21:56:28] I wonder why {{}} is being treated differently? [21:56:31] The reason why it works I guess is because the arguments get replaced before it gets to postprocessing? [21:56:48] Before the XML even enters the PI processor [21:57:33] No need to worry about accessing arguments when they have already been replaced [21:58:01] I wonder if i pass it to $api->preprocessWikitext() first [21:59:29] https://cdn.discordapp.com/attachments/407537962553966603/1413644734374740139/image.png?ex=68bcaec0&is=68bb5d40&hm=c938eeb8e311d57055c39254c487b8e0d30f60d0d6702503de03f1f4f380ecd9& [22:01:41] What does your template look like using {{# i'll see if I can find anything there [22:01:59] [22:02:15] I don't have the branch deployed in production but that's what the template looks like [22:08:11] tried but i couldnt get it to work [22:08:19] i forgot when i requested for a url change [22:08:30] GrampaSwood was cool username [22:08:34] anyways i'm gonna add a [22:08:35] uhhh [22:08:40] the BEe Queen theme [22:10:54] Yeah, something is happening way before sourceToDom is hit which replaces the variable in the $src with whatever was passed to the extension tag handler hmm [22:13:15] Yeah [22:13:56] It feels... risky because someone can just break the entire infobox by using /format/data/infobox in an argument [22:15:57] But I mean who tf does that [23:12:39] brb, updating critical infrastructure just to do that /j [23:41:49] Like I just send my wiki link? [23:44:30] My tabbbers and infobox imported from fandom is like broken [23:45:14] https://botsandmuskets.miraheze.org/wiki/Bots_%26_Muskets_Wiki. And this is the fandom https://bots-muskets.fandom.com/wiki/Bots_%26_Muskets_Wiki [23:45:21] What should I do [23:45:25] To fix this [23:48:52] It worked fine for my other wiki , where I ported it to wiki oasis