Problem/Motivation
When threading is enabled on comments, there is no mechanism to limit how far a comment will indent. This poses a problem for sites that wish to have a defined maximum threading level for threaded comments.
Proposed resolution
- Add a configuration to allow the maximum threading depth to be defined.
- Allow the site builder to decide whether replying to the deepest comment is allowed. If allowed, the reply will be displayed with the same indent as the parent comment. If not allowed, then replies are totally denied.
Remaining tasks
None.
User interface changes
User perspective
When the thread depth is limited, depending on the Limited depth settings configuration the user can either reply on the deepest comment, case when the reply will be displayed with the same indent as the parent comment, or replying access is completely denied.
Site builder perspective
The Threading (internally, default_mode
) field setting is converted from a check box into radios, exposing three options:
- Flat list
- Threaded (no depth limit)
- Threaded (limited depth)
The first two options are the current options of the checkbox.
When Threaded (limited depth) is selected, the site builder is able to define a thread deep and the reply policy. Site builders can decide whether replying to the deepest comment is allowed.
Backwards compatibility note
The reason why it was opted to add a new default_mode
is to ensure a more safe backwards compatibility. The current threaded comments fields will work without needing any update path.
API changes
None.
Data model changes
- The comment field
default_mode
setting has a new option CommentManagerInterface::COMMENT_MODE_THREADED_DEPTH_LIMIT
- New comment field setting:
thread_limit
.