In D6 version of this module, it was possible to configure allowed formats per content type, but it's missing in D7. Please bring back this functionality.

Comments

Subscribe, this is killer feature for me :-)

The problem I forsee with this request is that Drupal 7 works with fields and entities and those fields can be used in multiple content types. Hence a setting per content type doesn't seem to make as much sense as a setting per field.

subscribing here also.

How do you set the default input per field?

edit already existing fields that accept text, or set upon creation of new fields that accept text. ie: text field, text areas ...

sure, per field :-)

I can't seem to set to another text format. Always reverts to the top text format on saving body field.

Hi everyone,

Subscribing & +1. This was the primary reason I used Better Formats in D6.

@BeaPower Yeah, I was just confused by that as well. Read this: http://drupal.org/node/1003262#comment-3994376 You have to order your text formats on the text format page and it seems that the order is applied throughout all content types & fields. Changing the default text format on the body field or any field for your content type doesn't do anything right now (someone please correct me if I'm wrong). From a UI perspective that dropdown under the body field shouldn't even be shown if changing it has no effect.

Thanks for reading,
-Tim

Status:Active» Postponed (maintainer needs more info)

I tend to agree with VM here. I feel that per field defaults are more useful than per entity or bundle defaults so I am focusing on that effort.

There still will be comment defaults at the bundle level.

If you feel we need per entity or bundle level defaults, please make your case here and how you see those interacting with the global and field level defaults.

I thought, the per-entity defaults would provide reasonable settings if we have many fields on an entity.
In our case, there are some formatters that are content type specific. E.g. there's a wiki filter for the wiki content type. It might be usable for all fields in a wiki-content type.
In the blog we might have some other filters for all fields.

Users might have a bunch of formattable fields, all with certain features (filter).

So in general i want to limit some formatters to some content types only.

In addition i think about some very specific fields and an input format that is limited to that field only.

Sure, the per-field solution will allow me to do the same. But it might take some more time to define everything. Important seems to me, that we have something like an overview: What content type and field supports what? (Without opening the field definition...)

There is not much time added for all new fields as you have to create the field anyway and set all the other options when doing so. There is a little more work for existing fields that may exist in a site but the benefit of a second tier of defaults would not help much. The complexity of dealing with many tiers of defaults gets worse exponentially as the tiers increase. So this is what I am worried about most and want to limit the tiers to only the ones we really need.

Maybe a solution would be something like a mass change feature that would allow you set all fields on a bundle or entity at once then you can further customize at the field level where needed.

Implementing a overview would be a big job with little benefit I think. We could want to see the other options on the fields too and we we would end up with a big complex interface or number of interfaces. The simplest way to check settings fast without going to the field definition is go to the content create page and see an entire content type at once.

StatusFileSize
new21.55 KB

I was wondering exactly which direction you were planning on going with this? An idea I came up with was putting a draggable table of the formats on the instance settings page. You can order the filters and even disable them as needed. I attached a screenshot of what I got so far. If you would like I can continue on with this.

I should add something else I was considering is putting in a admin page where you can set the defaults, then on the instance settings page having a checkbox to override the defaults. If that is checked then the weighting on the instance settings page will be used instead of the default. That way you don't have to set the filters on every field, just override the ones you want.

StatusFileSize
new7.72 KB

Here's a patch for applying per field formats. There is also the ability to set default formats per entity type under admin/config/content/formats/settings

StatusFileSize
new7.85 KB

OOPS here's a better patch. Forgot the change I made in logic to falling back to a default profile.

@intoxination, thanks for the work but it is better placed in #1275266: Add field level default format with full Better Format options.

This issue is about format defaults per bundle or entity not at the field level.

Moved the patch over to #1275266: Add field level default format with full Better Format options. This patch also does provide default format settings at the entity level, so it does work here somewhat. Not really sure about going at the entity + bundle level. I think that would really be a fringe case, as most bundles generally only have 1 field with text processing. The way this patch works:

- Set default formats per bundle.
- On the field you can override the default formats and set your own.

Status:Postponed (maintainer needs more info)» Closed (duplicate)

Status:Closed (duplicate)» Postponed (maintainer needs more info)

#1275266: Add field level default format with full Better Format options is for field level defaults not entity/bundle level defaults. This is still active pending a decision on how we are going to handle this.

A input filter default per content type would be great for me. Same content types need no editor for a short and simple text (input filter: plain text), but also use body field...

See #19. I don't think we also need to control this on bundle level, that is, if we could control the field pr. content type. This will be needed on fields we share between multiple content types.