Problem/Motivation
The webform module uses a "webform_default" text format. This format is hidden almost everywhere. It is especially removed from text format selects in WebformHtmlEditor::processTextFormat. This leads to users with permissions only for this text format to see a text format select on text fields outside webforms with "Plain text" as only option, where they previously did not see the text format selection.
Drupal hides the select if only one or no text format is configured. With the new text format, the users ave two text formats available, but then later the webforms module hook removes on of the options.
Steps to reproduce
- Give registered users the permission to use the webform_default format, but not any other text formats.
- Log in as a user with no other roles.
- Visit an edit form, e.g. for a basic page.
- The body field should use the Plain Text format, without offering a text format selection. It does offer the selection, but with only one option for "Plain Text". This clutters the user interface and potentially confuses users.
Proposed resolution
What is the webform text format used for? Is there documentation for this anywhere? Is access to the text format only needed for users administering wbforms or also for users of webforms?
I'm pretty sure that an update hook gave registered users the permission for the text format. Why is it necessary for registered users to use it, but not for anonymous guests? If this really needs to be this way, is there a better way to get rid of the text format without leaving the pointless select?
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork webform-3477051
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
cilefen commentedIt is to ensure a text format exists for the WebformHtmlEditor form element.
This is probably related to #3331164: Text format webform_default can not be used outside of webform module, but as a support request, won't be acted on.
Comment #3
ammaletu commentedI didn't want to outright label it as a bug, although I do think that it is one. There already is an unanswered question on Drupal Answers: https://drupal.stackexchange.com/questions/320170/what-is-the-purpose-of...
From a practical point of view, the whole thing boils down to "Do webform users need this text format or only webform admins"?
Comment #4
cilefen commentedThe answer to that is probably "only webform authors". If you could figure out a way to make existing text formats accessible to the webform author in this widget, I suppose that would be an improvement. But that would be in a context of having read every prior issue pertaining to this matter to understand the maintainers' position on this one.
Comment #6
jrockowitz commentedI was able to reproduce the issue, and this seems like a simple bug that should be addressed. Please review the MR.
Comment #8
ammaletu commentedI tested the change and it works perfectly! Users with more text formats still see the dropdown without the webform text format. And my registered users without any other text formats don't see the Plain text select anymore.
Thanks a lot for the quick patch! I just added two comments to the MR, concerning typos in comments.
Comment #9
liam morlandThanks for the patch and review. Those typos should be fixed first.
Comment #10
jrockowitz commented@ammaletu Thank you for the code review.
Comment #11
pameeela commentedJust wanted to note that #2502637: Disabled text formats can't be seen in the GUI makes this format visible in the list in 10.4+ and 11.1+, which is.... not ideal. Not sure what the solution is though.
Comment #12
jrockowitz commentedLet's resolve this issue via #3485556: Webform text format appears in the formats list
Comment #13
jrockowitz commentedComment #14
jrockowitz commentedI think the root cause of this issue n Drupal 11.1 users could be assigned the 'use text format webform_default' permission.Let's block this from happening and write an update hook to suppress the permission.
I am getting confused on what is triggering this issue. Please let me dig deeper. This may need to be resolved via this dedicated ticket.
Comment #15
jrockowitz commentedComment #16
jrockowitz commentedYep, we need this dedicated MR, which now has test coverage.
Comment #17
jrockowitz commentedComment #18
jrockowitz commentedOnce the tests pass, let's merge this.
Comment #21
jrockowitz commentedComment #22
jrockowitz commented