Store filter settings per format in {filter}

subscribing

Re-rolled against HEAD.

Reverted some not strictly necessary changes.

Quite. A. Patch.

Thanks for removing that part. Clearly belongs into the other issue.

In this patch:

- Removed the redirection to the format overview page after saving an existing format. Total UX nightmare.

- Introduced 'default settings' property for hook_filter_info() items. Default settings are automatically merged into $filter->settings. This is important, because filters in newly created text formats do not have any settings yet. Thanks to this, 'prepare', 'process', and 'tips' callbacks no longer have to duplicate the default settings all over the place. Default settings are defined once and all callbacks can simply rely on them. Furthermore, filter implementations can introduce additional settings at any time, and those need default values, too. Lastly, we can remove the hard-coded default settings from system.install that would have been added in a previous patch.

- Changed check_markup() to pass along the (new) $cache argument to 'prepare' and 'process' callbacks, so they know whether the (also passed) $cache_id is actually used. This was somehow forgotten when the $cache argument was added to check_markup().

- Updated filter.api.php accordingly.

This one should pass. Includes some further, nice clean-ups for the core filter tests.

Actually I think this is RTBC. I hope that dropcube can give it another review.

Better title.

Fixed the upgrade path.

Summary:

Problem

• Filters abuse the system variable storage to store their settings, per format.
• Because they are using variables in the form of "filter_foo_$format", we are not able to improve the UX for the text format/filter configuration pages, because the text format must be created first, so the filter settings can be configured on a separate page using the $format id of the text format in their system variable names.

Details

• Filters are stored in the {filter} table, one row per filter and format.
• Currently, {filter} simply contains the the info which filters are enabled for a format.

Solution

• We extend the {filter} table with a 'settings' column, so filter settings can saved when the text format is saved.
• To not "forget" about the settings of disabled filters in a text format, we add a 'status' column, so we can only query enabled filters for a text format.
• To not have to repeat a filter's default settings all over the place, we extend the hook_filter_info() definition with a 'default settings' array, which is automatically merged into the filter settings. Thereby, all filter callbacks can safely rely on all settings.

Just fixed some typos in the adjusted documentation.

I don't think that anyone can have any further objections to this, especially since we managed to get a flood of patches as preparation for this "final" master patch already in. Simply put, this is the conclusion and last API change of FilterSystemRevamp.

Additionally, it is a blocker for #558666: UX/security: Revamp text format/filter configuration (which is probably one of the most confusing UIs in Drupal).

- Fixed PHPDoc of module update function.

- Added PHPDoc for filter_format_load().

- Added CHANGELOG.txt entry.

- Added some more verbose information about the flow of the callback definitions in the API docs.

Hope that helps. :)

Great patch. Committed to CVS HEAD.

Marking as needs work for upgrade docs.

#653068: Update documentation is incomplete

changing tagging scheme

Summary of this issue in comment #18 above, and committed patch in #22... let's see. I'm trying to figure out what was a d6 to d7 change from #18 and the patch.

But see
http://drupal.org/update/modules/6/7#hook_filter_info

It looks like all of this was a change added to the existing change -- hook_filter() in d6 changed to hook_filter_info(), and this just added to it a bit. That change is already documented in the d6/7 update guide.

Two columns were also added to the {filter} table, but that won't break any d6 modules.

So it looks like the only thing we need to add to the 6/7 module update guide is the part about filter settings being stored in the db table vs. in a variable. But looking at the update function in the patch, it only looks like it's updating the HTML and URL filters, not any filters that other modules may have defined, so I don't see that this is going to affect contrib/custom modules. I'm inclined to say it doesn't need update doc after all.

Feel free to reopen and explain what needs to be update documented...