Allow text fields to enforce a specific format

TestTranslationTestCase is failing, that looks like the only issue

In general this looks really good. Below is a code-review but those are mostly minor issues.

I have one more general problem with this. Instead of the Form API element trying to figure out, what Field API wants to allow as text formats, really it should be the other way around: Field API specifying upfront in text_field_widget_form() what formats it wants to allow.

The problem is that there is no facility for that in the #text_format Form API element. So I would suggest opening a new issue for that, something á la: "Introduce a #formats property for the #text_format element, to preselect/-reduce available formats"

Here's the detailed review:

+++ b/modules/field/modules/text/text.module
@@ -87,15 +87,40 @@ function text_field_settings_form($field, $instance, $has_data) {
+    // Check for disabled filter formats.
+    if (empty($format->status)) {
+      continue;
+    }
+    $formats[$format->format] = $format->name;

Minor, but I think if ($format->status) would be more concise. That's just my opinion, though.

+++ b/modules/field/modules/text/text.module
@@ -87,15 +87,40 @@ function text_field_settings_form($field, $instance, $has_data) {
-      t('Plain text'),
-      t('Filtered text (user selects text format)'),
+       t('Plain text'),
+       t('Filtered text (user selects input format)'),

These changes need to be reverted, the indentation was fine before.

+++ b/modules/field/modules/text/text.module
@@ -87,15 +87,40 @@ function text_field_settings_form($field, $instance, $has_data) {
+    '#default_value' => !empty($settings['text_formats']) ? $settings['text_formats'] : array(),

We can initialize the default value of these settings in text_field_info(). That way the check isn't needed.

+++ b/modules/field/modules/text/text.module
@@ -87,15 +87,40 @@ function text_field_settings_form($field, $instance, $has_data) {
+    '#states' => array(

Yay, I love more #states in core!!!

+++ b/modules/filter/filter.module
@@ -866,6 +866,21 @@ function filter_process_format($element) {
+    // If text_processing == 1, skip this step, since it will fall back to only formats the user has access to.

That comment is incorrect. The condition itself is OK, but it is not described correctly.

+++ b/modules/filter/filter.module
@@ -866,6 +866,21 @@ function filter_process_format($element) {
+    if (!empty($field_info['settings']['text_processing']) && isset($field_info['settings']['text_formats'])) {

Since text_processing is either 0 or 1, I think simply dropping the !empty() should be fine. That's just a matter of taste, though.

I didn't try it out (yet), but I think $field_info['settings']['text_formats'] will always be set (at least if we initialize the default as explained above), so a !empty() would be in order here, I think.

+++ b/modules/filter/filter.module
@@ -866,6 +866,21 @@ function filter_process_format($element) {
+      // Hide unavailable formats. (They'll be keyed as '<format_name>' => 0).

We don't use abbreviations in comments. Also I think "unavailable" might be misleading. Maybe we could just write:

Formats that have been disabled for this field instance, have a value of 0.<code> Or something like that...

<code>
+++ b/modules/filter/filter.module
@@ -866,6 +866,21 @@ function filter_process_format($element) {
+      // @TODO: How do we define a sensible default?
+      $element['#format'] = end($options);

Ideally the default would have been specified on the field instance setting form. I don't know, off the top of my hat, though, why that might not be the case.

I opened #1423244: #allowed_formats property for #type 'text_format' to filter available formats.

I posted some example code there, and if it really is as easy as I claim over there, then we might want to re-merge the issues. Not sure, though.

+++ b/modules/field/modules/text/text.module
@@ -42,14 +48,21 @@ function text_field_info() {
+        'text_processing' => 1, ¶

@@ -96,6 +109,29 @@ function text_field_instance_settings_form($field, $instance) {
+  ¶

+++ b/modules/filter/filter.module
@@ -861,6 +861,28 @@ function filter_process_format($element) {
+      // Use the default format value from the field settings. ¶

Trailing whitespace.

+++ b/modules/filter/filter.module
@@ -861,6 +861,28 @@ function filter_process_format($element) {
+        // Filter the list of options to only formats the field has permitted and the user has access to.

This comment is incorrect. It's not about whether the user has access to this format or not. That is being handled by the code preceding the bit in the patch. This is about checking whether each of the formats that are allowed for the user, are in the allowed formats for the textfield. That said array_intersect() could be used here, which would make the code a bit leaner.

I still think this should be postponed on #1423244: #allowed_formats property for #type 'text_format' to filter available formats, so marking as such. Please revert if you disagree.

This is a duplicate of #784672: Allow text field to enforce a specific text format, which is the equivalent issue for Drupal 8. We should only have one issue open for this, and any patch needs to get committed to Drupal 8 first before being considered for possible Drupal 7 backport.

As far as I know, closing this will not prevent the testbot from testing any patches that are posted here (I could be wrong though)... If so, this issue could still be used as a place to get the testbot to test Drupal 7 versions of any patches, which was the original reason it was opened above.