Great! I'm glad to hear that it is now working.

OK, it sounds like you have a session error if it cannot find the state. You may need to try a different value for $wgMainCacheType or $wgSessionCacheType. As noted in the Known Bugs, CACHE_ACCEL may not work.

I believe that your issue is the first item under Known Bugs at https://www.mediawiki.org/wiki/Extension:OpenID_Connect#Known_Bugs. The redirect URL in your stack trace is https://my.domain.tld/index.php?title=Sp%C3%A9cial:PluggableAuthLogin, but it will need to be provided in the form https://my.domain.tld/index.php/Sp%C3%A9cial:PluggableAuthLogin (or whatever short URL is appropriate in your environment).

Thank you for reporting this, @NoxiousPluK. The bug you refer to was fixed in version 5.7 of PluggableAuth (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PluggableAuth/+/443339). It was not browser dependent, however, so it is odd that you only saw an error when Edge was used. But, regardless, if you upgrade, it should be fixed.

Per https://packagist.org/about#managing-package-versions:

Thank you for reporting this. I will have a look.

Thanks for the heads up!

This was originally a feature request for native search quite some time ago. But, the functionality does not property belong in the DisplayTitle extension, and there have not been subsequent requests for this feature.

Thank you for reporting this, @Kghbln. Could you please test the patch to see if it fixes the issue? Thanks!

Sorry for the delayed response. I was on vacation last week.

Thanks for checking, @Aklapper. @AndrewCampbell67 did discuss this enhancement request with me. I've unassigned it for now, but will reassign it to my volunteer account (@cicalese) once I have time to work on it.

There are two separate aspects of composer usage here: installing the extension and installing the libraries that the extension relies upon.

Great! The patch is merged, and version 4.7 is tagged and documented.

OK, T250109 is now resolved. Could you please test this patch again, @Krabina ? Thanks!

Your last instructions for checking out the patch look correct:

Sorry for the delay! It is now merged. I bumped the version number and tagged the release.

Thank you for reporting that! Please test the patch and give it a +1 if it fixes the problem for you.

In T246350#5926097, @Osnard wrote:

1. Case "Logout on IdP does not log out on Wiki, but only on SP": Well, die SP code does not destroy the Wiki user session automatically and I actually don't know how to implement that. We can not ask the SP at any "UserLoadFromSession" if he is still logged into the SP, @ccicalese, can we?

It was just good timing :-) I had just started working on it before you created the task. Thank you for testing! It is now merged and tagged as 2.0.

I had just finished implementing with a config variable, so if that's still ok, we'll keep it that way. Please test and make sure it works for you.

This fix is now available in version 5.3 of the extension. Thank you for reporting the issue and providing the fix.

Yes, agreed. the call to Title::makeTitleSafe was only intended to check if the preferred username could be used as a valid username. It was not intended to perform any lasting modification to the value. The conversion of the first character of the username, if necessary, is done later when the user is created. It is not clear to me why that is not happening successfully for you. What other configuration are you doing for PluggableAuth and OpenIDConnect?

OK, I did some testing with this. The current code works for me in a similar situation. I use the email address as the source of the preferred username. I have tested with lowercase email addresses, which result in a lowercase preferred_username. That preferred_username gets correctly converted to have its first letter uppercased when the user is created. I'm curious why that conversion is not happening for you. What software versions are you using and what configuration? I'm not averse to the requested change, but I want to be sure that we are not masking another problem.

Thanks for catching that. I will submit a patch. Do you have access to gerrit to test and +1 the patch before I merge it?

Nice! Thank you both!

@Markus.T Thank you for the report.

@Osnard Do you have any thoughts on this?

Per https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/4505, the problem was invoking wfLoadExtension('CommentStreams') after enableSemantics(). When the order is reversed, it works. The documentation at https://www.mediawiki.org/wiki/Extension:CommentStreams has been updaated to reflect this.