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?

[...] I instead get into an infinite loop in the SessionManager code (which times out after 30 seconds) [...]

See also https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DrawioEditor/+/1160031

Saving SVGs should be possible with the latest version.

Thank you very much! Yes, "56.2 KBytes/seconds" looks like the speed I faced recently. Today I didn't experience this anymore. At least I now know I didn't cause this by my automation. Again, thank you.

First of all, my apologies for the inconvenience. I'd like to provide some context.

Thanks for the feedback. I have now merged the change.

@Dsavuljesku investigated this issue and found the injection of the DeletePageFactory to be the root cause. He has provided a fix at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CommentStreams/+/1159325

It looks like d.savuljesku's work to make CS "store agnostic" is where the problem was introduced.

Thanks for researching this. For BlueSpice we use CommentStreams + SMW 5 and didn't face any issues so far. I have seen the error message

Thanks for reaching out. Yes, @pyashchenko does no longer maintain this extension. I'll take it on my list.

Thank you very much!

The change I mentioned is not merged yet and even if it were, the functionality is disabled by default. So situation will not get worse for you.

@Thomas-topway-it Thanks for providing this patch!

Patch available at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SimpleSAMLphp/+/959995

There is a patch available at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PluggableAuth/+/1124093

Thanks for reporting this. As far as I can tell at the moment, this is not a dependency to BlueSpice, but to a "library" pulled in by composer (there was actually a small dependency in the JavaScript, but we fixed this today). There _are_ integrations into BlueSpice, but they should not cause issues.

Yes, the conflicting dependency versions are concerning. But until now we didn't expierence any issues with them. Probably because the SimpleSAMLphp classloader is only included during the login flow and not anymore once the user is logged in.

I couldn't find any occurence of utf8_encode or utf8_decode in any BlueSpice*, LDAP* of WebDAV extension anymore. Updated task description. Removing tags.

REL1_31 of Extension:LDAPProvider does not contain this code.

This as been done already