Drupal core allows for users to select their own comment settings, I don't think it should. Putting this as a bug because it's possibly the worst usability issue in core that there is.

1. There are eight possible options presented to the end-user (of the site, not just the administrator) if these settings are turned on, possibly twice on every page.

flat expanded oldest-first

flat expanded newest-first

flat collapsed oldest-first

flat collapsed newest-first

threaded expanded oldest-first

threaded expanded newest-first

threaded collapsed oldest-first

threaded collapsed newest-first

+ infinite variation when number of comments is taken into account

2. http://www.lullabot.com/articles/drupal_usability_comment_configuration

3. I think a lot of people would like comment settings per node type (so threaded for blogs, flat expanded for forums, that sort of thing) - allowing users to override this would get very complex.

4. I've never ever seen a drupal site using this.

5.

> users.mode
> > users.sort
> > users.threshold

These are/were used by comment.module to store user preferences.
Probably can be dropped too, they are all 0 on d.o for all users.

This is an initial patch - removes the comment controls forms and theme functions, but leaves comment_get_display_setting and the db columns untouched. This is the kind of thing that could be done at the theme level by a contrib module, so those columns could be left in the database for one release cycle to provide an upgrade path. Also comment_get_display_setting would have to be refactored to take into account node types, which is probably another issue, and no patch for that today.

The one exception to this is maybe number of comments per page, I can see it being handy to set that and it can be done with very little cruft, but it should probably be a user account setting rather than a form on every page.

http://drupal.org/node/101013 is kind of related.

Comments

JirkaRybka’s picture

Good idea, I like it much. :-)

On my site I tried exposing this settings form, which led only to confusion. About 5 out of 300 users ever used it, and these then started to complain about complete mess in the forums: If different users have different flat/threaded settings on the same page, the whole discussion sort of crashes - one user comments with the words "as said in the post above this", but other user see that very post shown two pages below, placed as a reply under something completely unrelated.

At the very least, the flat/threaded setting should be enforced consistently for all users per-page. Also the form itself is big, not very good-looking on every page.

No time to test the patch now, but just reading it seems fine to me and solving the above.

Addition: Perhaps we should also change comment-deletion somehow: If flat display is selected (which is the only one ever used on my page), then deletion of comments behave *JUST CRAZY*, deleting randomly also another comments around the thread, making forums pruning impossible. That's because the system still see the discussion as threaded, although users don't, tying comments together invisibly depending on where exactly the original poster clicked a 'reply' link. Display setting flat/threaded should be respected here. Perhaps it's not that difficult to remove one entry from a threaded-chain replies, which might be useful even on truly threaded pages, if a single spam-entry slips in. This is perhaps worth another issue, or additional work in this patch.

catch’s picture

Good to see some support for the idea.

The "truly flat comments" issue is here: http://drupal.org/node/81373 - also see flatcomment.module for a quick fix on that. They're related, but I think it's best to keep seperate issues at least for now.

moshe weitzman’s picture

Can comment display really be done outside of comment? Doesn't the SQL change? If so, you can't modularize this properly and it will become harder to test core (a contrib will be needed). I don't feel strongly about this though.

catch’s picture

Can comment display really be done outside of comment? Doesn't the SQL change? If so, you can't modularize this properly and it will become harder to test core (a contrib will be needed). I don't feel strongly about this though.

To be honest I think giving users this option at all is a really bad idea - admins should just choose sensible defaults. A contrib would basically be re-introducing a nasty usability bug, and also wouldn't play nice with per-node-type comment display settings (which in my mind this issue is a prerequisite for), so I don't think it'd be a great loss if its impossible to re-implement.

moshe weitzman’s picture

oh, i understand now. you are keeping all the modes just removing the user's ability to choose. fine with me.

JirkaRybka’s picture

Thanks for the links on flat commenting. Similarily related is also my issue http://drupal.org/node/169938 about removing the "Add a new comment" link on node-teasers, these links make no sense for me. IMO the forum.module generally needs a lot of UI improvements.

catch’s picture

oh, i understand now. you are keeping all the modes just removing the user's ability to choose. fine with me.

I'd quite like to get rid of "oldest last" - groups.drupal.org has been so much easier to use since you switched it to "oldest first" for just one example. That's not necessary for this particular issue though and best to take one at a time for now.

bdragon’s picture

http://drupal.org/node/67046 marked as duplicate.

catch’s picture

Status: Needs work » Needs review

Marking to review since I'm increasingly convinced that this is a seperate issue from settings per node type or whatever - in their own right the user controls should go, further refinements would be great but not immediately necessary in this patch.

catch’s picture

http://drupal.org/node/180432

comment settings per node type is done. So although this may still need an upgrade path to remove the relevant column in the user table etc., that bit's covered, and all the more reason to get rid of this.

greggles’s picture

subscribing

catch’s picture

Category: bug » task
Priority: Normal » Critical
FileSize
8.11 KB

Untested re-roll to get this back in the game.

No upgrade path yet, looks like we could drop the "threshold", "mode" and "sort" columns in user table, maybe a few variable_del()s - but leaving at needs review for the general idea.

Also, this is possibly the worst visitor-facing usability issue in Drupal at the moment if admins actually switch these things on, so changing status.

catch’s picture

@JirkaRybka, comment deletion is partially dealt with here: http://drupal.org/node/193409

chx’s picture

oldest last is good with flat. But oldest last with threading? We tried on gdo. It was ugh. So of the four combinations , that one could be go. Could be a separate issue.

catch’s picture

I've love to see that one go, but it should be a separate issue I think.

catch’s picture

OK so I was given an example of a site which actually uses these in #drupal by someone who will remain nameless. This was the first live site I've ever seen which uses it.

I looked at the site as an anonymous user, and tried to change the comment control settings. It didn't work. He did, and it worked, then it stopped working. The site is here. This is due to the page cache. I have a feeling this issue was fixed in D6, but it underlines how little anyone ever actually uses these things.

Not to mention how much of the admin/content/node/type form we'd lose by getting rid of this, last I saw it was close to 20%.

catch’s picture

Title: UMN Usability: Remove comment controls for users » Remove comment controls for users

@chx: Comment ordering issue is here: http://drupal.org/node/191499

(also, note that this patch doesn't work - but needing as needs review because there should probably be a discussion about what to do with the db columns/upgrade path).

catch’s picture

Title: Remove comment controls for users » UMN Usability: Remove comment controls for users

"Yowzer!"

BrightLoudNoise’s picture

Title: Remove comment controls for users » UMN Usability: Remove comment controls for users

subscribing, I've been handling removing the comment controls with a custom module up til now as it caused much user confusion.

floretan’s picture

Subscribing. Patch needs to be re-rolled.

floretan’s picture

Status: Needs review » Needs work
Dries’s picture

I'm OK with ripping out some of this code. Please complete the upgrade path, and delete the stale fields from the users table. This is good.

catch’s picture

Status: Needs work » Needs review
FileSize
12.97 KB

This patch gets rid of everything to do with comment controls I could find, and drops the 'threshold', 'mode' and 'sort' columns from {users}. Note that 'threshold' was already marked as deprecated in schema, and I couldn't find any other references to it. Tested upgrade path etc.

catch’s picture

FileSize
12.99 KB

Re-rolled for concat operator spacing changes.

catch’s picture

FileSize
12.99 KB

And apparently that was the wrong patch, this one should be right.

floretan’s picture

Status: Needs review » Reviewed & tested by the community

Upgrade path is clean. The code changes are pretty clear and get the desired effect.

Freso’s picture

FileSize
12.95 KB

This patch is basically the same as the last uploaded one - just (manually) edited to remove some introduced trailing white-space. ;)

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

Dries’s picture

Committed to CVS HEAD. Thanks.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

dropcube’s picture

Include this in the CHANGELOG.TXT file: http://drupal.org/node/260700