Thank you for reporting this! It has been fixed in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CommentStreams/+/709101.

Sure, that would be great. Thank you!

Resolved in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CommentStreams/+/649730

Good question. The treatment of talk namespaces as a special case has always been confusing. I'm going to add a follow up patch that removes the $wgCommentStreamsEnableTalk option. It is unnecessary, since talk namespaces can be explicitly included in $wgCommentStreamsAllowedNamespaces, and it only adds confusion to the logic and the configuration documentation. So 'non-talk' would be removed from that statement.

Great! Happy to be able to help.

I'm unsure of how you copied the content from your test wiki, but if there were 55 rows in your cs_comment_data table, it is possible that there are also 55 pages with the comment data in the CommentStreams namespace. If you navigate to the Special:AllPages page and select CommentStreams from the namespace dropdown an push the Go button, you will see the pages in the CommentStreams namespace. If you have added new comments since truncating the table, though, you will not be able to tell which pages are new and which are old.

Sorry for the delayed response. I'm glad that worked for you.

It looks like WikiPage::quickEdit() was removed in MediaWiki 1.23 (see release notes). WikiPage::doEditContent() was available as a replacement, but it has now been deprecated in favor of PageUpdater::saveRevision().

Ah, that's a shame. It is the type of error you would get if the database is not set up correctly.

Did you run the maintenance/update.php script to create the required fields in the database?

I'm glad it worked!

Thank you for the reminder, @CarolinaReidBangingRocks. The patch is now backported to the 1.35 an 1.36 branches.

Thank you for reporting this. I'm unable to see the issue at the link you provided, since it requires login, but I was able. to reproduce the issue locally.

This capability was added to MediaWiki core in version 1.36 with patch https://gerrit.wikimedia.org/r/c/mediawiki/core/+/665805/. See also T265263.

As noted above, composer is used to install the OpenID Connect library.

We ultimately decided that it was not a good idea for an authentication plugin to prevent authorization. The fix for this should be made in the LDAPAuthorization extension.

The definition of the behavior of $wgCommentStreamsAllowedNamespaces is in the configuration section. Further, this section states "<comment-streams /> enables CommentStreams on a page even if it is in a namespace in which comments are disabled".

I would be interested in transitioning some of the third party extensions that I maintain, for example: CommentStreams, CreateUserPage, DisplayTitle, EmailAuthorization, JSBreadCrumbs, OpenIDConnect, PluggableAuth, SimpleSAMLphp, and TitleIcon.

Thank you for the bug report. Please try out the patch and report back whether it fixes the problem for you. Thanks!

@tosfos @xSavitar This issue was introduced in patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CommentStreams/+/481669. Could you please take a look at it? Thanks!

With respect to the patch, my thought is that environments (like NASA's) where the wiki is only accessible from their enterprise network, their wikis could be configured to ALWAYS_REMEMBER. The default is the current behavior, CHOOSE_REMEMBER, which still allows the login form to be bypassed. For environments where the wikis could be accessed from public networks, it could be set to NEVER_REMEBER, or, if you trust your users, FORCE_CHOOSE_REMEMBER, which would force showing the login form and would allow users to select Remember Me.

The patch allows search on comment pages to be disabled. It does not address autocomplete of comment page names in the search box when search is enabled. I will leave the task open for now to investigate solutions for that.

The two patches are an untested experiment but might do the trick. It seems to me that the fix should be in PluggableAuth and LDAPAuthentication2, not LDAPAuthoriztion. @Osnard, what do you think?

Note the discussion at https://www.mediawiki.org/wiki/Topic:Vq9ay00v0kphuhdd.

I think it would be best to use the UserAuthorization hook for now. I have plans to do some refactoring. I don't anticipate that hook changing place, but I will leave this open until that is done. At that point, I will reassess whether it makes sense to have another hook.

@HenrikGebauer thank you for reporting and diagnosing the problem!

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: