Hi. When can we expect the moderation features?
Topic on Extension talk:CommentStreams
I just merged a new version that supports comment moderation. Please feel free to test and provide feedback.
I tried it out and the moderation works wonderfully. I can't wait for future features. :)
Excellent!
If you would like to test the comment voting feature that I'm working on, I have a patch in gerrit that you can try out: https://gerrit.wikimedia.org/r/#/c/357402/. You can enable the feature by setting $wgCommentStreamsEnableVoting = true; You will need to run the update maintenance script to add the vote table to the database. Thanks!
Thank you. I tried your modifications out and it works. The only problem with it is that you can only vote to the OP comments. You can't vote to the replies. Unless this was intentional, then everything seems to work fine.
Also, I did notice an other thing while I was testing the comments before I tried out your patch. When I make an OP comment and then I make replies to it right after I can't delete the entire comment thread I made even though I have $wgCommentStreamsModeratorFastDelete set to true. It only gives me the edit option. I have to reload the page in order to delete my OP comments with replies. After reloading the page the delete button apears.
Thank you for testing out voting. Yes, we intentionally only added voting to the main comments, not the replies. We may add voting on replies as an optional feature in the future, but we didn't want to clutter up the interface too much. The use case that we needed this for was strictly for voting on the main comments, with the replies being a chronological discussion of the comment. You could sort of think of this like stack overflow, with the page being the question, the comments being the answers (which can be voted on), and the replies being comments on the answers.
Thank you for the bug report on fast deletion. I will fix that.
Ah, alright. Also, I have two questions. I've seen the suggestions being made here:
And here:
Are you planning to include those too in a future release?
My other question is when I try to comment it takes some time to save the comments. Will that be improved in the future or is that something that cannot be fixed due to how the extension works?
Thank you for the feedback! I have merged the change to add comment voting.
Regarding the other items:
- Time to save comments: I have noticed that if Echo is installed, it takes additional time to save comments. If Echo is disabled, comments can be saved very quickly. I don't see anything in the CommentStreams code to account for this additional time. Perhaps the notification code could be transferred onto the job queue.
- Permalinks: This should be straightforward to implement.
- Editing tools for comments: Comments can contain wikitext, so styling is possible. Perhaps advanced editing tools could be added in the future (wikieditor, Visual Editor).
- SocialProfile avatars: I have not had a chance to look into what it would take to implement this. It is a possibility.
- RecentChanges: This seemingly small change turns out to be more difficult to implement than I had originally thought.
I will try to get to the first two items on the list relatively soon. It is unlikely that I will have a chance to work on the last three any time soon, but patches are always welcome.
Btw I manged to figure out how to use the SocialProfile avatars for your extension. I added the following code under public function getJSON() { in /CommentStreams/includes/Comment.php:397:
$user_id = $this->wikipage->getOldestRevision()->getUser(); $avatar = new wAvatar( $user_id, 'l' );
I also modified the following code in /CommentStreams/includes/Comment.php:405 from this:
'avatar' => $this->getAvatar(),
To This:
'avatar' => "/images/avatars/{$avatar->getAvatarImage()}",
Currently it replaces the Semantic Avatars completely, but I'm sure you could able to figure a way to switch bettwen them with a configuration variable or something.
Wow! That was easy! Yes, I could probably check for the presence of the SocialProfile extension and add that code optionally. I've added a task to the CommentStream workboard (https://phabricator.wikimedia.org/tag/mediawiki-extensions-commentstreams/)for that.
Nice. Thank you. :)
I have merged two patches that add permalinks and that allow vote counts to be queried with Semantic MediaWiki. I have turned my attention to your report that saving comments is slow. I had thought that it might have to do with Echo. However, now I cannot reproduce that behavior. In fact, it is pretty speedy to save comments all the time (a couple of seconds at most). I only saw the delay the one time after you mentioned it, but there could have been something else going on at that time on the server. Could you please give me a little bit more information about what you are seeing? When you say it is slow to save a comment, how slow? A couple of seconds? More? Does this happen regardless of whether you have Echo installed? Thank you for the additional information.
Okay I tested the new version and the permalinks work fine. Although it would be nice if besides the pressing the escape button on the kexboard there would be an X button on the top right corner of popup window.
I also tested how much time it takes to save a comment and it is about 15-20 seconds. With echo disabled it is about 5-6-7 seconds. I was also thinking that besides Echo it might have something to do with using Javascript to display the comments maybe, idk.
Also I noticed that while the newest OP comments do get on top, but when someone replies to an OP comment that doesn't moves the comment thread to the top. I don't know if that's intentional or something that was left out.
Although it would be nice if besides the pressing the escape button on the kexboard there would be an X button on the top right corner of popup window.
Agreed. I had some issues getting the text field to show up at full width when I put it inside a message dialog using OOJS UI. I figured I would revisit that later.
I also tested how much time it takes to save a comment and it is about 15-20 seconds. With echo disabled it is about 5-6-7 seconds.
Wow. I typically can save a comment in 1 to 2 seconds. I saw it take 5 seconds with Echo enabled once, but now I cannot repeat that. I have created a version of CommentStreams that puts the echo event creation on the job queue. If I put that on gerrit, would you want to test it to see if it helps? The downside is that it takes longer for the notifications to be sent, because they could sit on the job queue for a while. I guess I could make it optional, but I want to see if it even helps your situation before I do. How long does it take to save a typical page on your wiki? Maybe something else is going on.
You are correct that we sort by the creation date of the OP comment, not the creation dates of the replies. That makes more sense for our use case, but details like that will have to be revisited as the extension gets more use. Again, that could be an option, but I hate to introduce too many flags to control options, making the extension more complex.
I could try out the job queue version that you are testing to see how it works.
About the page saves, the creation of a page filled up with text and images and with the comments streams enabled on it takes about 5-6 seconds. The save of editing that page takes about 1-2 seconds.
The creation of a page filled up with text and images but with the comments streams disabled on it takes about 4-5 seconds. The save of editing that page takes about 1-2 seconds.
Also, I wanted to ask what do you think about having bigger avatars next to the comments instead of inside the comment header? Example: https://i.gyazo.com/f759050d54f6fe852c72d470972a7063.png
This way people would be able to see their avatars better. Also, this a similar avatar layout to what other popular comment sections are using.
I also played around with the placement of the comment buttons in the inspect element tool. What do you think of this button layout: https://i.gyazo.com/5b75f266704353aea4374d07ec680871.png I also based this on the layout of other popular comment sections use.
OK, try this: https://gerrit.wikimedia.org/r/#/c/359505.
I tried it out and with your patch and it reduced the comment posting time from 15-20 seconds to 5-6 seconds.
Huh. OK, so I guess it really is the time it takes to create the Echo notification. And, did the notifications get sent correctly for you? If so, let me know, and I will merge.
I tried it out with multiple accounts but I did not get any notifications.
Did you try running the maintenance/runJobs.php script? The jobs are probably sitting on the job queue.
Oh, I didn't do that, but I just run the script and the notifications didn't come up even after. I tried making new comments and replies with different accounts and run the script again but still no luck. I still see no notifications.
That's odd. That worked for me, but it was annoying to have to run the script or wait. We do have a cron job that runs the jobs every hour, but I guess it depends upon how long you are will to wait to get notified. However, if you aren't getting notified at all, that's not good. Did you run maintenance/showJobs.php to see if the job queue was empty? If you switch back to the previous version of the extension with the same configuration, do the notifications start coming again?
Okay, so what I did now is re-installed the latest 3.5 completely. I tested the extension and the notifications are working with it. Then I applied the 359505 patch again to see if with a complete re-install the patch may work but the notifications didn't show even after run the runJobs.php script.
Also, I have a noticed that with the latest 3.5 version if I am user that doesn't have the moderation power to delete comments(csdelete) I am not able to delete my own comments. I get an error message saying "User does not have permission to delete the comment." I thought even if a user don't have moderation power they should still be able to delete their own comments.
Another thing I noticed with the latest 3.5 version that I only get notifications if someone replies to my OP comments, I do not get notifications if I just have a replies in a thread that I am not the OP of. I don't know if this is intentional or not but on other social media sites you usually get notifications on threads where you left replies when other people comment there too.
Thank you for your continued testing.
That is strange that the notifications are not working for you for https://gerrit.wikimedia.org/r/#/c/359505/. You could try checking the row count in the echo_event and echo_notification tables after you post a reply that should generate a notification and again after running jobs. That way you could determine whether the events are being generated.
Thank you for reporting the bug regarding deleting a comment. That was a bug that got introduced when I introduced comment moderation. It is now fixed. When fixing that, I renamed the csedit and csdelete rights to cs-moderator-edit and cs-moderator-delete to be more descriptive.
You are correct that it is not currently set up to send you notifications for any post to which you have replied. Currently it only sends notifications on replies to a post you authored and posts on pages on your watchlist. I'm considering adding a comment watchlist, so you can star posts that you want to be notified about replies on. I hesitate to increase the situations under which a notification will be sent without providing a way to mute those notifications.
I am now seeing the same behavior you are: notifications are not working reliably on the version where they are sent from a job. I do see the job being run from the job queue, and the events are added to the echo_event database table. Comparing those events to those created in the previous method does not reveal any obvious differences. But, the events are not generating notifications. I don't know enough about the internals of Echo to say if that is a bug.
But, I also noticed that there is a $wgEchoUseJobQueue flag in Echo. So, please go back to the master branch and try setting that flag to true. Thanks.
I tried the Echo flag, and I'm getting exactly the same erroneous behavior. The event is correctly being placed on the job queue and is then processed. I tracked the interaction as far as the user locator, and the correct users are being selected to notify, but they are never receiving the notifications. I believe this may be a bug in Echo.
I've made quite a few updates in the last week, and now using the $wgEchoUseJobQueue flag is working. It greatly improves the time it takes to create a comment or reply, and notifications are correctly being sent.
The 5-6 seconds to save a comment is comparable to the 5-6 seconds it takes you to save a new page (which is what CommentStreams is doing under the hood), so that may be as good as it is going to get for you. It only takes 1-2 seconds for our wikis for both. I'm assuming you either have a hardware limitation or have other extensions loaded that are causing the delay.
I agree that it would be nice if the avatar were larger. I'm not sure about moving the buttons, but I'll give it some thought.
Btw you said that going to straight to the comment from the links on Recent Changes page is a "seemingly small change turns out to be more difficult to implement than I had originally thought."
Since you implemented the permalinks now, would it be possible to put a Mediawiki redirect(for example: #REDIRECT [[Page_Name#cs-comment-11205]]) or a JavaScript redirect(For example: window.location = "http://mywiki.com/Page_Name#cs-comment-11205";) on the wiki pages of the comments in the CommentStreams namespace? That way every time someone clicks on the links on the Recent Changes page they would be taken straight to the comment.
There is another way I could implement a redirect, but I'm not sure I always want to redirect away from that page. At some point I want to revisit whether there's anything I can do to improve RecentChanges, but now I'm trying to knock out the low hanging fruit.
I just merged a patch that suppresses comment actions from Recent Changes and logs them to Special:Log?type=commentstreams.