Expose an option to hide the text format information of textarea fields

I think this is just permissions.
Create a user role say 'author' and give them permission to create 'Article's but not permissions to change text formats.

or is this not what you mean? It works for me see screenshots.

It's not a persmission afaics. The outcome is to just hide the information about text formats, but allow access to say Filtered HTML to which the current user has access and is configured as default. Not many people really read those pages about the text formats.

I'd be fine hiding them, should be an easy patch.

Would be good to have the feature. That way the form would be easier for the editorial board. How is the status here, will this be done?

This seems to work.

Fixing the failures

Thanks for the fast reply and your work on this feature. It's appreciated. :)

I've tried to use the following command from my Drupal 8 root directory to apply the patch

git apply patches/2413335-6.patch

Then I get the following message

fatal: corrupt patch at line 91

It's the same if I put the file into Drupal's root folder. How is it intended to apply the patch?

I've needed an new line at the end of the path file to be able to apply the patch (Drupal 8.0.3). Afterwards the patch works - it does what I need: the admin can choose text formats and the user with the editor role does not see a drop down field for choosing the input format. Thanks.

This looks to me like it will need an update to re-save existing config with the new default value, otherwise it'll show up in diffs etc.

Also couple of questions:

1. I'm assuming when a user only has access to a single format that this hides just the filter tips?

2. Do we really want to hide text formats from users with 'administer formats' permission or similar?

3. Extension of #2... Do we really want to hide this when the format selected for existing content is not the default? I'm thinking of existing sites (like Drupal.org) where there might be old content in an old format, the default was changed, and people might want to switch it to the new format manually when editing. You might still want to hide this for new content, but making it impossible to change the format of old posts is a bit tricky.

I don't know the answer to those questions - agreed that this makes forms look crufty, but also wondering a bit whether we couldn't de-emphasise the existing element a bit more in general - like just the '?' icon for filter tips.

1. That's what #2544188: Change the label "About text formats" if only one format is available is doing, we can always merge it in there
2. Good question, and I think we should actually show it indeed. I've run into situations where I wanted to change it but couldn't because of an annoying #access => FALSE thing
3. Fair question. If we do 2, then it's at least half covered. Also, since this is opt-in, it shouldn't be a problem when deploying on an existing site either, so we're getting away with it - for now.

And yes, needs an upgrade path to update the entity form displays.

My feedback to this issue as a reply to #10 (and #12).

1., If there's already an issue for this seperated topic, we could keep it seperated.
2., It would be good to have a possibility to make the text formats available if the user has the permission. But there can be situations, where you as a admin don't like this text formats dropdown and don't want to see it anyway. If you're an admin, you have "all" permissions. Maybe a "checkbox"-option in configuration would be nice for this case or just an option in the yaml config.
3., If you have old content, the last defined input format could be the default one. For new content, the defined text format for the field could be the default one.

Note about the patch: the text formats dropdown is still visible in node forms, which were created with devel generate module.

Also, I've been testing this code a bit in a custom project, and I think it's actually wrong anyway, especially if there's an editor: then the editor is completely gone too - but I'll double check (because I'm using a variant where I swap out the process of the default textFormat class with my own)

A contrib solution is available in #2617982: Control "About text formats" link and inline text format guidelines

@swentel just by looking at the code you could see that if using an editor it will be gone if the new setting is used because setting $element['format']['#access'] to FALSE and putting the editor in $element['format']['editor'] would not work, instead the editor should be placed somewhere else, but not under $element['format'].

I think #784672: Allow text field to enforce a specific text format will resolve this

Update:

#784672: Allow text field to enforce a specific text format allows hiding the text format information, when only one format is allowed to be used for the text_format element.

But it leaves the 'About text formats' link behind. #2544188: Change the label "About text formats" if only one format is available is looking at improving the UX when that shows without the format selector.

None of these cover the possibility of hiding the 'About text formats' link altogether (whatever it might get labelled). I guess this issue might probably still be need to wait for that latter issue to be resolved though.

I think that

1. the scope of the current issue is unclear, whether it is referring to the text format selector or the text format information link

2. hiding the link but not the selector is not a 95% use case and should not be a core option

3. this issue should be about giving the option to hide both the selector and the link together, which is relevant if:
- a. the default format is different for different users, but you don't want them to choose
- b. only a single format is allowed, so no selector is shown, but you still want to hide the link

4. even with this reduced scope, I have doubts about whether this is a common enough use case for this setting to belong in core

I don't think it should be postponed, if it should be open at all. It's independent of the issue of the link's wording.

Yeah I think I’m inclined to agree. Even if there is an outstanding feature that could be implemented, it’s possibly for too narrow a use case, and so not worth supporting in core.

The work already done in core to allow configuring allowed text formats, plus the possible relabelling, could be sufficient for core.

I’m going to be brave and just close this issue - it can always be reopened if there really is enough support for it, though it’s scope would then need clarifying.

For people finding this issue from popular search engines, the work is now happening in https://www.drupal.org/project/drupal/issues/3323007