Select Input Format for Each Text Field

it would be great when we could define per text field what the applied input format should be.

I'm really wanting this feature as well. I'm going to see if I can create a patch for this in the next couple of days.

Subscribing.

I wanted something like this for the longest time as well.

I've recently hacked it in in my version of the Text module, by changing the "user selects input format" to the value "-1" (plain text remains "0"), leaving the way free for setting a fixed input format (which are numbered from "1" upwards). It's a bit ugly; perhaps the real patch should use two fields (the first offers the options "plain text", "user selects", "fixed", and the second field offers the default format that should be used).

I don't have time to make a formal patch (and this is a dirty hack anyway, so it shouldn't be used as-is anyway), but here's a diff on my changed file:

Basically, "1" to "-1", then the options for the input formats get added. The condition that checks if a format selector needs to be displayed is extended to remove it not only for "0", but also for greater values. And there's an extra condition in the formatter function that runs it through the proper format filter.

But, as said, it would be much better with two separate fields, especially as that would make it possible to set a default format, but let the user choose another.

25c25,27
<       $options = array(0 => t('Plain text'), 1 => t('Filtered text (user selects input format)'));
---
>       $options = array(0 => t('Plain text'), -1 => t('Filtered text (user selects input format)'));
>       $formats = filter_formats();
>       foreach ($formats as $id=>$format) $options[$id]=$format->name;
76c78
<       if ($field['text_processing'] == 0) {
---
>       if ($field['text_processing'] >= 0) {
183c185
<   if ($field['text_processing']) {
---
>   if ($field['text_processing']<0) {
184a187,188
>   } else if ($field['text_processing']>0) {
>     return check_markup($text, $field['text_processing'], is_null($node) || isset($node->in_preview));

Arancaytar

What version of content.module is this patch against? And can you attach an actual patch file?

It applies to the text.module, not the content.module.

Thanks for this!

Any progress on this?

The patch I have in mind (and have started working on) will do this:

- add another option to "Text processing" - "Filtered text (fixed input format)"
- add a select menu titled "Default format", containing all input formats applicable (filter_formats())

If text processing is set to plain, default format is ignored.

If it is set to user selection, the input format selection form will pre-select the default format (overriding access rights to add it if the user normally can't use it).

If it's set to fixed, the input format selection form will not be shown at all.

----

I'm not sure whether to save the input format for each node the field is made in, regardless of whether the format is set to fixed or not. Doing so makes the filtering process far easier, but on the other hand changing the default format won't be retroactive.

Can't win them all. I looked at http://api.drupal.org/api/5/function/filter_form, and overriding the access permissions seems to require tedious re-implementation of a lot of its form-building code. So I left the overriding part out: If Text processing allows a user-selected input format, then the user can only see those formats they have access to, regardless of what the default format is set to. I'll have to test this a bit more to see what actually happens when calling filter_form with a "pre-selected default" that isn't listed.

The rest works, though: Fixed input format fields are rendered correctly, user-selected input format fields get the format selector with the proper format pre-selected.

This patch is rolled against DRUPAL-5, not HEAD. According to a warning message in the repository, HEAD already contains 6.x code, and I'd rather see this in 5.x-1.x-dev first than have to wait and then backport. However, on accidentally checking out HEAD, it seemed that my changes were merged in without conflict; porting to 6.x shouldn't be a major problem.

Tested and works perfectly. Thanks!

If so, could this be RTBCd?

Ditto on the patch working perfectly. It would be nice it this was in CCK for 6.x and rolled into 5.x.

Thank you. I came here looking for exactly this, and the patch worked perfectly.

A godsend, Arancaytar. Your patch works perfectly.

Not to come off as impatient, but this is dropping off the page again, and it appears to work, mostly.

I have another week to make changes to the patch if necessary, after that it will fall to someone else or have to wait till November or later...

This works great for me. Can this please be committed it is very useful!

Thanks.

Thank you for this. Makes life so much easier. I had a field into which the administrator needed to paste buy ticket button code from a ticket vendor. Unfortunately, the code contained onclick JS, which needed to be there, or the buttons don't work. So if the administrator didn't change the input format from the default to one which didn't strip out these types of code, then the buttons wouldn't work.

Asking most site admins who are adding content to remember to change the input format for a specific field just isn't practical, so this patch is exactly what is needed. Obviously it would be nice to be able to lock the input type for a field, but this patch works great as is.

Thanks much. I hope this will be added to the module for the next release, as I bet a lot of other users would also find it useful.

Greggles kindly checked this, and I have made a new version that fixes several indentation errors (the text editor invisibly substituted the spaces for tabs in some lines). The description of the new "default format" field has been slightly modified to be a little clearer. Also, several parts that are actually fairly straightforward are no longer accompanied by inline comments.

I'm afraid I'm going to violate good form for a moment to at least attempt to get this some attention. I know that the patch applies, it is apparent from the responses here that it has been tested without problems in multiple production environments, and I think the last patch fixes the remaining code style issues. So at this point, any disqualifying problem is likely going to be along the lines of "this is the wrong way to do it, start over", or "there's a comma missing from an inline comment".

Either of these don't require copious testing and could be arbitrated at a glance by a maintainer, so I dare set this RTBC in the hope that a maintainer at least looks at it. If it does need work... well, at least it doesn't sit here another month with no action.

On my site, I have now added an additional modification to the patched module, that causes the fixed format's Filter Tips to be displayed. As the patch removes the input format selector on a fixed field, the filter tips were also gone. Users were confused what format the field actually expected, and adding "(BBCode allowed)" manually to the help text was a bit of a WTF design.

However, to keep the testing work from piling up, I would rather wait for a review on the current patch before uploading the new modification.

I have discovered a bug that occurs during preview. If you create a field with a fixed input format that is not otherwise available to users, the field will show up as "n/a" during preview.

This is because the module tells check_markup to make an access check on the input format if the node is in preview or is empty (I'm not sure under what circumstances the node object would be empty, but that's what it says). As the fixed input format is supposed to override filter permissions, this causes anomalous behavior: While the final node displays the field as intended, during preview the filter is blocked by an access check.

To fix this, I have inserted an additional condition that will bypass the access check if the input format is not selected by the user.

Tracking the issues in this excellent patch, I will install it soon, and give feedback.

No longer my business.

I will have next to no time to dedicate to development for the next half year, and I don't plan on spending the little time I do get on making sure this patch stays clean (let alone improving it or porting it to 6.x). I've watched it for five months, and it applied when I last checked out 5.x-dev but I can't guarantee it from now on. Please take it, leave it or get someone else to track it. It's not my intention to sound bitter, sorry.

I do appreciate the work you've done on it, regardless, as it was quite helpful for me personally. Would it be possible for you to make the last patch you did available here (that addressses the n/a display bug) before you go about your life?

And thanks.

goddess:

I haven't tested this code (and I'm not going to, since my needs don't require me to), but it looks like the preview bug can be fixed by changing one line in text_field_formatter in text.module.

change

 return check_markup($text, $item['format'], is_null($node) || isset($node->in_preview));

to

  return check_markup($text, $item['format'], $field['text_processing']==2?(is_null($node) || isset($node->in_preview)):NULL);

Untested, and the access testing is there as a security sanity check, so this may be a security issue (but in theory the user would be able to view/execute the content after previewing anyways, so perhaps it's moot).

Arancaytar, thanks for putting together this patch -- saved me a little time. IMO this is a serious defect in CCK, since it is not really possible to set a default format via the form_alter hook.

I've rerolled the patch from what I have currently. I think this should take care of both the n/a bug and the fixed filter tips. (From UMTS and the battery's nearly empty - hope the upload goes fine.)

Thanks, folks. Much appreciated.

Really sorry for letting this go for such a long time without any feedback. We've been really focused (and still are) on the 'cck for D6' port / refactoring, which is critical for Drupal 6 to actually 'take'.

I agree that this would be a useful feature. However, messing with input formats is sensitive stuff and can lead to nasty edge cases. On a (semi-)related note, there has been several attempts in core at assigning 'default input formats' to user roles, all of which were abandoned because of conceptual flaws.

Not to say the current effort should be abandoned, this just makes me a little nervous. We need more careful testing and insightful reviews than the '+1' and 'works for me' that have been voiced so far (no offense intended).

For instance, I'd think that a user trying to create / edit a node without having the rights to use the specified format for the field should get an 'access denied' page. More consistent with core behaviour : if I don't have access to the 'full HTML' format, I get access denied when trying to edit a 'Story' whose body is 'full HTML'.

But that /would/ force the input format system to either get a widely extended permissions system or to be worked around for custom fields.

For example, the site I am extensively using this for uses several content fields with "syntax-coloring" filters that are not supposed to be used anywhere else. If the "Fixed" filter has to pass the user access check, this means I either allow everyone to use this filter everywhere, or I do not use filters at all and instead write a lot of custom code when rendering the node...

The security issue lies not so much with regular users as it does with a jointly administrated site with different permissions. You would need to ensure that a Content Type admin can't give users implicit permission to use a filter in some field unless he is also an Input Format admin - while at the same time avoiding a close meshing of the two modules.

Re-rolled a patch for CCK 5.x-1.9 based on Arancaytar's most recent patch, but with a few changes:

• Spacing, tabbing, and code style.
• Made optional a feature that the previous patch otherwise enforced -- input format tips. Some of my fixed input format fields don't require tips and I assume I'm not alone in this.
• Reworded the growing list of options to be more readable. See attached image.

Any chance this can be ported to 6.x? Or does this feature already exist? Thanks!

6.x Request as well.
Or is there another cck module that allows full html/php input already?

I think it would be great to be able to use Markdown syntax in custom CCK fields, and as far I understand that is what this discussion is about.

How about doing this the way the http://drupal.org/project/filterbynodetype module does for node bodies? I allows to select any number of input formats valid for a node type. So if you select only one then the input format is fixed, as suggested in this discussion.

One way or the other consider this an official 6.x feature request ;-)

tracking

May I suggest giving the Better Formats module a try?

Well, Better Formats' description sound great, but from this http://drupal.org/node/350696 it seems that the module doesn't really do what this issue is all about (at least not in the current 1.x version).

This patch works for me against cck-6.x-2.5. It's not as feature filled as the 5.x version in earlier comments, but might help someone.

There is an interaction with Better Formats you should be aware of - if Better Formats is enabled and you've specified a fixed format for a field, the Input Formats part of the form may still appear when a user adds/edits a node. The patch will still do its work, but users might be confused by seeing an Input Formats section that's ineffective.

The attach widget isn't working for me, so I'll try inlining the code.

diff -ruN .cck/modules/text/text.module cck/modules/text/text.module
--- .cck/modules/text/text.module       2009-07-18 01:18:07.000000000 +0000
+++ cck/modules/text/text.module        2009-08-18 07:04:39.000000000 +0000
@@ -52,13 +52,24 @@
   switch ($op) {
     case 'form':
       $form = array();
-      $options = array(0 => t('Plain text'), 1 => t('Filtered text (user selects input format)'));
+      $options = array(0 => t('Plain text'), 1 => t('Filtered text (user selects input format)'), 2 => t('Filtered text (fixed input format)'));
       $form['text_processing'] = array(
         '#type' => 'radios',
         '#title' => t('Text processing'),
         '#default_value' => is_numeric($field['text_processing']) ? $field['text_processing'] : 0,
         '#options' => $options,
       );
+      $formats = filter_formats();
+      foreach ($formats as $id=>$format) {
+        $formats[$id]=$format->name; // replace format object with name only
+      }
+      $form['default_format'] = array(
+        '#type' => 'select',
+       '#title' => t('Default format'),
+       '#description' => t('The default format will only have an effect when the field is not processed as plain text. When the format can be selected by the user, the user must have permission to access this format.'),
+        '#options' => $formats,
+       '#default_value' => isset($field['default_format']) ? $field['default_format'] : variable_get('filter_default_format', 1),
+      );
       $form['max_length'] = array(
         '#type' => 'textfield',
         '#title' => t('Maximum length'),
@@ -107,7 +118,7 @@
       return $form;
 
     case 'save':
-      return array('text_processing', 'max_length', 'allowed_values', 'allowed_values_php');
+      return array('text_processing', 'default_format', 'max_length', 'allowed_values', 'allowed_values_php');
 
     case 'database columns':
       if (empty($field['max_length']) || $field['max_length'] > 255) {
@@ -116,7 +127,7 @@
       else {
         $columns['value'] = array('type' => 'varchar', 'length' => $field['max_length'], 'not null' => FALSE, 'sortable' => TRUE, 'views' => TRUE);
       }
-      if (!empty($field['text_processing'])) {
+      if (!empty($field['text_processing']) && $field['text_processing'] == 1) {
         $columns['format'] = array('type' => 'int', 'unsigned' => TRUE, 'not null' => FALSE, 'views' => FALSE);
       }
       return $columns;
@@ -166,9 +177,10 @@
 
     case 'sanitize':
       foreach ($items as $delta => $item) {
-        if (!empty($field['text_processing'])) {
+        if (!empty($field['text_processing']) && $field['text_processing'] != 0) {
           $check = is_null($node) || (isset($node->build_mode) && $node->build_mode == NODE_BUILD_PREVIEW);
-          $text = isset($item['value']) ? check_markup($item['value'], $item['format'], $check) : '';
+          $format = $field['text_processing'] == 2 ? $field['default_format'] : $item['format'];
+          $text = isset($item['value']) ? check_markup($item['value'], $format, $check) : '';
         }
         else {
           $text = check_plain($item['value']);
@@ -230,7 +242,7 @@
  */
 function theme_text_formatter_trimmed($element) {
   $field = content_fields($element['#field_name'], $element['#type_name']);
-  return ($allowed =_text_allowed_values($element)) ? $allowed : node_teaser($element['#item']['safe'], $field['text_processing'] ? $element['#item']['format'] : NULL);
+  return ($allowed =_text_allowed_values($element)) ? $allowed : node_teaser($element['#item']['safe'], empty($field['text_processing']) ? $element['#item']['format'] : ($field['text_processing'] == 2 ? $field['default_format'] : $element['#item']['format']));
 }
 
 function _text_allowed_values($element) {
@@ -407,7 +419,7 @@
 
   $element[$field_key]['#maxlength'] = !empty($field['max_length']) ? $field['max_length'] : NULL;
 
-  if (!empty($field['text_processing'])) {
+  if (!empty($field['text_processing']) && $field['text_processing'] == 1) {
     $filter_key = $element['#columns'][1];
     $format = isset($element['#value'][$filter_key]) ? $element['#value'][$filter_key] : FILTER_FORMAT_DEFAULT;
     $parents = array_merge($element['#parents'] , array($filter_key));
@@ -450,7 +462,7 @@
     '#columns' => $element['#columns'],
   );
 
-  if (!empty($field['text_processing'])) {
+  if (!empty($field['text_processing']) && $field['text_processing'] == 1) {
     $filter_key  = (count($element['#columns']) == 2) ? $element['#columns'][1] : 'format';
     $format = isset($element['#value'][$filter_key]) ? $element['#value'][$filter_key] : FILTER_FORMAT_DEFAULT;
     $parents = array_merge($element['#parents'] , array($filter_key));

This is being implemented in Better formats module. Please, check out: #350696: Per field format settings with full BF options via CCK widget.