https://gerrit.wikimedia.org/r/1083337 should be backported to 1.43 LTS at the very least. It is no different to T290808 (CVE-2021-46148), even if it does not affect WMF.

This is happening because the .mw-editsection element does not appear on protected pages, and the JS in DiscussionTools tries to click the a element in that non-existent node: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/DiscussionTools/+/ec5a42d1e2e426d51e5c740bdfc455836af06260/modules/mobile.js#135

This issue was fixed in T403519 when PHP session handling was disabled in WMF production before this issue was fixed, causing it to break OAuth apps.

I'm pretty sure that you get a session cookie if you edit while logged out (regardless of if you have the new temporary accounts feature enabled or not), unless that has changed since 1.43. I think a reasonable approach to this issue, if WMF have concerns about using POSTSEND, is to allow third-party wikis to configure this without needing to edit the source code.

This doesn't happen with Vector 2022 (default Wikipedia theme), as the Vue search component shows the redirect target rather than the name of the redirect.

Trying to catch up on this. On Weird Gloop wikis, we're constantly finding that editors want to be able to select their own page images to show up on hover previews and in search, rather than relying on the algorithm to pick one. Usually, the most relevant image on video game wiki pages is in the infobox, so having a way to force that would be helpful. I think this has already been discussed, but I believe it would make the most sense to simply add a class similar to notpageimage called pageimage or similar that simply returns a score of 1000 or something (notpageimage returns a score of -1000), so that the first image designated with that class will always become the page image for the page. We're probably going to implement this in our own MediaWiki fork, but I can upstream it if it is deemed useful.

On Weird Gloop's wikis, we've actually backported Vector 2022's search into old Vector (we don't intend to switch to Vector 2022 in the near-term, but desire the new search functionality). Part of this has been implementing a change that allows us to show the names of redirects on the suggestion items.

I've uploaded a patch which changes the LinkSuggest extension to use the core prefixsearch API module, which in turn adds support for showing redirect targets as suggestions.

That looks awesome! The #invoke example looks good, but not the end of the world if it’s not doable as part of this ticket. Thanks for the hard work.

Hey @Bhsd, awesome work on this. Is there any scope for also implementing autocompletion for page links? I appreciate that this is something that might be better served by the scope of T300618, but perhaps a lot of the work you've already done would make this significantly easier?

I note that in T302623#8566372, it is clear that there is an intention to phase out PHP session handling. This seems like a hard blocker right now.

Just wanted to add an external voice to this task - we (at Weird Gloop) are observing "Math extension cannot connect to Restbase" on a regular basis on our hosted wikis (example link). $wgMathFullRestbaseURL hasn't been changed, so we're using Wikimedia's Restbase API for our rendering. We're considering running our own Restbase server if the instability seems to be related to WMF's infrastructure, but if there's a core issue with Restbase/the Math extension then this wouldn't do much for us. We'd also not really like to support Restbase going into the future, given that WMF is deprecating it.

Now that Turnstile is generally available, I've pushed a patch that implements it into ConfirmEdit. The code for it is very similar to ReCaptchaNoCaptcha, but I felt uncomfortable with inheriting anything from ReCap's classes given that it does have a couple of (mostly server-side API) differences, and T324925 would do a better job at genericifying JS-based captcha implementations. I tested the code on MediaWiki 1.40 across account creation, source editing, and visual editing.

Just adding my two cents here that as an external wiki farm, we'd also like to see user renaming support wiki farms properly, especially now that it is integrated into core. We use a fork of the Renameuser extension, but to upgrade to 1.40, it means that we're likely going to have to make patches to the core implementation instead.

Is there any interest in backporting the fix for this issue to 1.40 once reviewed & merged? I'm not sure if there's a formal process for requesting that, but it is seemingly likely to cause issues on more external MediaWiki installations than just ours.

In T341435#9015002, @Func wrote:

$wgHiddenPrefs[] = 'skin'; seems very broken, other skins would still register their features and preferences if they are not uninstalled.
How skins are managed in your setup? Are there any difficulties with simply only install the wanted skin and not using $wgHiddenPrefs?

I made an account on the beta cluster - this is how the page looks to me with JS disabled.

Hey @Jdlrobson, I just had a look at the page you linked on the beta cluster but I don't actually get the same as you when JS is disabled. However, I'm not logged in, so I'm wondering if that makes a difference in what you see on that page. Maybe try with an incognito window/logged out? (or maybe there's some other variable at play here)

In T336987#8888656, @abi_ wrote:

In T336987#8885001, @JaydenKieran wrote:

In T336987#8882370, @abi_ wrote:

In T336987#8871291, @JaydenKieran wrote:

@abi_ Hey! Translatewiki should have a pending invitation for the repo at https://github.com/jayktaylor/mw-discord/invitations.

Thanks accepted.

Thanks - although weirdly, GitHub seems to indicate that this is not the case (and the invitation has disappeared). Let me know if you need me to send it again. Cheers!

Hmm, you are right. The invitation seems to have disappeared. I'm not sure. Can you resend the invite again? Thanks.

Another request, can you update the documentation for messages like discord-blocktimeformat(https://github.com/jayktaylor/mw-discord/blob/master/i18n/en.json#L24) that use the PHP date time format, to link to the PHP documentation? That should make it easier for translators to understand what each character/symbol does.

FWIW, ?action=purge on https://en.m.wikipedia.org/wiki/Korean_drama appeared to fix the issue on that page for me.

I'm assuming that the full-width toggle is supposed to be hidden when JavaScript is disabled because that's what happens if you just visit other pages (like article pages, or user preferences)

In T336987#8882370, @abi_ wrote:

In T336987#8871291, @JaydenKieran wrote:

@abi_ Hey! Translatewiki should have a pending invitation for the repo at https://github.com/jayktaylor/mw-discord/invitations.

Thanks accepted.

Is there a reason that "will not be carried over" is used here instead of "will not be attributed"? I'm a native English speaker so I can't really speak for those who have it as a second (or third) language, but it seems like it makes sense to remove any potential confusion and ambiguity with the wording - especially for those people. Obviously this isn't just limited to the mobile site/app, but I'm not sure where else this is being discussed.

@abi_ Hey! Translatewiki should have a pending invitation for the repo at https://github.com/jayktaylor/mw-discord/invitations.

In T332805#8857049, @Milimetric wrote:

Is anyone talking/thinking about how these names are going to look in regular use? I was reading the updates here and couldn't help but think about a discussion thread or revision history where you might see activity from different temp users and accidentally group it together, like:

• <<Totally nice reasonable thing>> ~~~~ !2023-12345
  • <<Really Nasty Mean thing>> ~~~~ !2023-12355
    • Hey, @!2023-12345 this is your last warning before we block your account ~~~~ SomeAdmin

I wonder if some more randomness in the layout of the temp numbers would help, like !2023-12-355 and !2023-123-45

Looks like @Rxy has a revert patch here: https://gerrit.wikimedia.org/r/c/operations/puppet/+/535987/

I'd like to see this. We use CodeMirror (and LinkSuggest), but the latter doesn't work with CodeMirror.

I think that regardless of how effective CentralAuth's global locks are, implementing something in the GlobalBlocking extension that allows users to be blocked would be worthwhile, especially for independent wikis who don't utilize CentralAuth.

@Volker_E Well, anywhere that the help buttons are used in conjunction with a form, whether that be a custom gadget/script that utilises OOUI or an extension. Whenever I've used forms elsewhere (outside of MW), tab has cycled through each input on the page, not any guidance or help text. It's a slight annoyance from my perspective that there are extra key presses required to cycle to each input, especially when there is a form with a lot of inputs and each have their own help buttons.

@Volker_E Can we set the button to an access key instead to retain that accessibility? It just doesn't make a whole lot of sense to cycle to the help elements on tab, especially when you're trying to quickly fill in a form. Alternatively, another solution where we can keep this functionality but move it away from tab, as I know access key can behave differently per browser.