Make comment settings form more usable

+1 to these changes in principle, however a couple of things:

- the node type form comments tab is a lot noisier now. In particular, 'Threading' is a bit muddled in beneath the radios with descriptions.
- The tab summary needs some change too, as now it shows ", Threading , 50 comments per page" with a leading comma.

Looking good.

Just one thing:

* Open , Show comment replies in a threaded list , 50 comments per page(active tab)

Space before the comma.

The Publishing options suffer from this glitch too, but this particular spare space is added by your patch.

Also, I've just noticed it used to say:

* Open, Threading , 50 comments per page(active tab)

So stray spaces in the current code too -- so we could leave those to another issue. However, I think perhaps just 'Threading' is clearer in the summary, or something shorter than the full checkbox text at any rate. I like your change to the actual checkbox label though!

Ok I've filed #991522: Vertical tabs summaries have stray spaces for the stray spaces.

How about adding '#attributes' => array('class' => array('container-inline'))

I hate seeing two or three small options stacked - horizontal is better.

Screenshot?

I don't think we need to split up the issue, let's make this issue a general "comment form settings cleanup" issue. No? #991078: Anonymous contact information settings per node type needs to be radios, not select Is marked as duplicate.

Attached is a patch and two screenshots on my first take. It includes most of what is mentioned above, with some minor changes.

Oops, not very usable patch ;)

Thanks, dixon_. Could you look at #9 above, please?

@NancyDru Making radios and other form controls inline with each other is not a pattern used throughout core. I agree it could be useful, but that needs to be decided as a design pattern to use, and apply it consistently throughout core.

Run it through @Bojhan and the UX team first.

In a D7 - D8 upgrade, what happens to content types where comment was set to hidden on the node type? Is there any unexpected behavior change?

The patch in #13 doesn't change any of that behavior.

@dixon_

After a D7-D8 upgrade there will potentially be a value for some node types that is no longer available on the settings page. What happens in FAPI when we try to set #default_value to a value that is not in #options?

Manually tested this patch. All three states worked fine.

1. Initially only had two states available, Open and Closed (very sensible)
2. After I created a comment for a node and edited the node, I saw three states: Open, Closed, and Hidden.

This changes make a whole lot of common sense. It's finally crystal clear what these settings mean.

I recommend RTBC

I don't think that introducing a new UI pattern in just one single place is a very good thing -- do we have inline radio options anywhere else?

+      '#description' => t('If <em>Open</em>, only users with the <a href="/admin/people/permissions#module-comment">Post comments permission</a> can posts comments.'),

What happens if I have permission to administer node types, but not permission to assign permissions? Won't this link to a 403?

Just had a quick look through the code and as far as I can see, container-inline is only used for the search form and for the various forms that list actions (node admin, comment admin, etc).

If we want to introduce it for radio sets, it needs an issue of its own to do it consistently rather than piecemeal.

Updating tags per http://drupal.org/node/1517250

#1: fix_comments.patch queued for re-testing.

Currently comments are configured via field settings (to see anonymous settings you need to enable permission)

Also not sure about backport to 7 because this changes form structure

This is no more issue for 8.x

edit see #30