[00:22:49] Anything else you need to be done with the puppet config? [01:27:55] originalauthority: idk why the bug happens though? [01:28:04] (also, mention my nick so i see it >_>) [01:41:46] @blankeclair I'm a bit confused really what the bug actually is [01:41:57] i've always seen the masthead even if the page doesn't exist [01:41:59] apparently non-existent user pages doesn't show the masthead [01:42:03] not sure why others aren't? [01:42:05] but like... non-existent user pages show the masthead in testing? [01:42:41] [1/10] ```php [01:42:41] [2/10] public function onArticleFromTitle( $title, &$article, $context ) { [01:42:42] [3/10] $userNameUtils = MediaWikiServices::getInstance()->getUserNameUtils(); [01:42:42] [4/10] $pageTitle = $title->getText(); [01:42:42] [5/10] if ( $title->inNamespaces( [ NS_USER, NS_USER_TALK ] ) && !$title->isSubpage() && [01:42:43] [6/10] $userNameUtils->isUsable( $pageTitle ) ) { [01:42:43] [7/10] $article = new UserPage( $title ); [01:42:43] [8/10] } [01:42:43] [9/10] } [01:42:44] [10/10] ``` [01:42:58] is all its doing and that would still result in a UserPage even if the page doesn't exist [01:44:14] I can't see fuckin shit on this discord updat [01:44:18] why all the text so small [01:46:26] yeah, idk why it'd break [10:31:10] [1/2] OK so I would explain what happen is that, only and ONLY when I clicked on an user page as an red link, as Claire elaborated in the task, the masthead is not showing but rather redirect you to creating that user page. [10:31:11] [2/2] {{mh:lhmnwiki}} has prevent red link activated, I will disable it soon to check that out [10:31:13]

[1/2] [10:31:13]

[2/2] Not the correct result? Use `!wiki page lhmnwiki` for a direct link or `!wiki search lhmnwiki` for a list of all hits. [10:32:58] my screen recording shows the masthead on a redlinked page though [10:55:42] [1/2] my theories is that those users without contributions will have this issue, not those who made at least just 1 edit [10:55:42] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1355133241186848940/2025-03-28_17-52-12.mkv?ex=67e7d1ad&is=67e6802d&hm=8e7b57082d95c4ed4e868bf78e24f80ce2877413011ef9030fe2067a4822a833& [10:56:03] wtf is that audio [10:56:30] is there something wrong? I haven't watch the video again [10:57:02] before you muted your mic lol [10:57:13] anyway, it seems like the problem is because of action=edit&redlink=1 on user pages [10:57:32] maybe we could perhaps install a hook that'd make it automatically redirect w/o action=edit on user pages? [10:59:04] I don't think so, when users try to create their part of user page they might get redirected indefinitely [10:59:43] only redirect back to viewing if redlink=1 i mean [11:00:38] make sense, hovering the create button don't apply the red link thingy [11:05:30] @originalauthority found the cause: going to User:Example?action=edit&redlink=1 is the bug [11:05:43] since that is the url that is provided when you go to redlinked user pages [11:09:54] [1/17] so the fix would be: [11:09:55] [2/17] ```php [11:09:55] [3/17] $wgHooks['AlternateEdit'][] = static function ( EditPage $editPage ) { [11:09:55] [4/17] $title = $editPage->getTitle(); [11:09:55] [5/17] // Bail if we're not in a user page [11:09:56] [6/17] if ( !$title->inNamespace( NS_USER ) ) { [11:09:56] [7/17] return true; [11:09:56] [8/17] } [11:09:57] [9/17] $context = $this->getContext(); [11:09:57] [10/17] // T13424: If we're going to a user page through a redlink, redirect to the non-action=edit version so that the user profile stuff is displayed first [11:09:57] [11/17] if ( $context->getRequest()->getBool( 'redlink' ) ) { [11:09:58] [12/17] $context->getOutput()->redirect( $title->getFullURL() ); [11:09:58] [13/17] return false; [11:09:59] [14/17] } [11:09:59] [15/17] return true; [11:10:00] [16/17] }; [11:10:00] [17/17] ``` [11:10:04] but: should this be a (configurable) feature of UPV2? [11:15:23] eh, we'll have that discussion alter [11:15:29] i'll go and push the fix [11:26:42] https://github.com/miraheze/mw-config/pull/5883 [11:27:11] fml it broke [11:30:08] try now :3 [12:22:49] not working yet but still appreciate :'3 [12:24:17] oh crap [12:35:58] can you give an example? :3 [12:46:42] This would also be fixed then by always ensuring NS_WIKI pages are known pages, right? [12:47:01] Because then you'd never end up on a create page from clicking a user page link even if it doesnt exist [13:14:55] that also works but is more hacky imo [13:24:13] [1/2] https://meta.miraheze.org/wiki/Talk:Custom_domains#Confusing_instructions_for_CloudFlare [13:24:14] [2/2] Someone finds our guide confusing. (I do too, but I also never read up on this) [15:43:28] That's very fair [15:44:29] I'll reply to it in the next day [17:45:37] [1/2] you see, since it is still the same as before, there are a few things to look at [17:45:38] [2/2] was it cache? or is it puppet? [17:46:00] but basically it didn't work [19:57:17] https://cdn.discordapp.com/attachments/1006789349498699827/1355269536785502259/image.png?ex=67e8509d&is=67e6ff1d&hm=fc0f8fe6fe1d320d179e9178299cc9e8b17b5f0d80e1e45871d33a30c5fac562& [19:57:21] [1/2] https://test.miraheze.org/wiki/Special:Preferences [19:57:22] [2/2] I seem unable to change my preferences as I cannot switch between tabs: [19:57:35] What went wrong? [20:12:20] Something [20:14:03] Oh hi Sherlock!! 😄 [20:15:11] Interesting [20:15:17] But really, It has been days, and I just cannot switch the tabs, not even when manually inputting the link to said tab [20:15:23] Why you breaking my poor testwiki 😔 [20:15:29] Not me [20:15:39] I bet others can't either? [20:15:47] It's only on Test wiki [20:16:41] Yeah i cant either [20:17:20] What did YOU do with the wiki ey? heh [20:17:33] Wasnt me [20:17:40] I blame someone else [20:17:55] I’m looking to see whats changed [20:20:21] Its working for me now [20:20:23] 🤷🏼 [20:20:52] [1/12] ```Explanation [20:20:52] [2/12] Understanding the problem [20:20:52] [3/12] The error message "Refused to load the image...because it violates the following Content Security Policy directive: "img-src..." indicates that the browser's Content Security Policy (CSP) is blocking the loading of an image from https://publictestwiki.com/w/load.php?modules=skins.vector.icons&image=language&format=original&lang=en-gb&skin=vector-2022&version=bcb7z. The CSP directive [20:20:53] [4/12] img-src defines the allowed sources for images. The requested URL is not included in the allowed list, hence the violation. [20:20:53] [5/12] How to verify [20:20:53] [6/12] You can verify this by examining the CSP header sent by the server. In Chrome DevTools, go to the "Network" tab, find the request for the affected page, and inspect the response headers. Look for the Content-Security-Policy header and its value. Check if the img-src directive is present and if publictestwiki.com or its related subdomains are explicitly allowed. If not, this confirms [20:20:53] [7/12] that the CSP is indeed blocking the image load. [20:20:54] [8/12] Suggested fix [20:20:54] [9/12] To fix this, you need to modify the server's CSP configuration to include publictestwiki.com (or more specifically, *.publictestwiki.com to include all subdomains) in the img-src directive. This can typically be done by adjusting the web server's configuration files (e.g., .htaccess for Apache, or the configuration file for Nginx) or by modifying the application's code if it dynamic [20:20:54] [10/12] ally sets the CSP header. [20:20:55] [11/12] For example, if your current img-src directive looks like this: [20:20:55] [12/12] ``` [20:21:12] [1/10] ```Code [20:21:12] [2/10] img-src 'self' data: example.com [20:21:13] [3/10] Use code snippets with caution [20:21:13] [4/10] You should update it to include publictestwiki.com: [20:21:13] [5/10] Code [20:21:14] [6/10] img-src 'self' data: example.com *.publictestwiki.com [20:21:14] [7/10] Use code snippets with caution [20:21:14] [8/10] Make sure to test thoroughly after making changes to the CSP, as overly permissive policies can introduce security vulnerabilities. [20:21:14] [9/10] Summary [20:21:15] [10/10] The error arises because the image URL is not whitelisted in the site's Content Security Policy's img-src directive. To resolve this, you must adjust the server's CSP configuration to include publictestwiki.com or its subdomains within the allowed image sources.``` [20:21:23] (That's the AI talking) [20:21:51] Yeah we didnt really need that, it was clear those were all CSP warnings [20:22:01] Ah okay [20:22:19] And i highly doubt that was the cause [20:22:30] I'll delete them again then [20:27:42] [1/2] @zppix [20:27:42] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1355277191792824391/image.png?ex=67e857be&is=67e7063e&hm=36ef4fd89174bc018f27ab6731f3b9df03fbf38ca179d3698a152047e3834709& [20:28:05] Do you also have this bar continuously moving? [20:29:54] No but I use old vector with no dark mode [20:33:20] hmm [20:51:56] `oo-ui-pendingElement-stripes animation` [20:52:06] rip js [21:11:31] Do you have that issue too Clair? [21:12:22] not on publictestwiki.com [21:12:42] ah okay, it's test.miraheze.org [21:21:00] yeah