Modify module to have one set of config options per input format

Here's how I would personally modify the module. I haven't included anything about upgrading yet: I'm not sure what the best approach would be. Here's one idea.

1. The default body config, spec and help settings for each input format are copied into the new variables, and they'll be the settings used.
2. The old settings (htmLawed_format_x) aren't automatically deleted.
3. A separate module can be enabled that lets you view your old settings to make it easier to copy them to new input formats. This process is not automatic (I can't think of a sensible way it could be).
4. When you've completed the migration and no longer need the old settings, there's an option to delete them.

What do you think?

Hi alpha2zee, thanks for the reply.

one does have an option to have just one htmLawed setting for an input format.
...
Regarding the 'Body' vs. 'Other' issue, which is separate from one htmLawed setting per input format, the problem still remains

For me these are two sides to one problem. There's a particular way that Drupal's input format architecture works. At the most basic level there are filters, like this one. As I see it, a filter can be viewed as a function: it takes an input and delivers an output. Where possible (and certainly with a filter like htmLawed which might eat resources) you want to always have the same output for the same input (which makes things simpler at higher levels, and allows you to cache). It follows from that idea, that you really only want to have one set of config options (this means not having multiple content types or body-, teaser-specific settings, etc.). It really should be (imho) one set of config options per filter, period.

So what's the Drupal way of doing content type specific settings? Using input formats. This way you can create a completely customised input format for one situation, and an utterly different one for a different situation. As htmLawed stands, it works at the filter level, but offers functionality that lives at the input format level. What do I do if I want to have htmLawed and filter x to run for content type story, but htmLawed and filter y to run for content type page? I can't (not using htmLawed's content type functionality). As well as this, it's easier for a module running at a higher level to understand the context and make a correct decision about whether this textarea represents the body, a block, etc. (In fact, this was the initial problem that brought me to the issue queue - the filter was trying to decide if it should be in body or other mode, and made the wrong decision because it just doesn't have sufficient information, as it's really supposed to be a pure function.)

If you do use htmLawed with better_formats to solve the problem I describe above then you're duplicating functionality, and you have lots of settings hanging around to confuse the user (ok so although it says on this filter that it will use these settings for this content type, better formats is actually going to select an entirely different input format that has different settings). It's a recipe for confusion imho.

Also, caching can lead to unpredictable results (because the same filter yielded different results despite having same input, due to some change in context); not caching obviously has performance implications, and would certainly be a deal-breaker for me personally.

It also means that as other modules are released for interacting with input formats, there's a good chance they won't play nicely with it.

Basically, as I see it, all the functionality offered by this module is great - but it should not live in a filter. If you cut down this filter to something like my patch and use better formats you have a cleaner, less confusing, and more performant solution. I think the only thing that better formats can't do is change input format for teaser/body and for other. Maybe there's already a contrib module that does it; if not, then you can write the functionality as a separate module that isn't a filter.

Thanks for your time,

Andy

I've just taken a quickish look, and can't find any module for (2). Maybe it would be worth seeing if the author of better_formats would accept a patch to add the functionality there?

Drupal 7 core takes care of (1)

I didn't know that, that's cool!

(3) having Drupal save filtered anand not raw content

It still seems to me that this shouldn't live in the filter. If I want to save filtered content to the database, then it would be nicer to save the output of the whole input format (not just the individual filter). And it ought to be independent of htmLawed: maybe for one content type I don't want to use htmLawed but I still want to save the filtered output to the database.

Btw, imho saving the filtered content to the db is quite a big change to the default Drupal input format system, so I think it needs lots of clear warnings!

Just my 2 cents

Hi alpha2zee

I'll stop nagging you after this, but thought I might give it one last go! If I helped create a separate module that handled saving filtered content to the database, would you be ok separating that functionality from the htmLawed filter?

Thanks for your time.

Thanks alpha2zee!

Thanks for all the hard work you've put in alpha2zee!