Unfortunately, there is no official issue tracker for that extension. I'll request one here in Phabricator and then monitor it. My apologies for answering this late.

Bumping dozens or hundreds of versions in extension.json needs automation. And such cases also don't need code review. We didn't want to cause problems and will adapt our tooling. This will take some time though. I guess the way the "libraryupdater" tool does it is the way to go then?

Thanks for raising awareness to this topic. And my apologies for the inconvenience.

Patch at https://gerrit.wikimedia.org/r/c/VisualEditor/VisualEditor/+/1311819

Is this maybe related? https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageForms/+/1306378

I believe there are two possible solutions:

Fix available at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageForms/+/1283669

Probably related T384133

If someone is logging in using Auth_remoteuser, does the fix still allow them to successfully log in?

Yes, this change does not break any general functionality. When one of the build in mechanisms (e.g. $wgAuthRemoteuserUserName or the UserNameSessionProviderFilterUserName hook) return a valid user name, the session will be properly established.

Sorry for keeping you waiting. I'll check next week and provide an answer

Thanks for reporting! I have created an internal ticket ERM45366 and scheduled it for the next patchlevel release of BlueSpice. Will probably be early 2026 until it is done.

@sbassett Thanks for reviewing. The failing CI tests seem to be unrelated. Looks like a general incompatibility to a DB schema change in MediaWiki Core at master. Could we get this change cherry-picked and merged into REL1_43 as well?

Apparently, it is sufficient to bump the library version to a new minor. None of the interfaces used by the extension has changed.

Sorry, my bad. As mentioned in the discussion on the change, this object member is not required, as it is already declared in the base class. So, yes, one can safely remove this line.

Nevermind, thanks for confirmation.

Hint: I am not entirely sure if the original check is still valid in modern MediaWiki. Description says

Our parent class provided a session info, but the $wgGroupPermission for creating user accounts was changed while using this extension.

AFAIK, currently a change in $wgGroupPermission will not be possible anymore once GroupPermissionsLookup has been initialized. So I don't see how this situation can happen in MediaWiki 1.43+

FYI: I have created https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Auth_remoteuser/+/1188293 as an proposal. Have set it to WIP, as I didn't have time to test it yet. Open for discussion.

because I want to grant read-only access to remote users who do not have a MediaWiki account. When such a user tries to log in, the same memory error appears.

I have provided a patch. And a version 9.0.1 will be published soon.

Thank you. I can not believe I missed this line. How embarrassing.

Potential fix at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Auth_remoteuser/+/1181142

I have created a patch at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Auth_remoteuser/+/1181135

As far as I can tell this is not required anymore, as modern versions of Parsoid do not need Cookie-Forwarding anymore.

This seems to be a duplicate of T369974, isn't it?

This should be fixed in the meantime

The latest version of Extension:DrawIOEditor can save SVGs. Can we close this ticket?

In the meantime 9.0 has been released. Can we close this ticket?