Text formats

Input filters currently used a rather obnoxious storage system. Some input filters store their settings in variables, which makes it very difficult to programmatically track down all configuration related to an input filter.

I suggest adding the filter module to #490462: List of Modules that would need export/import stuff.

@yhahn #640302: Provide exportable for input formats and #616496: Features integration mention features.filter.inc and and have people wondering where input filter import and export should live. Would you be able to clarify what Features will and will not do so a way forward can be plotted? If Features itself will not handle this, perhaps the Exportables module could provide a wrapper to get around numeric ids for user roles and input formats? Figuring this out would then allow for proper exportables support for Better Formats (#616496: Features integration) & WYSIWYG (#624018: Exportables and Features support for WYSIWYG 7.x) to be layered on top.

I love it. This issue totally read my mind. Subscribing!

We have some bandwidth to throw at this problem if we can coordinate the work.

Is there a manual way how to do this in code for example? There are many other variables which I would like to be set when some feature is enabled, because I'm trying to build my own "out-of-box" Drupal. Features has helped me a long way, but there are some parts missing from the puzzle.

suscribe

I have recently uploaded http://drupal.org/project/input_formats to deal with the numeric ids for input formats.

It allow export input formats using Features.

Please, take a look to this module and provide some feedback :)

Coming from #624018: Exportables and Features support for WYSIWYG 7.x (Wysiwyg) and #640302: Provide exportable for input formats (Exportables), I just skimmed the code of http://drupal.org/project/input_formats. Not wanting to insult anyone trying hard to get this work somehow, but the approach taken does not look valid to me.

To start from scratch, I think that Features module itself is responsible for enhancing/fixing Drupal core where required. Otherwise, you're introducing a nightmare of interdepencies.

So what do you need? Just a machine name?

Hi @sun:

Thanks for this patch. I'm the maintainer of input formats and I will try to explain the main problems I had while coding input formats to help with this issue.

In D6, input formats are loaded from database, and there is no way to modify this. Then, I created (using input_formats module) a new level of indirection, to allow users to export their settings into code. Only a filter is created in the database, and when a text is going to be processed by this filter, it load its definition from code, and the text is processed by filters defined in code.

Also, in D6, filter settings are storaged in variables and in a table. So, when settings are exported, it not enough to use CTools to export the definitions. Something have to care about this settings, and this is other function of input format module.

Even more, besides I'm using strongarm as a dependency of input_format, variables are coded with name_of_variable_3 where 3 is the id of the input format, and input format take care to remove this number and make this variable more generic.

Let say we have the code correctly exported, using features, input_formats or whatever. Now we have the problem to load the settings. As I said above, there are no way to intercept the definition of the filter (it is taken directly from the db, without hook to modify this settings). I fixed this problem introducing the filter that works like a bridge between db and code.

And finally, we have the problem of modules that use the id for the input format to indicate which input format have to be applied to a piece of text. For example, think in a header of a view, the export is something like

  ...
  'value' => 'this is my header',
  'format' => 1,
  ...

To resume, to get a fully way to export and load text formats from code in D7 we do not only need machine names but "Text formats have to be cached like other objects does, like views, contexts, imagecache presets, etc. And we have to introduce a 'drupal_alter' before that. To have a change to load other Text Formats from code."

Related to D6. I just can say, with the tools we have, input formats is the better approach (that I found) to load input format from code without hack the core. And I'm happy to see that this will not be needed in D7, I just was looking for a solution to this issue.

Thanks for the additional insight. I've created #903730: Missing drupal_alter() for text formats and filters -- please help to get that patch into D7.

Thanks for the start sun. Further changes would be to features.filter.inc.

1. Update all functions to key by machine_name rather than format or name.

2. Add the following (which appears to have been intentionally left out):

/**
 * Implementation of hook_features_export_options().
 */
function filter_features_export_options() {
  $options = array();
  $formats = _filter_get_formats();
  foreach ($formats as $format) {
    $machine_name = check_plain($format['machine_name']);
    $name = check_plain($format['name']);
    $options[$machine_name] = $name;
  }
  ksort($options);
  return $options;
}

* Are the db_add_field() calls in features_install() needed? Isn't this covered by the hook_schema_alter()?
* Change to features_test.info is unrelated.

Re db_add_field(), right, needed because this module won't have been present when filter was installed.

Thanks for the review, nedjo! However, I'm currently not working on this patch. Instead, I want to fix this for Drupal 7:

#902644: Machine names are too hard to implement. Date types and menu names are not validated - Features module should back-port this patch to D6. Was actually triggered by my work on this patch, as I couldn't believe in how many pitfalls you can run when implementing machine names, and how many utterly wrong or needlessly complex implementations there are (even in core). Therefore, D7 has to make this really easy to do. No real API change, just an API addition.

#903730: Missing drupal_alter() for text formats and filters - depends on aforementioned patch - implements machine names for text formats natively for D7. Especially, because text format permissions are currently based on format IDs in D7, it gets even more important to do that. Only changes the internal Filter API. Other modules should use the public Filter API, nothing else, so this should also still be possible to do.

Effectively, it would make much more sense to get some traction on those two issues ASAP. It's not guaranteed they make it in, but at the very least, we should try hard to convince Dries and webchick of the benefits.

#903730-94: Missing drupal_alter() for text formats and filters and the next comment from webchick makes it sound like the issue sun is waiting for is not going to happen.

In circular logic, it looks like alex_b is suggesting using #643566: Text formats instead. (that is this issue.)

Text formats are now exportable, see http://drupal.org/cvs?commit=439782. Note that you need to use the dev version of features for now until a stable release is issued with that change.

See Debut WYSIWYG for sample exports.

#1156778: Export Filters (Input Formats) With Features for Drupal 6