Through building and maintaining the Better Formats module I have gained insight in many different ways that I and others would like Drupal's input format system to work. There are 2 key points that make the current system in need of help.
- Every site has different needs and use cases.
- Current format system is not extensible.
There are 3 categories of features that site admins need to be able to control.
- Allowed formats
- Default formats
- Display options
Many times it is appropriate to control the allowed or default formats at a more granular level then site wide. Use cases go from per role to per content type to per field. Because of the wide range of use cases, with none being overly more popular than others, it is hard to say what should go into core.
When controlling the allowed formats and default formats on such different levels, you inevitably run into issues that a user does not have format permissions but has create/update permissions for a piece of content. This leads to a hierarchy of fallback formats to attempt to provide a good user experience or simple disallowing the action as is done in core now. Use case for fallbacks and disallowing vary just as much and you can easily get into tangled messed of rules and exceptions that is harder to maintain and/or rework than it is any good.
Currently there are several issues in the core queue (some listed here: http://alanio.net/blog/2009/01/d7-issues-interest) that deal with modifying the format form in one way or another. Many of them could easily be solved easily through contrib if the system was easily extensible.
Proposal
- Make filter_form context aware.
- Add a hook_filter_form_alter.
- Use only a safe and simple default system in core.
filter_form(), although not a true sub-form, is a a sub-form in concept. It is added to every format able field. It deserves to be treated as such. Making it context aware by passing the field type information (node, node type, comment, block, etc) condition decisions can be made. Using a hook we can allow modules to fine tune the formats that are shown to the user, the default format selected, and how the formats are displayed to the user. Since setting allowed and default formats starts to cause conflicting issues that will increase the complexity of the core system making it that much harder for sites to build their own systems, I recommend keeping the core default system as simple as possible and not include any allowed format settings except at the current permission level.
I have purposely, not gone into full detail on all the different scenarios and issues that arise with them to keep this post as short as possible. I can go into those in the comments if need be.
I am currently working up a working concept of this for Better Formats 2.x then I will post a patch for D7. As I am writing this though I would like to hear any thoughts about this approach.
Comments
Some thoughts
Thanks for stopping by and talking with me at DrupalCon.
I agree with a lot of what you're saying here. In some ways, this problem is actually going to be worse for D7 than it was in D6 (at least with the code as it currently exists). This is due to http://drupal.org/node/125315 and the addition of the #text_format property. Before, in D6, modules called filter_form() on their own while building a form, so that if you wanted to modify the text format selector you could at least do it with hook_form_alter(). Now, the form element doesn't even get added until the #process stage of Form API and Drupal does it behind the scenes, well after hook_form_alter() is invoked, if I'm not mistaken. So I'm not even sure how a module would be able to do things like remove a particular text format from the list only when certain conditions are true. (However, the good news is that modifying the default text format is extra easy now, since you can just modify the #text_format property itself).
Overall, it seems like a real problem, and needs a solution. In some ways it may be a more general problem with the Form API, though? Although I sort of see your logic for why filter_form() is a bit of a special case. Are you filing an issue on d.o. about this?
In terms of what belongs in core, I believe the answer is "as little as possible". Core should control permissions for the text formats, and have a default ordering for them. When constructing the filter form for a particular user, it presents the list of formats that user has access to, in the default order, and leaves it at that. That is more or less what we are doing at http://drupal.org/node/11218. It is then up to contrib modules to make changes -- if they want to remove some options from the form, reorder them, change the default, etc., based on whatever criteria they feel like, they should have an opportunity to do that.
By the way, I think you mentioned interest in seeing my presentation, since you had to miss it to videotape the other one. The video is up now, at http://dc2009.drupalcon.org/session/path-richer-text-input-format-improv... (I haven't looked at it at all, so I don't know if the audio is good). I could post my slides as well, although the thing is, I was going back and forth between the slides and demos a lot, so I don't think the slides would make that much sense on their own.