Enable different default input formats for authenticated and anonymous users

I made a patch, you can uncheck "default" input format for user roles. (in standard version, default input format cannot be unchecked).

E.G.: This is useful when you use htmlarea for "editor" user role , but for e.g comments and forum topics you want to set "filtered" html input format for e.g. anonymous or authenticated users.

(for version 4.6.4)

Not so fast. // $args[] = variable_get('filter_default_format', 1); commented out line has nothing to do in core. And before commit, we need to ask Ber & Steven what's the reason for current approach (Ber was the one who redid the admin interface and Steven is the filter maintainer).

The reason I opted for a site-wide default input format is because at that time there were still plenty of modules calling check_output() without any format and converting them to use formats was non-trivial. If we can ensure not a single module calls check_output() without letting the user enter a format, there is no problem. We would need to abolish FILTER_FORMAT_DEFAULT.

We'd need to make sure no existing database records use FILTER_FORMAT_DEFAULT, and that when a format is deleted, any content using this format is converted into the content /author/'s default format (rather than the non-existant site-wide default, or the format for the person doing the deleting). This is non-trivial.

This is a suggestion. I have only been looking at the filter.module source (HEAD) for half an hour, so I may have missed something.

Assume an extension in which the filter administrator can define a site-wide order of preference for the filters, like a weight factor. Then filter_form() can be modified to set #default_value to the most preferred filter that the user has access to, if $value was undefined in the call.

This would address the objective of the original post and keep a "default" format for other reasons (see below).

Consequences:

a) for the administrator: "Set default format" does not apply to the default selection for users, but to the fall-back format that is used to filter content with in case somehow no format is supplied [1] to check_markup(). Thus it becomes a security setting in stead of a preference setting. The button can be renamed into something like "Set fall-back format" or "Set secure format".

b) for the programmer: the documentation for filter_form() becomes confusing or misleading due to the name of the constant. A new constant could be introduced (with the same value) for use with this function, so that the API would become, e.g.,

filter_form($value = FILTER_FORMAT_BEST, $weight = 0, $parents = array('format'))

Calls to filter_form(FILTER_FORMAT_DEFAULT) would still work, although not do exactly as suggested by the name of the argument. But I am guessing those are pretty rare.

While at it, it might be better to rename the other uses of FILTER_FORMAT_DEFAULT to FILTER_FORMAT_FALLBACK...

What do you think?

Regards,
Bastiaan Veelo.

[1] If I am not mistaken, this could be considered a bug or at least deprecated behaviour, and could be detected by check_markup and logged to watchdog.

Regarding the above proposal, instead of introducing a new constant it could be better to have

filter_form($value = '', $weight = 0, $parents = array('format'))

and check for emptyness of $value?

Bastiaan.

Please see http://drupal.org/project/filter_default which provides some of the functionality this issue requests.

I'm marking this a duplicate of http://drupal.org/node/11218 as there is more activity over there.