This is definitely a different problem than before.

Steps to reproduce, for anyone else that doesn't speak Bengali (I could only find the page because it's Nahian's latest edit):

Not a bad idea, but the messages using {{FULLPAGENAMEE}} would actually have worked correctly if they used the global context from RequestContext::getMain()->msg( … ), they only don't work because they used wfMessage( … ) (which would previously fall back to the global context, but now it doesn't).

I listed every message in FlaggedRevs that uses {{FULLPAGENAMEE}} (or similar magic words, but there aren't any such messages), then looked at the code that uses them. It looks like all of the uses in FlaggedRevsHTML.php need to be updated, and everything else is already fine.

This patch fixes the message shown on the page history view (exactly following the original replication steps), but as I was reviewing it, I realized that the same issue is present in at least one more place: the "Checked" / "Pending" tooltip on the page reading view. (This is the only one I found, but I haven't tested the whole extension carefully.)

The path to api.php used by mw.ForeignApi is generated in the load.php request (ultimately it comes from ResourceLoader::getSiteConfigSettings), and the load.php request runs on the normal domain, and it's not aware of the shared domain path prefix (or the shared domain). Kind of like the problems we had in T371530.

"Badtitle/Message" only comes from one place: https://codesearch.wmcloud.org/search/?q=Badtitle/Message

Thank you for backporting the fix!

This is just a quick workaround. It would be great if you could have a closer look at the various margins and other spacing, and the other places in the code that use HorizontalLayout, and make sure everything looks right. I only know a little about CX myself.

Hmm, sorry about that. There's probably a simple fix, I'll have a look and propose a patch.

In T380260#10338997, @Nahian wrote:

I have already cleared my browser's cache. I have set a different password for the new account so that it does not match the previous account in any way. It doesn't seem to be a device-related problem to me.

By the way, DiscussionTools also displays an error when $wgLocaltimezone is not set. It's not exactly standard either: https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/ /c049828dcead354354d3ec777cffee6b91d7cff8/includes/Hooks/RegistrationHooks.php#27

The message is also wrong as it claims the user can view the revision even if they cannot.

11 patches during the past year indicates to me that CologneBlue is extremely stable. This is a very small number. I am struggling to find a single extension deployed on Wikimedia sites that has had fewer than that. (I found one tie: by my count the SiteMatrix extension, which implements a single special page and a single API module that haven't really changed in the past 15 years, also has had 11 non-bot patches last year. Other extensions that I thought would be trivial and requiring almost no maintenance have had more, e.g. Babel, InputBox, WikiHiero.)

Presumably this has been resolved by the subtasks.

onTempUserCreatedRedirect() sure looks like it should be using the primary database, seeing as the user has just been created. Let's try that first and see if it fixes the problem.

Potentially relevant logs, I didn't find anything obvious though:
https://logstash.wikimedia.org/goto/8c2a697b6d931e162825da7e4c701114
https://logstash.wikimedia.org/goto/0c28bad8e33e88bdcf8dee399088b735
https://logstash.wikimedia.org/goto/1281562fe77ebfb53a324a6d7f9e870a

I think there are two things happening:

• Locking the "Renamed user c4a36f15bc7798269081d4eaeca1c196" account somehow did not invalidate its existing login sessions (did not force it to be logged out). It's not possible to log into it any more, but since it was already logged in on your browser, you can still use it. Someone should try to un-lock the account and then lock it again, and see if that fixes it.
• Your browser must have a mix of cookies for the login sessions of the two accounts. I am not really sure how that's possible. Have you ever used some browser extensions or features to switch between the two accounts?

Everything is deployed and I tested it briefly with the &usesul3=1 parameter, things work as expected.

No, @Dringsim is right, and MediaWiki.org also has an override :/ The base message in MediaWiki for 'userlogin-remembermypassword' is just "Keep me logged in": https://gerrit.wikimedia.org/g/mediawiki/core/ /REL1_43/languages/i18n/en.json#379 (but it takes an unused parameter $1 that allows displaying the customized time).

Presumably it was some local developer setup problem, otherwise someone else would've complained.

Tested with username "MediaWiki default".

The duration has been restored at some point, probably long ago, and the login form currently states something like "Keep me logged in (for up to one year)".

This was fixed by https://gerrit.wikimedia.org/r/c/mediawiki/core/ /1030453 (3cf3b1e1049098dd89c892543fc5b5fd7ef527ee)

I'm afraid we'll never know what caused this problem in 2016.

Looks resolved now. No idea in which version it was fixed.

(I assume you'll want to QA this)

It will be somewhat improved by the subtask's resolution: markup like {{PLURAL:}} inside the messages will now appear correctly. The page will still be missing styles, causing some formatting like parentheses etc. to be missing. I'd like to repeat my suggestion of removing this customization from that message that no one sees these days. :)

Looks fixed by the subtask.

:D

In the end, we found a way to resolve this with just one simple fix to the tests.

Per discussion on the patch, particularly @Krinkle's comment here: https://gerrit.wikimedia.org/r/c/mediawiki/core/ /1087937/comments/025ac4d8_5ab8220c it seems that this isn't strictly necessary to allow unit testing, and we'd rather not complicate these checks further.

Thanks!

Thanks!

Resolved now, right? Or are you waiting for the MW release to close this?

Scheduled the MW config patches for today: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20241118T2100

See also T231376: Desktop link inspector popups flickers several times before it closes

(I submitted a patch at https://gerrit.wikimedia.org/r/c/mediawiki/core/ /1091844)

It seems that this is no longer reproducible (as far as I can tell, we only display this message when the form has not been POST-ed now), but it would still be nice to change this code, to avoid this bad pattern being copied elsewhere. (e.g. T309907)

It's actually PHP doing this. https://www.php.net/variables.external

This seemed like a known issue to me, and indeed it has been reported a few times in the past, but I like your bug report better, so I'll merge those into here.

There was actually a good number of translations with this problem, I fixed them: https://translatewiki.net/w/i.php?title=Special:Contributions&target=Matma Rex&namespace=all&tagfilter=&start=2024-11-15&end=2024-11-15&limit=50

Agreed, this seems like the expected behavior for any message that allows wikitext (and this message has wikitext links in it).

Declining per Krinkle. I guess we can hope that this was an isolated and Beta-only issue, until it happens again.

FWIW, I could see the issue when this task was filed, about 7 hours after the revert.

Revert merged. (I just realized it wasn't tagged with this task, oops.)

The change caused T379983, reverted.

@Umherirrender found a bunch of problems in extensions reported by Phan due to the new type hints. A couple of them seem like real bugs that would have also caused warnings, but they mostly occur in rarely-reached error handling code paths. Fixes here: https://gerrit.wikimedia.org/r/q/topic:message-params-phan

WMF logs show one deprecation warning coming from EditPage::getPreviewLimitReport.

I think this can happen when the itr_transcludedfrom field (a foreign key to page.page_id) points to a page that has since been deleted.

The problem is that the visual diffs check for the 'stashbasehtml' permission. It is needed to open the page for editing (so to speak) in the visual editor, but not to view a visual diff. Unfortunately both "visual" things use the same API to access data. I feel like there's another bug about this somewhere.