Sat, Nov 21
Great! I'm glad to hear that it is now working.
Fri, Nov 20
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.
Thu, Nov 19
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).
Thu, Nov 12
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.
Thu, Nov 5
Wed, Nov 4
Thank you for reporting this. I will have a look.
Tue, Nov 3
Sep 3 2020
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.
Aug 26 2020
Aug 23 2020
Thank you for reporting this, @Kghbln. Could you please test the patch to see if it fixes the issue? Thanks!
Jul 27 2020
Sorry for the delayed response. I was on vacation last week.
Jul 6 2020
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.
Jun 22 2020
There are two separate aspects of composer usage here: installing the extension and installing the libraries that the extension relies upon.
Apr 29 2020
Apr 14 2020
Great! The patch is merged, and version 4.7 is tagged and documented.
Apr 13 2020
Your last instructions for checking out the patch look correct:
Apr 12 2020
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.
Apr 11 2020
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.
Apr 10 2020
This fix is now available in version 5.3 of the extension. Thank you for reporting the issue and providing the fix.
Apr 9 2020
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?
Apr 8 2020
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.
Apr 7 2020
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?
Mar 17 2020
Nice! Thank you both!
Mar 8 2020
Feb 28 2020
@Markus.T Thank you for the report.
@Osnard Do you have any thoughts on this?
Feb 25 2020
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.