In T363037#9750588, @gerritbot wrote:

Change #1024859 had a related patch set uploaded (by Jack Phoenix; author: Jack Phoenix):

[mediawiki/extensions/HelpPages@master] Looks like a Title is passed to HelpPages#helpPageExists when called from SkinTemplateNavigationUniversal hook handler

https://gerrit.wikimedia.org/r/1024859

In T361920#9692142, @Aklapper wrote:

This seems to be about https://www.mediawiki.org/wiki/Extension:GlobalUserrights .

Indeed.

Many thanks to @Ciencia_Al_Poder for helping me out with this!

In T144658#2979064, @lcf119 wrote:

It seems like all that has happened is that - has replaced +, as when a user joins/leaves, - is displayed regardless.

Indeed. Something I failed to understand back in 2016 was that the appropriately named MediaWikiChat.flashJoinLeave method is called for both cases: when someone joins AND also when someone leaves the chat. Its internals do not change depending on the action type, it always performs the same logic.

@Paladox seems to have taken care of this in be12f3c79e57116dd75049c2979ca26e05fba1ca (thanks!).

Now fixed in master.

Only a bit over a decade later, this is now finally fixed. :)

CC'ing @Samwilson since you've recently committed to this repository with significant contributions.

In T361449#9675160, @Paladox wrote:

Thank you for reporting! Would you mind doing the patch on Gerrit and I’ll +2 it as soon as you’ve done it please?

Hopefully fixed with https://gitlab.wikimedia.org/ashley/mediawiki-skins-Wikimini/-/commit/f2dbec0f6f5e8b73505559156d43d37765afaff0 ; note that it relies on the content language (on the JS file) so sticking ?uselang=sv to the URL on the French site won't load the Swedish code, and likewise, appending ?uselang=fr won't load the French code on the Swedish site. If the language code is neither fr or sv, the French (fr) code is used as a fallback. Oh, and as per SkinWikimini.php, the Swedish site's configuration file is assumed to have define( 'WIKIMINI_PROJECT_UID', 'sv' ); in it but as per my inline comment on that file, changing that is easy enough.

Assuming this is about my fork of the Wikimini skin (ping T356324 etc.) ...

For PrivateDomains, SocialProfile and Video extension, as the maintainer I'd be more than happy to allow the tag, so please let me know what needs to be done for those repositories.

Fixed now, thanks for the report! 👍

This seems to originate from rEDRAdfd4fb2e73f4: Replaced full list with small notice on preview, show changes, and non…. With JS disabled, clicking on the Save draft button results in the URL action param being set to submit...and whaddya know, the code added in that commit explicitly checks for that value and lists the drafts only when action is not submit.

Thanks for the swift replies, @Ladsgroup and @Tgr; much appreciated! :) I didn't submit a patch to gerrit as there was essentially nothing submission-worthy; quite the opposite, I had to revert my futile attempts to unbreak Special:Contributions so that I could test out some different extensions which hook into Special:Contributions as well.

ArticleFeedbackv5 isn't currently WMF-deployed, though who knows, perhaps it will once again be someday. :-) In the meanwhile, I definitely could use a helping hand with this...I wished to implement this change in AFTv5 in a non-BC-breaking way but the code turned out to be somewhat convoluted and I don't have a 1.41+ test setup to test out this part. What I can definitely say is that everything I tried out ended up breaking things like Special:Contributions (!) and such, so, yeah. :-/

Per discussion on MW.org, +1. The method's been "deprecated" for almost a decade without being removed and there'd be a real use case for it, so let's simply revert that part of rEGTOfc9de92a6ae6: Refactor and add non-linear tours, with tests.

Looks like this got fixed in ede423c7c355f7c8541dc19f9c2d6d8146ecfaf5 back in May by @Umherirrender.

@Shirayuki seems to have addressed this in b8634f6106b3b10aec468e43630d9dfb0b571f87 back in early May. That said, it was not nor is not an issue since in practise the regexblock-exempt user right is used "internally" by the codebase to see "should we even try to see if this user can be blocked?" (includes/RegexBlockHooks.php, function onGetUserBlock). If the user has the right, they're exempt from RegexBlocks, and no error message will be shown; if the user does not have the right, the processing continues normally and if they're not blocked, no error message will be shown as they can then edit the site normally; if they're regexblocked, a regular-ish block message, similar to the one you'd get if you were blocked via Special:Block, is shown.

In T309052#9147964, @Krinkle wrote:

In T309052#7957030, @ashley wrote:

In T309052#7957014, @Jdforrester-WMF wrote:

Delighted to Decline this if people really are using it. https://wikiapiary.com/wiki/Extension:CodeReview last time I used it (and it worked) said no-one did, IIRC?

WORKSFORME currently, the list shows 12 wikis. […]

Should we un-archive the page at https://www.mediawiki.org/wiki/Extension:CodeReview?

Negref looks to be like a prime example of a very lightweight extension that needs almost no maintenance whatsoever. Having it converted to extension registration might've been the only maintenance it needed (+the associated cleanup, i.e. introducing a Negref PHP class instead of having two global functions).

Archiving the extension is a solution, but I feel it's the lazy one for when the issue is "there's a bit of bitrot and some things don't work quite right on the latest supported version(s) of MediaWiki".

Finally fixed in master. Thanks to @matmarex for all the help with this one! 👍 🏅

In T152865#9270832, @MacFan4000 wrote:

Noting that if this is not done by the time MW 1.41 releases, then compatibly with scripts such as mergeMessageFileList.php will break as extension registration is now required.

This may have gotten fixed a long time ago but in 2f5650a4f3c7ac1810151749996707e13fe097a9 I added some intentional checks for the "Show preview" and "Show changes" buttons and the extension works now as described in this ticket (for existing pages), and there's no point in creating empty drafts (T21737/ab188ba8181493be6f97843b1636e5d99900c09f), so closing this ticket.

Now fixed in git master by the afore-referenced commit. @sbassett, feel free to make this task public now; thanks!