Thanks for the report. This is sorta known (to me), but there wasn't a ticket for BlogPage prior to this, let alone any of the other extensions also impacted by this change.

"Improve documentation" type tasks are basically neverending...but I'm still gonna close this.

Closing this because MW 1.35 reached its end-of-life in December 2023.

Please try out the aforementioned patch to see if it fixes this issue for you.

In T405988#11227476, @SomeRandomDeveloper wrote:

Nevermind, I just realized that running UserStats:updateUserStats.php fixes it.

In T403924#11159143, @SomeRandomDeveloper wrote:

In T403924#11158969, @ashley wrote:

LGTM with the same caveats/question as in T403923#11158964.

The module already depends on jQueryMsg since 505a46a71594b8302677ff650aa0fa3473604b7a.

Ah, awesome; I didn't check, as you can tell. ;-)

In T403923#11159001, @SomeRandomDeveloper wrote:

In theory you do need to, but in this case, there is already an indirect dependency on jQueryMsg through mediawiki.api. Though of course, it would be safer to still add an explicit dependency on jQueryMsg.

Updated patch with jQueryMsg as a dependency:

T403923-2.patch2 KBDownload

Awesome, feel free to push this to gerrit whenever you're ready! 🎉

Closing per T155264#10833050.

LGTM with the same caveats/question as in T403923#11158964.

Patch LGTM (not tested though, but I trust you), though I wonder...do the formats like .escaped(), .parse() etc. work just like that, i.e. don't you need to declare a dependency on mediawiki.jqueryMsg? (I think at one point you needed to, but that was literally years ago and core probably has changed a fair bit since that.)

^It's something. It helped a bit that I had the most of it already written for a different extension (VoteNY), I just had to adapt said uncommitted code a bit for ARE. :-)

Would be very interesting to see what's going on in the ratings DB table...one thing is that unlike e.g. the core page table, the ratings table lacks a UNIQUE INDEX which'd enforce that only one key-value pair with the same data can exist.

First off, full disclaimer: I didn't check all of the 2014-era commits. That being said, I feel pretty confident in saying it's a feature that may have once been planned for ARE, but was never written, and the codebase has no special handling whatsoever for a value called category.
The Rating class only cares about codename, name, img and link -- that's all.

This is because internally ConfirmAccount uses PHP's str_word_count (line 141 of /includes/business/AccountRequestSubmission.php as of the master version of the extension), which is known to be buggy for UTF-8 characters.

Done by @Fomafix in 357fd5545e4df29995827a571cad26352e56c131.

As far as I can see, @MarkAHershberger fixed this already back in January in 6efc92baa2ee2ab5a25451c3db101a5e6e781ae5 while working on T379300.

Patch got merged back in January, so I think this is now fixed.

In T402002#11089361, @SomeRandomDeveloper wrote:

In T402002#11089355, @ashley wrote:

In T402002#11089349, @SomeRandomDeveloper wrote:

Patch:

LGTM, nice catch! 👍

Would you be able to +2 it if I uploaded it to gerrit shortly?

So this is some strict SQL mode thing; WMF CI enforces stricter SQL stuff than what many installations in practise do, and the same appears to be true of my dev environment, and it goes without saying that Aaron, Dave & co. weren't very strict at all about these sorta things way back in the early-to-mid 2000s...

In T402002#11089349, @SomeRandomDeveloper wrote:

Patch:

Not reproducible on current master on MW 1.43 at least when using Chosen (which is nowadays the default, instead of the treeview-based previous thing). With Chosen, if I choose categories "Foo Bar" and "Baz", they are shown in the summary with the localized category name as their prefix, but that's it - no reference to {{PAGENAME}} anywhere, and even the PHP source has only one reference to it in a regex.

Being bold and assuming this was fixed back in 2016/2017 by @tosfos' 363d0e09353a79c81c22a09800255a4722af0aea, thus closing this task.
Feel free to reopen if it's still happening on current master with a currently supported version of MediaWiki core. (Note that as of 64834d8a5145c610fd3867807705765bfbf37677 the Chosen-based selector instead of the treeview-based one is used by default.)

The CategoryOnUpload extension got archived in very early 2019. As of today, SelectCategory's support for Special:Upload should be decent. Please make sure you're running MediaWiki 1.43 (or newer) and update your copy of SelectCategory to git master to pick up the latest changes. Please feel free to report back with any and all issues you may still encounter. Thanks!

Closing this as unactionable, since:

• this ticket hasn't seen any action in over a decade
• the wiki mentioned is gone
• I wasn't able to reproduce this locally last year when I worked on cleaning up and improving SelectCategory

This sounds like a file permissions related local issue.

Fixed in this patch.

Now done.

So I was able to partially confirm this on latest master of ProtectSite w/ MW 1.43.0. I'm able to edit pages just fine but the account creation part indeed fails and throws an error message, despite that regular users should be able to create accounts.
The bug is most likely in ProtectSite#setup, likely related to these two lines:

			$wgGroupPermissions['*']['createaccount'] = ( $wgGroupPermissions['*']['createaccount'] ?? false ) && !( $prot['createaccount'] >= 1 );
			$wgGroupPermissions['user']['createaccount'] = ( $wgGroupPermissions['user']['createaccount'] ?? false ) && !( $prot['createaccount'] == 2 );

since changing the latter conditional to $wgGroupPermissions['user']['createaccount'] = !( $prot['createaccount'] == 2 ); does seemingly fix this issue, but I think it also reintroduces T273687.

Already fixed on master in e52ad4b712ed392901df75dca348b54b0807c57b in late March 2025.

What kind of a(n) (no-JS-friendly) alternative do you propose?

I suppose this is yet another instance of T69959.

Thanks @Seb35 for your work on this! 👍 🎉

In T396956#10918331, @matmarex wrote:

I suspect that what you really want is to set https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-padding-top on the html node in CSS (equal to the height of the sticky header), and remove that JS code entirely.

In T395949#10887814, @sbassett wrote:

It's really more about finding maintainers than about the actual usage of an extension or skin. The current Developers/Maintainers page is pretty laughably out-of-date and flawed in other ways.

Indeed, but at least it's translated into various non-English languages. ;-)

@SomeRandomDeveloper: Very nice find and detailed write-up and functional patch, thanks for all this! 😍 Patch is fine to land as-is, but mandatory nitpicks:

• might be worthwhile to bump the extension's version number in extension.json
• likewise, I'd suggest making the minimum required MW version 1.43 as (per mw:Version lifecycle) it's the current LTS version and the namespaced Html class is available there; otherwise I'd suggest 1.39, which is the legacy LTS version, but the namespaced Html class is not available there; either way, 1.40.x series reached their EOL about a year ago
• if going with the 1.43 suggestion, might add a use MediaWiki\Parser\Sanitizer; statement to the top of the file as well as the Sanitizer class is namespaced in MW 1.43(+)
• I'd suggest decreasing indentation on patch lines 71-76 by one

In T394564#10841952, @matmarex wrote:

There are a few more extensions maintained in Gerrit, I'll submit patches for them as well

Thank you for this, and thank you for setting a good example to other people and teams on how these kind of changes should be handled! ❤

In T394590#10832985, @SomeRandomDeveloper wrote:

Thanks for the quick response and for merging my patch! Would it be possible (or necessary?) to backport this patch to other branches as well? Especially REL1_39, REL1_42, REL1_43 and REL1_44, since those versions of MediaWiki are still supported

Thank you for the detailed write-up, and, naturally, for the patch as well! ❤ I've applied it against gerrit master and merged the patch (rEWCTbee952ba5da2: [SECURITY] Prevent reflected XSS via the linkstyle attribute by using the Html…).

In T278033#10769139, @Seb35 wrote:

• The visual editor is working fine but there is a warning "Your skin is incompatible with VisualEditor. See https://www.mediawiki.org/wiki/Extension:VisualEditor/Skin_requirements for the requirements.", I may check in more details how to improve this integration.

I no longer have a 1.39 box to test with, but this might be resolvable with this VE patch (which was backported to REL1_39 as well). If memory serves me correctly, I did have VE working under 1.39 just fine; it definitely works under MW 1.43.0 with no related changes to the skin. (For 1.43, there are two tiny PHP-level changes needed to get rid of some deprecation notices and whatnot, and a whole bunch of LESS changes related to the .background-image mixin to unbreak the skin for 1.43.0; again, as you're targeting 1.39, it should just work.)

In T159062#6684265, @Dinoguy1000 wrote:

There are already too many editors out there who believe redirects are "bad"; adding this functionality to core would only validate that view by providing them with a maintenance report which existence implicitly claims that certain redirects are categorically bad (similar maintenance reports indicate problems that need to be fixed, providing an obvious parallel argument).

Hopefully it's a bit better now. :)

Raising priority now that the Google Charts API is gone for good and that part of Special:SiteMetrics is broken (yet it still pings Google's servers, of course, until this ticket is resolved...).

No activity in almost two years now and I was never able to reproduce this issue, so unfortunately closing this. Please feel free to reopen if the problem persists under the current LTS release (which is 1.43 as of now) and you have more details on the issue. Thanks!

Confirmed. This is my fault, I introduced this bug in b9c7ebe0556434b848d02101e9b8cec9288d8208 while fixing T363693.

In T390590#10694924, @Dreamy_Jazz wrote:

I'm not sure exactly the cause. The test is not failing for me locally when I have the Refreshed skin installed. I have a feeling this is a problem caused by another extension.

Some updates happened in b53a6d8e7f011b65cf85ba5fa35f0c01e345ffd1 and 0e6c9c2fbe58471a8afb9f5a4504b42deb87ec88 in late 2019.