Problem/Motivation
This is a followup to #81373: Allow option for comments to be completely flat (no threading in database). Copying the relevant comments here for simpliicity.
From RobLoach in #comment-21
When "Threading" is disabled, you still get the "reply" link in the Comment operations.
From andypost in #comment-22
#21 is only issue left here, also it make sense to check other code for possible optimizations when comments are not threaded
Like \Drupal\comment\CommentStorage::loadThread() does
For example:
1) no need to calculate thread and query it in \Drupal\comment\CommentStorage::getMaxThread()
2) and other places
Steps to reproduce
Standard install
Disable threading, /admin/structure/types/manage/article/fields/node.article.comment
Create an article
Add a comment
See the reply link.
Proposed resolution
Remove the reply link.
Remaining tasks
Patch
Review
Commit
Manual testing done in #17 and #22.
User interface changes
As it is:

As it to be:

API changes
No api changes
| Comment | File | Size | Author |
|---|---|---|---|
| #24 | 3214487-24.patch | 2.99 KB | paulocs |
| #24 | interdiff-13-24.txt | 1.22 KB | paulocs |
| #17 | After patch screenshot.png | 55.12 KB | manojithape |
| #17 | Before patch screenshot.png | 60.45 KB | manojithape |
| #13 | 3214487-13.patch | 2.87 KB | paulocs |
Comments
Comment #2
andypostInteresting, maybe it needs to add recalculation of comments changing from flat to threaded?
Comment #3
paulocsWhat if the user enable threading again?
Will be lost all old threading when disable and enable it?
IMO even if threading is disabled,
getMaxThreadshould be still calculated, not?Comment #4
vetal4ik commentedIt's just a small fix to remove 'reply' link from the comment field when threading is disabled
Comment #6
nishantghetiya commentedThe above patch applies successfully. need to update test case
Attaching screenshots
Comment #7
vakulrai commentedUploading a patch for failing tests in #4 and adding test coverage for the new configuration implementation.
Kindly review.
Comment #8
paulocsPatch adds tests to it and properly remove the reply link.
Moving to RTBC.
Comment #9
quietone commentedNice to see the progress here!
The Issue Summary shows that a remaining task of Review and I don't see a code review in the comments so I will start with that.
Since $field_definition is only used once, inside the following if statement, it should be moved to inside the if statement. I would put it directly before the line where it is used.
This needs to be clearer. Will the reader know what default_mode = 1 means? I certainly don't.
I don't think another functional test is needed. The test above this is testCommentLinks() and this new test is also testing links. I think the new assertions can be added to the existing test. The comment for testCommentLinks() should be expanded to include that testing with a comment mode of threaded and flat is also done.
Why is a forum test being changed? I was curious so I applied the patch, removed the fix and ran ForumTest. ForumTest passes.
This also needs a fail test.
Next to look at is the screenshots, in #6 and #8. Both of them show what I presume are flat comments with the link removed. If they are flat comment then that does show it is working. But we also need a screenshot of threaded comments to see that the reply link is still there and not accidentally removed. And the screenshots are easier to find if the IS as well, in this case in the User interface changes section. That section also needs to be updated because this issue is changing the user interface.
Setting to NW for the above items.
Finally, there is a patch and it is the review stage so updating the remaining tasks section of the IS.
Comment #10
paulocsWorking on it.
Comment #11
paulocsAttaching new patch that addresses #9.
I attached also an image with threading enabled to check if 'Reply' link is properly displayed.
Comment #13
paulocsForumTest must be changed because of
$this->clickLink('Reply');.The test failed locally as well.
Adding new patch and interdiff.
Comment #15
paulocsThis is a random fail.
See: #3214565: [random test failure] Random fail in BuildTestTest::testPortMany.
Moving back to NR...
Comment #16
manojithape commentedComment #17
manojithape commentedVerified and tested patch#13 on the drupal 9.3.x-dev version. Patch applied successfully and looks good to me.
Testing Steps:
Testing Results:
After applying the patch comment "reply" link disappeared.
Please refer attached Before patch screenshot and After patch screenshot images for reference.
Moving this ticket to RTBC.
Comment #18
quietone commented@manojithape, thanks for the detailed comment on what you did to test the patch! Great work. A patch that passes tests and is working correctly may not be ready for RTBC. It is also important to read the Issue Summary and comments to see what else may need doing before setting to RTBC. In this case, there is no comment on whether #9 has been addressed satisfactorily.
This isn't quite ready for RTBC. There is no evidence that a code review has been done on the latest patch and there is confirmation that all the points I raised in #9 have been addressed. Setting back to NR.
Comment #19
paulocsI forgot to write but patch #13 addresses everything pointed on comment #9. Except the fact that the forum test needs to be changed as well. I did a one line fix to the forum test as the reply link no more exists.
I'm also adding the pictures to the IS.
Comment #20
lendudeIf this change is indeed needed, it means we are changing something about how the forum module works. Are we okay with that change? Can somebody do some manual testing or maybe show some screenshots about how this effects the forum module?
Comment #21
paulocsI can explain.
When installing the forum module, it is created a node bundle called
Forum Topic. This bundle has acomment fieldthat by default has threading disabled. If we are removing the reply link, there is not theReply linkanymore. So if a user needs to add a comment to aForum topic, it is necessary to click onAdd new comment. Both links are from theCommentmodule and not from theForummodule.Comment #22
quietone commented@paulocs, thank you for fixing everything in #9, As a reviewer I do appreciate the screenshots in the summary.
I retested with the fix for ForumTest removed and indeed the test fails. Whatever I did earlier in #9 for testing was wrong. I applied the patch and read the code, particularly ForumTest. The comment above the change needs to be modifed.
This is no longer replying to a comment, it is adding a new comment.
Since a change is needed to the patch can we take care of this nit? It is tough to add this alphabetically but after CommentInterface would be better, I think.
I have tested forum comments with and without this patch and this does change the behavior for forums. Is that a problem? I don't know.
Currently, when viewing a forum topic with comments the reply link is present in each comment. When you click reply a new page, 'Add a new comment' appears with the comment you are replying to listed first. When you enter and save the comment it will appear at the bottom of the comments. That makes sense because threading is off. With this patch, there is only the option to 'Add new comment' at the bottom of the forum topic page.
I think a search should be made in the forums issue queue for anything related to this. And this change should be explained in the User Interface section of the Issue Summary.
Comment #23
larowlanSo the issue here is that by default comments in forums are flat.
See field.field.node.forum.comment_forum.yml
I think switching it to 'threaded' would be a BC break, so I think the change in ForumTest is correct.
The forum is flat, hence replying to comments should not be allowed.
Comment #24
paulocsThanks @larowlan
I attached a new patch that addresses comment #22.
Btw I didn't find any issue related to this issue in the forum module.
Comment #25
quietone commented@larowlan, thanks for that confirmation. I looked at that file and there is no mention of threading. After searching, I learned that it is 'default_mode' and the values are define in CommentManagerInterface.
@paulocs, thank you the two small fixes. And notably, checking forum for related issues. I would have been a bonus to find a duplicate.
That covers all the points from my previous review, which also included testing. I have noted the manual testing in the IS.
Off we go!
Comment #27
larowlanCommitted 1926ec3 and pushed to 9.3.x. Thanks!
As there is little risk of disruption here, backported to 9.2.x
Thanks
Comment #30
Anonymous (not verified) commentedI came upon this thread after recently upgrading from Drupal 8 to Drupal 9, and noticing the change of behaviour.
For my use case, this change is a regression, as it is a usability hit for screen reader users.
When relying on a screen reader (such as VoiceOver on iOS and Mac), there is no quick and easy way of identifying new comments when using threaded mode. In this case, you have to navigate by keyboard (or other gesture based options on mobile) through each and every comment in order to determine which are the new ones. You can't do a quick visual scan to spot the “new” indicator..
In flat view, you can simply use the keyboard or gestures to quickly navigate to the last comment and then move back through the list to find all new and unread comments.
The previous behaviour allowed for the best of both worlds - you could set comments to flat view, but still be able to reply to a specific comment and for the interface to indicate to others which comment you were replying to.
* For those who are unaware, most themes include a ‘invisible’ element in the comment template that is only seen and recognised by screen readers, and will, if applicable, give details of the comment that the poster has replied to - something in the form of “in reply to CommentTitle by Username”, where the comment title is also a link to that comment.
Now, people are back to having to guess at which comment you are referring to.
There is also the adjustment needed because screen reader users typically have a regular and preferred method of navigating webpage content, they assume that if a UI element which has been there for some time is now gone, it's most likely because either the site or their screen reader is misbehaving. In the short time since upgrading, I've had one experienced screen reader user contact me thinking that comments were no longer supported (yes, even though the comment form is on the same page, but they are used to finding and using that ‘Reply’ link). There has also been a slight drop in the number of comments posted to the site, which might be due to others thinking the same buts saying nothing.
And, yes, I am a very specific and niche use case here, as my site caters specifically to blind users. So, probably 90% of my site users are screen reader users.
I know that this change is unlikely to now be reversed, but I would definitely welcome any suggestions on how its implications might be addressed for my use case.
Comment #31
claudiu.cristea@Janner, could you open a new issue with your concerns and link it here?
Comment #32
rootwork@Janner there's now an issue requesting this feature to be restored: #3227091: Users should be able to reply to a specific comment even when threading is disabled
I would suggest copying your comment there if you can, as open issues will get a lot more attention than closed ones.
Comment #33
Anonymous (not verified) commentedThanks for the heads-up.