Thank you for reporting this! It has been fixed in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CommentStreams/+/709101.
Wed, Sep 15
Sat, Sep 11
Sure, that would be great. Thank you!
Wed, Aug 25
Jul 27 2021
Jul 26 2021
Jul 17 2021
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.
Jul 16 2021
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.
Jul 15 2021
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().
Jul 11 2021
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?
Jul 1 2021
I'm glad it worked!
Jun 30 2021
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.
Jun 17 2021
Jun 15 2021
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.
Jun 14 2021
Jun 9 2021
May 21 2021
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.
May 20 2021
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".
May 15 2021
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.
Apr 28 2021
Apr 9 2021
Mar 24 2021
Mar 23 2021
Thank you for the bug report. Please try out the patch and report back whether it fixes the problem for you. Thanks!
Mar 21 2021
@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!
Mar 2 2021
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.
Mar 1 2021
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.
Feb 24 2021
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?
Feb 22 2021
Note the discussion at https://www.mediawiki.org/wiki/Topic:Vq9ay00v0kphuhdd.
Feb 19 2021
Dec 29 2020
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.
Dec 4 2020
@HenrikGebauer thank you for reporting and diagnosing the problem!
Nov 21 2020
Great! I'm glad to hear that it is now working.
Nov 20 2020
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.
Nov 19 2020
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).
Nov 12 2020
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.
Nov 5 2020
Nov 4 2020
Thank you for reporting this. I will have a look.
Nov 3 2020
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: