Allow text field to enforce a specific text format

I don't see how this can go into D7 at this point.

Agreed. Sorry.

Something similar to the filter.module part of this issue was discussed at length in #414424: Introduce Form API #type 'text_format' but ultimately did not make it into the final patch. See for example:
http://drupal.org/node/414424#comment-1617600
http://drupal.org/node/414424#comment-2177612
(and many subsequent comments)

The argument I tried to make there was that since we were already doing a massive API change in that issue (completely reworking how #text_format works), it would make sense to slip in both something like the #formats option described here, as well as a #default_format option, since it would require almost no extra work to do so. I was overruled though...

So personally, if limited to the filter.module at least (the field module changes do seem like they might be too much for now) I'd be very in favor of still trying to do this in D7 :) It's possible to do this kind of thing in a contrib module - and people will undoubtedly try to do it - but it's tricky to do correctly (involves somewhat complex form API stuff that most people don't know about), and if you do it wrong, you are very likely to introduce a security issue. Plus, the filter.module changes here wouldn't break any existing code, just introduce a new optional property to the form element. I think adding this API functionality to the Filter module in a way that we know will be easy for contrib modules to use securely is definitely still worth doing. Anyone else agree? And would doing that help allow a contrib module to make the changes to the field UI/functionality that are contained in the rest of this patch?

It's sad that such essential ability for user-friendly forms is not in Drupal 7. Please reconsider :-)

Looking at the patch in #2, it doesn't provide what I want - ability to hide format fieldset altogether and wysiwyg+tinymce to do its job.

+1 for Drupal 7!

subscribe, a default text format for textfields might be also relevant to allow adding html tags for accessiblity.

This may help accessibility in some situations, but definitely isn't an accessibility issue. Removing tag, thanks for bringing it to my attention.

OK. Tagging this as WCAG/ATAG and 'language of parts' as this feature request would help create accessible content, especially language tagging (WCAG2.0 3.1.2)

#2: text-field-format-2.patch queued for re-testing.

Tagging for accessibility.

Drupal 7.x patch on-the-way.

I didn't change how the filter formats permissions are checked against the field, since this will require additional community feedback.
I.E. Should the user's permission to use the format supercede their ability to use a format specifically defined on a text field?

This probably isn't the most efficient patch in the world, but I have tested it locally against 7.x-dev and it works!

EDIT: Opened #1419016: Allow text fields to enforce a specific format so it could be tested against D7.

Oops, forgot to set needs review.

I think the strategy we need to take to implement this is:

1. Create an API in the filter system for any module which provides text format elements to specify which formats they want to allow in that instance.
2. Have the Text module implement that API.

We should really avoid hardcoding any special behavior for text fields inside the filter system itself, because that will limit how this can be used.

See also the related issue at #1423244: #allowed_formats property for #type 'text_format' to filter available formats. It almost would make sense to postpone this issue on that one (because that's basically #1 above), except that there's lots of code here already...

Note that there are also a lot of potential security issues that need to be dealt with in implementing this (see #1295248: Allow per-field-instance configuration of allowed formats for discussion and code), and that's one of the reasons why it would be good to at least have the API for this in core regardless of whether or not the code that implements it lives in core too.

We need clarification on why this is an accessibility issue. Sorry.

Some while ago I tagged this issue as helping accessibility. For accessibility (or markup) in single line textfields we need sometimes additional HTML inline tags (span (for 'lang'), dfn and abbr). At the other hand, we don't want to allow HTML block level tags (h1, h2, h3, p) in single line fields, only in textareas.

So, in a website there are possibly two separate filter formats needed: one for single line textfields and one for textareas (where HTML block level tags are allowed). The end-user shouldn't be allowed to mix these sets, because we will end up with content that doesn't validate (ATAG2.0 issue (http://www.w3.org/TR/ATAG20/#principle_b2))
As abbr and dfn is needed on level AAA, it is mostly needed for language of parts (level AA), when someone wants to add text in another language (for example <span lang="fr">Tour de France</span>).

Wished you'd been able to come over for A11ySprint by-the-way. You'd have had a great time with us I'm sure.

I think we just need a bit more of a use case where it's clear that this additional functionality meets the needs of the 80%.

How would this practically be used? I do think that there are a lot of instances where Languages of Parts really isn't dealt with all that well as you know.

What are the options for implementing this now in D7?

@mgifford yes, it would have been nice to help during the sprint.

This issue is at the moment not relevant for most of the users. It becomes more relevant as soon as the node title becomes a text field (#1188394: Make title behave as a configurable, translatable field (again)). At the moment it is not possible to produce titles with language information nor semantic markup (part of WCAG 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)).

A technique for this is using semantic markup to mark emphasized or special text. For this certain - inline level - HTML tags are needed. Here are some examples taken from WCAG H49:

An excerpt from the <cite>The Story of my Life</cite> by Helen Keller
What she <em>really</em> meant to say was, "This is not ok,  it is <strong>excellent</strong>"!
Helen Keller said, "<q>Self-pity is our worst enemy and if we yield to it, we can never do anything good in the world.</q>"
Beth received 1<sup>st</sup> place in the 9<sup>th</sup> grade science competition.
The chemical notation for water is H<sub>2</sub>O.

Note: Instead of having two filter formats (one for text fields, one for text areas), an alternative could be to automatically disable the block level html tags in filter formats applied to text fields and only allowing them on text areas.

Sadly this issue has been left behind. @Hanno are you in a place where you can try to update the patch?

#1423244: #allowed_formats property for #type 'text_format' to filter available formats has a patch ready to be reviewed which adds some missing functionality in the text_format form element provided by the filter module. Once it's ready we can use it to make it possible to set the format for a specific field.

This feature is key. Please don't leave it behind. You should be able to select available formats per field. Some fields require a specific one or things break. (I guess if a user didn't have permissions for the available format it should make the field un-editable for them).

Agreed. I'm wondering about tagging it for security. It's come up a few times thus far in this thread.

This is very desirable to me. I have had to go about it with an ugly hack:

1. Created a custom module that searches the edit/add form for any field that has text_formats applied to it (sometimes there are many).
2. Hide the drop-down list but keep the guidelines for the default format displayed.
3. I set a default format by entering default text into the content-type field definition. The default text is

.

.
4. My modules looks for that default value and unsets it. I don't want the field polluted with this ugly data.

I like this functionality because sometimes I want a field that is just a simple 3 line box for entering a short amount of minimally-styled text. Perhaps I only want people to be able to use HTML to link some words in the text, but nothing else. I don't want them to have to switch between all the available content types, I don't want them to use a wysiwyg editor and be able to insert tables and headings and videos. I only want them to be presented with a simple box with guidelines on the limited allowed html they can use that is appropriate for that particular field.

There is a working patch for this bug in D7 over at #1278886: Default text formats are not saved properly without accompanying values

Looks like #1423244-68: #allowed_formats property for #type 'text_format' to filter available formats was committed 10 months ago. @floretan suggested in #26 above that it "adds some missing functionality in the text_format form element provided by the filter module. Once it's ready we can use it to make it possible to set the format for a specific field."

Thanks for the link @jenlampton and yes, hopefully it gets backported.

The last patch didn't apply at all anymore, but the changes to the typed data API from the past two years have made it quite easy to rebuild this functionality.

Here's what this patch does:

1. Make an additional setting available on the field editing form for all formatted text fields, like the body field of nodes for example. The checkboxes let you select what text formats should be available for that field.
2. Use that setting on the widgets for fields of this type to determine what formats are available using the new #available_formats attribute from #1423244: #allowed_formats property for #type 'text_format' to filter available formats. Note that this only restricts what formats are available, it doesn't make formats available that the user doesn't have access to.

Open questions:

1. Do we want to make the fallback format an option?
2. The current patch adds the settings on the field level, based on the fact that it really affects what kind of data gets stored in the field, not only how it's entered. However, the validation is only done at the widget level. We should probably add some validation at the field level as well.

Once this gets in, we can have a follow-up issue where we check all fields in the default installation profile that should have limited text formats. For example, comments should probably be limited to "Restricted Html".

Adding default configurations to fix most of the exceptions seen in the test results.

Fixing two more failures. The remaining failures are related to FieldUiTestTrait and I'm not sure how to fix them yet. Any help on that would be appreciated.

Oh, the ordering of items in an array matters for comparison.

1. +++ b/core/modules/block_content/block_content.module
   @@ -83,7 +83,10 @@ function block_content_add_body_field($block_type_id, $label = 'Body') {
   +        'available_formats' => array(),
   
   +++ b/core/modules/config_translation/src/Tests/ConfigTranslationListUiTest.php
   @@ -401,7 +401,10 @@ public function doFieldListTest() {
   +        'available_formats' => array(),
   
   +++ b/core/modules/migrate_drupal/src/Tests/d6/MigrateFieldInstanceTest.php
   @@ -90,7 +90,10 @@ public function testFieldInstanceSettings() {
   +      'allowed_formats' => array(),
   
   +++ b/core/modules/node/node.module
   @@ -328,7 +328,10 @@ function node_add_body_field(NodeTypeInterface $type, $label = 'Body') {
   +        'available_formats' => array(),
   

   Just a minor thing: We should use the new syntax here, just [] instead of array().

2. +++ b/core/modules/text/src/Plugin/Field/FieldType/TextItemBase.php
   @@ -12,12 +12,37 @@
   +    $element['available_formats'] =  array(
   

   Another minor thing: We should remove that " " two spaces there.

Fix the confusion between "available" and "allowed".

@yannickoo: I also fixed the double spacing in TextItemBase.php. Regarding the array notation, all of the modified files use the old array() notation, so I left it as is to not add unrelated changes with the patch.

This new patch fixes the schema definition for the individual formats in allowed_formats fields in text.schema.yml, which should fix the remaining failures.

Ah sequence property did the trick ;)

Patch works fine, code looks good and no more failing tests!

Actually, there are few more things that need to happen.

At the moment, the allowed formats get exported like this (because that's the way checkbox values are submitted):

  allowed_formats:
    basic_html: basic_html
    restricted_html: restricted_html
    full_html: 0
    plain_text: 0

What we want is something like

  allowed_formats:
    - basic_html
    - restricted_html

Once we have this, we can update the configuration schema in text.schema.yml. The allowed formats are a sequence, but their values are not just any strings. So we should replace

    allowed_formats:
      type: sequence
      label: 'Allowed text formats'
      sequence:
        type: string

with something like

    allowed_formats:
      type: sequence
      label: 'Allowed text formats'
      sequence:
        type: filter.format.[%value]

One final but important addition we would need is some test coverage. The #allowed_formats form API property is already covered, but we probably need to extend some more textfield-related tests.

One issue pointed out by @maijs is that when applying this patch and there are already existing fields without the allowed_formats setting we get "undefined index" notices. We don't do something similar for other settings that have always been there, so I'm not sure if this is needed since it's one case of beta-to-beta upgrade. Saving the field settings form would get rid of those notices.

This patch work fine in my case !! Thanks @floretan

ps : It would just be more optimized to put as select.

Reroll.

Migrate installation confiuration files (core/modules/migrate_drupal/config/install) was moved to core/modules/migrate_drupal/config/optionnal.

You can see this here /admin/structure/types/manage/page/fields/node.page.body

Looks good to me. What else, if anything, is needed before this is marked RTBC?

The schema change I mentioned in #48 is not necessarily needed, but a test should be included.

While working on more real Drupal 8 projects, this functionality seems to be needed everywhere.

Here's the patch re-rolled, with some tests added. This should be good now.

+++ b/core/modules/text/src/Tests/TextFieldTest.php
@@ -182,6 +182,31 @@ function _testTextfieldWidgetsFormatted($field_type, $widget_type) {
+    // Limit our field to only allow the newly created format.
+    $field_storage->set('settings', array('allowed_formats' => array($format_id)));

The set() is not working. I tried setSetting() and even calling save() after. The allowed_formats doesn't get saved to field storage.

Thanks @lokapujya. The format ID should be in the key of the settings array, not in the value.

I also realised that the patch I uploaded somehow had an older version of the test. Here is the correct one (no functional change, only the test is different).

is there a d7 version of this patch (or one in the works)?

@rcross: it could be done, but #1423244: #allowed_formats property for #type 'text_format' to filter available formats would need to be committed first.

Changed the test so that it first has 2 formats. Verify that the format select shows up. Change the field to only have 1 format. Then, verify that the format selector doesn't show up.

Also, made the following changes:

1. +++ b/core/modules/text/src/Tests/TextFieldTest.php
   @@ -84,6 +84,69 @@ function testTextfieldWidgetsFormatted() {
   +    // Create a second text formats.
   

   format (singular.)

2. +++ b/core/modules/text/src/Tests/TextFieldTest.php
   @@ -84,6 +84,69 @@ function testTextfieldWidgetsFormatted() {
   +      'settings' => array('allowed_formats' => array($format1->id() => TRUE)),
   

   This still wasn't working. The format selector was not showing up, but only because no formats were allowed.

3. +++ b/core/modules/text/src/Tests/TextFieldTest.php
   @@ -84,6 +84,69 @@ function testTextfieldWidgetsFormatted() {
   +    $this->assertFieldByName("{$field_name}[0][value]", '', 'Widget is displayed');
   

   '' should be NULL.

Re-rolling patch, due to changes made in #2533994: Move module-specific migration support into the block_content module

Skipping the interdiff, as it was a simple file rename from migrate_drupal to block_content

Prior to the use of array_filter, check if the value to be filtered is an array.

Updating the summary.

It seems more like a task than a complete new feature. Beta evaluation needs update too.

Nice, this is a really cool feature. I reviewed the usability of the new UI. Only minor comments:

Can we move these options so they are above the default value display? It is quite big and has shown a tendency to be distracting in usability tests. If we move the options above the default value they have a better chance of being noticed.

Here's a screenshot displaying the changes to the content creation screen. When there are multiple choices it's the same UI. When there is only one choice the UI looks like this:

Can we remove the text formats help link if there are no options? It doesn't seem to provide any value.

Thanks @LewisNyman for the review.

I agree that placing these options above the default value would make sense, but that would be different from what every other field configuration form does (the default value always comes first), so I'm not sure we want to do that.

I also agree that the link "About text formats" doesn't make sense if there is only one text format available. The changes in this issue make that problem apparent, but the problem is independent. I created #2544188: Change the label "About text formats" if only one format is available to address that issue, it probably shouldn't be combined with this one.

Simplify tags, and requesting usability review

1. +++ b/core/modules/text/src/Plugin/Field/FieldWidget/TextareaWidget.php
   @@ -35,6 +35,14 @@ public function formElement(FieldItemListInterface $items, $delta, array $elemen
   +      if (!empty($allowed_formats) && !$this->isDefaultValueWidget($form_state)) {
   

   Probably want to avoid two function calls by refactoring to a temporary variable.

2. +++ b/core/modules/text/src/Plugin/Field/FieldWidget/TextfieldWidget.php
   @@ -35,6 +35,14 @@ public function formElement(FieldItemListInterface $items, $delta, array $elemen
   +      $allowed_formats = array_filter($this->getFieldSetting('allowed_formats'));
   

   Probably want to avoid two function calls by refactoring to a temporary variable, here too.

EDIT because DrEditor doesn't make it really clear, this is about the repeated calls to $this->getFieldSetting('allowed_formats')); in both cases.

The latest patch from #65 did not apply correctly anymore because 2 files were moved by recently commited issues #2415335 and #2534010. The files that have been moved and/or renamed are

• core/modules/block_content/migration_templates/d6_block_content_body_field.yml and
• core/modules/migrate_drupal/src/Tests/d6/MigrateFieldInstanceTest.php .

The attached patch fixes that and implements the suggestions from #74.

+++ b/core/modules/field/src/Tests/Migrate/d6/MigrateFieldInstanceTest.php
@@ -78,7 +78,10 @@ public function testFieldInstanceSettings() {
-    $expected = array('max_length' => 255);
+    $expected = array(
+      'allowed_formats' => array(),
+      'max_length' => 255,
+    );

What do you think about using $expected = ['max_length' => 255] instead of array() syntax?

Does #71 & #72 qualify as the usability review?

Short array syntax FTW!

What happens if the field allows only one format, but the user doesn't have access to that format?

Stupid array comparison.

@lokapujya: Not sure how to reproduce that.. The plain text format is always available. If you find a way to disable or delete it, I can then answer your question. My guess is that the correct reply to your question is that, by design, Drupal will always allow you to use the plain text format.

My guess is that the correct reply to your question is that, by design, Drupal will always allow you to use the plain text format.

That's true, but, now with this patch, it can be configured that "plain text" is not allowed for the field.

What happens if the field allows only one format, but the user doesn't have access to that format?

The content editor will get this message in the input box when adding a new node, "This field has been disabled because you do not have sufficient permissions to edit it." That is the same message the content editor would get if he edited a piece of content and doesn't have access to the format.

Looks good!

After discussing this with various people at the code sprint, it became clear that the best way to approach this issue is to implement it as a contrib module for now and eventually integrate it in Drupal 8.1. At this point the somewhat unclear logic for all fallback cases will be battle-tested.

I created a module here https://www.drupal.org/project/allowed_formats, we are working on converting the latest patch from this issue to a contrib module. Please join that module's issue queue if you want to contribute.

The Allowed Formats module (https://www.drupal.org/project/allowed_formats) is now functional.

Nice that there's a contrib module, but can we go back to getting this into core, now targeting 8.2?

not tested.

this is the interdiff.

Updated patch that addresses the DefaultConfigTest failures.

Also fix MigrateFieldInstanceTest failure.

Anyone have thoughts on whether #1278886: Default text formats are not saved properly without accompanying values should be postponed until we get this one done? This might affect how that one is solved.

The last retest failed to apply.

Relolling the patch.

Patch does not apply anymore (because forum config was renamed).

Code looks ok though.

Re-roll patch.

Hm, maybe we should add a description to the field. For example. it is not immediately obvious what happens if you select no allowed formats.

Here is a patch with only that added.

1. +++ b/core/modules/text/src/Plugin/Field/FieldType/TextItemBase.php
   @@ -7,12 +7,36 @@
   +  public function fieldSettingsForm(array $form, FormStateInterface $form_state) {
   

   inheritdoc missing.

2. +++ b/core/modules/text/src/Plugin/Field/FieldWidget/TextfieldWidget.php
   @@ -25,11 +25,20 @@ class TextfieldWidget extends StringTextfieldWidget {
   +    if (is_array($allowed_formats_setting)) {
   

   The is_array check is not needed as it impossible to get anything different than an array there.

3. +++ b/core/modules/text/src/Plugin/Field/FieldWidget/TextfieldWidget.php
   @@ -25,11 +25,20 @@ class TextfieldWidget extends StringTextfieldWidget {
   +      $allowed_formats = array_filter($allowed_formats_setting);
   

   Why do we need to filter the array here?

@hchonov
I have fixed 1 and 2

I tested by removing point 3 $allowed_formats = array_filter($allowed_formats_setting);
and tested manually. It seems worked fine for me.
still we can get some inputs from @eiriksm

Feedback totally makes sense. As I said it was more or less a re-roll.

Nice points!

@mohit_aghera when you are posting an interdiff please make it so that it indicates all the changes that are included, in your case the third change is to see in the interdiff, but not in the posted patch.

1. +++ b/core/modules/text/src/Plugin/Field/FieldType/TextItemBase.php
   @@ -16,6 +17,31 @@
   +      '#title' => t('Allowed text formats'),
   ...
   +      '#description' => t('Select the allowed text formats. If no formats are selected, all available text formats will be displayed to the user.'),
   

   Use $this->t() instead of t() whenever possible.

2. +++ b/core/modules/text/src/Plugin/Field/FieldType/TextItemBase.php
   @@ -16,6 +17,31 @@
   +      '#options' => $this->getProperties()['format']->getPossibleOptions(),
   

   The property should be retrieved with $this->get('format').

3. +++ b/core/modules/text/src/Tests/TextFieldTest.php
   @@ -142,6 +142,77 @@ function testTextfieldWidgetsFormatted() {
   +
   ...
   @@ -182,8 +253,8 @@ function _testTextfieldWidgetsFormatted($field_type, $widget_type) {
   

   An empty line is not needed here.

Some high-level remarks on the current approach:

We need to implement calculateDependencies() to declare a dependency on the text formats that we are limiting the text field to. Then we also need to implement onDependencyRemoval() to remove a text format from the list of allowed formats in case it is removed. This then becomes problematic if we are removing the single text format that was allowed for a field. In that case the allowed_formats array is empty which means that all formats are allowed which would be a security problem.

I think that problem hints to the fact that the "no values means all values" pattern employed here - while being used elsewhere in Drupal as well - really is problematic and I think we would be wise to avoid it in this case. I would suggest to add a separate restrict_formats boolean setting that activates this behavior. Then the allowed_formats setting really is just that: the list of allowed formats. And if it is empty (and restrict_formats is TRUE) then it simply means that no text formats are allowed and thus text cannot be submitted until this issue is resolved either by allowing one or more formats or by deactivating restrict_formats altogether.

I by no means think that we always need to have a 1-1 relationship between our UI elements and our storage but in this particular case I think the separate setting would make the UI less confusing as well. We could have a simple Restrict text formats checkbox and only when it is checked does the list of text formats to allow appear.

Would love to hear your thoughts on this, but marking needs work because - as explained in the first paragraph - the current patch is not sufficient, even if we pursue a different approach than outlined here.

@tstoeckler what about if we just name it restricted_formats or enforced_formats and in this case only use what is set there without the boolean flag.

i.e. always restrict the list of text formats, and just have it default to all formats by default? I am not sure about that. Given the properly implemented dependencies, it would mean that every textfield has a dependency on every text format or a subset of them but at the very least on one. That could be seen as a benefit if you see it as already existing dependencies becoming more explicit or you could see it as a a problem if you argue that it increases coupling of different systems (text storage vs. text processing). Not sure where I stand on that myself.

I am curious if this should be closed since the Allowed Formats module is offering this functionality (per: https://www.drupal.org/node/784672#comment-10373375)

I think the point of that issue is to bring that functionality into core which would IMHO make sense as it is a very useful feature. We only started that contrib module because we didn't manage to get it into core for 8.0.

Doesn't apply to 8.4

Re-rolled.

Having thought about this for a while and having watched a bunch of other bugs being fixed with config dependencies in the meantime, I am convinced that we need to restructure the configuration that is currently being pursued by this patch. Feel free to disagree, of course, but this is what I think what we should do:

* Have a separate "restrict_formats" boolean flag, that defaults to FALSE.
* Have a "allowed_formats" array (just like now), that defaults to an empty array.

Then if "restrict_formats" is FALSE, then we do nothing. As soon as it is used then we use the "allowed_formats" array.
This is for the following reason:

We will have to add a config dependency on any text format that is being used. Then if a format is being deleted we will need to remove that format from the list of allowed formats. If that format happened to be the *last* format, then it must not be possible to use any format at all until the field is re-configured explicitly. Anything else would be a security problem. Currently if we remove the last format, the field is interpreted as not restricting formats as all.

I hope that was clear, this is kind of hard to explain... What do you think?

Unexpected behavior, yes, security issue, no, IMHO. This is not a security feature, it's a user experience improvement. Security is handled through permissions and you'd still only have access to formats that you are allowed to use.

I think showing all would be OK, we don't really have an API/UI to handle having no allowed format, it would likely just fall back to the fallback format, which is most likely not what you want.

We could also force you to fix your configuration first by letting the field be deleted, but we all know that users don't really read those warnings (e.g. the related views deletion issue), at least not with the current UI.

to resolve this problem, i used allowed_formats module

A must have for sure. +1 to this feature

reroll for 8.5.x

+++ b/core/modules/text/src/Plugin/Field/FieldType/TextItemBase.php
@@ -7,12 +7,38 @@
+      '#title' => t('Allowed text formats'),
...
+      '#description' => t('Select the allowed text formats. If no formats are selected, all available text formats will be displayed to the user.'),

Should not use t() inside an object. Use $this->t() instead.

Rerunning a test against 8.6.x

Addressing a couple of the errors

@tstoeckler re #125 Can we address the config dependency in a follow-up and does @Berdir's comments help alleviate your security concern?

Missing use statement in test and umami default config for copyright field.

Re #135: Yes #126 is correct that it would be not be a security issue, unlike I claimed. However, not cleaning up the configuration would be a bug that we would be introducing here, so I don't think we can punt that to a follow-up. Also, since my proposal would change the configuration structure relative to what the patch contains now, I think - if people agree with my proposal - we should just do it "correctly" now instead of changing it again in a follow-up.

@tstoeckler thanks for the quick reply, regarding your proposal of the extra field. What do we gain from the extra field? Can't we let none or explicit all checked for showing all? I believe that's how other things have worked in the past.

It's true that this has been used before, but it has also lead to problems.

In this particular case the problem would be the following:

• Say you have a field that is limited to only allow text format basic_html
• The administrator then removes the basic_html text format
• Since we have added the restricted filter as a config dependency, it is cleaned up when the format is deleted and the format is removed from the list of allowed formats
• Since the list is now empty, the text filter now allows all formats. Since access to text formats is checked independently of this configuration n one will be able to use a format they don't have access to, but still this behavior violates the principle of least surprise

If we agree that this is not a big issue, I don't feel super strongly about this, but on the other hand I don't see much reason not to do it this way.

We actually have this pattern already with allowed bundles in entity reference fields. We handle it there by treating NULL and [] differently. NULL means all filter formats are allowed that the user has access to, [] means none are allowed.

We could specifically test for that and disable the text field completely, similar to how we now handle existing data in a format that the user is not allowed to use, disabling the form element, possibly failing validation, forcing the admin to fix it.

Then again, this is actually rather theoretical, because officially, there is no way to delete a text format, you can only disable it (in which case you can't restore it, but that's another story).

So the only way to delete one would be through the API/deleting config files.

Reroll attempt against 8.6.

Good points from @Berdir in #144.

• It seems to make a lot of sense to copy the existing model of entity reference fields.
• Deleting text formats is theoretical - at least at the moment.

Also sticking to a single field has the advantage of simplicity. Do we have a consensus for @Berdir suggestion? OK with you @tstoeckler?

In terms of "[] means none are allowed", if someone is keen they could add it to this patch. Or we could defer it to a follow-up issue on the basis that there is currently no UI to delete text formats.

The patch seems to be working from the functional point of view but it seems that we need to accommodate some of the core tests.
I tested on 8.7 and then re-rolled back to 8.5.8 that is the stable for our platform. All is working fine so far, documented the re-roll here:
https://www.drupal.org/project/drupal/issues/3008020
I will try to fix the failing tests if none-one is working on that already.
Thanks for this!

Hi All,

Having this feature in field settings will be applicable for all the form modes. So we can't restrict it to particular form mode. So Can we implement this feature based on form display?

Hope makes sense.Thanks

Re #149 I think that is a separate feature request, to make this available as a widget setting for the formatted textarea widget.

Thanks for the patch, very useful!

Some really small remarks:

1. +++ b/core/modules/text/config/schema/text.schema.yml
   @@ -38,6 +44,12 @@ field.storage_settings.text_long:
   +        type: string
   

   I'm fine with using string here but it implies that the same format is valid for all languages (which makes sense imo).

2. +++ b/core/modules/text/src/Plugin/Field/FieldType/TextItemBase.php
   @@ -7,12 +7,38 @@ use Drupal\Core\Field\FieldDefinitionInterface;
   +      '#title' => t('Allowed text formats'),
   

   use $this->t()

3. +++ b/core/modules/text/src/Plugin/Field/FieldType/TextItemBase.php
   @@ -7,12 +7,38 @@ use Drupal\Core\Field\FieldDefinitionInterface;
   +      '#description' => t('Select the allowed text formats. If no formats are selected, all available text formats will be displayed to the user.'),
   

   use $this->t()

The last patch from #145 was rerolled

This is an excellent idea IMO. On a related note: once this is done, could we "kill" the formatted/unformatted text fields differentiation?

Instead of two field types, we could just have "text" with a list of allowed formatting types. And one of them being the "unformatted".

In that case, it would be possible to change the type of a field from "formatted" to "unformatted" and back easily. Moreover, it would be possible to apply *some* filters even to unformatted text if necessary. "Onomasticon" filter comes to mind. Or the one that recognises URLs in the text and adds links automatically.

+1 for Deno's idea. In new projects we are using formatted text fields in most instance where you'd expect a plain text field - mainly (but strongly) for the reason that editors should be able to add language attributes (German has a lot of loan words). The text format selectors cause a lot of clutter.

After all if would be awesome if we could enhance the accessibility on existing sites by allowing language attributes in plain text fields that would never be replaced.

+1 for #154.

And thanks to all for working on this, I'm finding this a really annoying issue.

+1 to #154. I hope that could be merged soon because it's really annoying (I'm using Allowed formats module in order to hide that selector).

Thanks all, would be great to get this in! The old patch is directly storing the checkboxes value for allowed formats in the config, eg:

settings:
  allowed_formats:
    basic_html: basic_html
    restricted_html: '0'
    full_html: '0'
    plain_text: '0'

This causes problems with the textfield widget: the allowed format doesn't exist so you get the This field has been disabled because you do not have sufficient permissions to edit it message as a non-admin user. (The textarea widget has an explicit array_filter() which makes it work as expected.)

I've updated the patch to save the allowed formats as an indexed array of selected formats, eg.

settings:
  allowed_formats:
    - basic_html

When I originally saw the symptoms of the problem (but didn't know what was happening under the covers) I tried to update \Drupal\Tests\text\Functional\TextFieldTest::testTextfieldWidgetsAllowedFormats() to get a fail before fixing it. The change didn't detect the problem however because we don't use the UI to create the text field, but I've left it in nonetheless as I think it's still probably useful. Do folk think it's worth updating the test to actually use the UI to create the fields themselves? Thanks!

• Address phpcs feedback.
• Remove use of deprecated functionality in new test.
• Address some failing tests.
• I think I found some extra text field config that hadn't been updated to the new schema.

Still todo: fix remaining tests, implement calculateDependencies(), thanks!

Guess there's no remaining tests to fix (: I've added the text formats as config dependencies, tho that's not tested. Thanks!