Problem/Motivation
Comment field settings are nested in a 'comments' details element.
The field-schema does not reflect this, so the values/settings aren't saved
Proposed resolution
Remove the 'comments' wrapper nesting from the form field names
Remaining tasks
Review
User interface changes
None
API changes
None
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | Screen Shot 2015-01-14 at 09.49.52.png | 95.54 KB | larowlan |
| #7 | comment-settings-busted.7.patch | 3.82 KB | larowlan |
| comment-settings-busted.pass_.patch | 2.83 KB | larowlan | |
| comment-settings-busted.fail_.patch | 1.36 KB | larowlan |
Comments
Comment #2
yched commentedAgreed on the fix, a bit sad that there isn't a simpler way ?
Comment #3
dawehnerit sounds like a generic functionality for me. Can't we provide some kind of process callback in FAPI somewhere? Note: I have seen a similar thing in
SystemMenuBlockComment #4
yched commentedSo the case is "I don't know which form structure I'm embedded into, but I want my values sub-array to be structured that way".
Our current tools (#tree, #parents) do not allow this, but ideally, such things could be expressed directly in the $element sub form without having to resort to process callbacks ?
Comment #5
larowlanSo perhaps we allow #tree => FALSE on details elements to auto-implement this functionality? Even when #tree is already TRUE.
But to be honest, this sounds like a follow up, I'd rather we didn't block fixing this issue on adding a new API.
Thoughts?
Comment #6
larowlanAlso, I'm completely ok with removing the details element if that helps with velocity.
I think it was a carry over from the old details tab on the node-type form
Comment #7
larowlanSo just removed the details element in the interest of velocity.

Doesn't make much difference - no other fields have a details wrapper on their settings.
Screenshot
Comment #10
yched commentedLooks good to me
Comment #11
alexpottIs this not used?
Comment #12
larowlanYa that was used to update the vertical tab summary when these fields were on the node-type edit form.
So, nope - not needed.
The library is still used to update a vertical tab summary on the node edit form, so we need it, just not here
Comment #13
grendzy commentedI think I found one other place which looks up this variable using the wrong key:
http://cgit.drupalcode.org/drupal/tree/core/modules/comment/src/CommentA...
Comment #14
larowlanWe have #2405691: CommentAccessControlHandler checks for an invalid setting (anonymous_contact) for that
Comment #15
grendzy commentedThanks, good work!
Comment #16
alexpottThis issue addresses a major bug and is allowed per https://www.drupal.org/core/beta-changes. Committed 125424b and pushed to 8.0.x. Thanks!