There is some movements to make module's settings exportable to support things like the Features module and migration and deployments better.

It would be really great if the Better Formats module could take care of exporting input formats and its settings and do the Features integration. This way one could package input formats into Features in a very powerful way.

I'll look into providing a patch for this.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

catch’s picture

I'm also interested in this, most standard way would be to use ctools exportables. I'm unlikely to have time to write a patch, but would definitely review / test one to get it rtbc.

nedjo’s picture

Input formats are already included in features via the features.filter.inc file, though it doesn't yet include a hook_features_export_options() implementation so filters don't appear as a component that can be added to features.

Add this to get filter formats at least showing up:


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

Of course, the additional data from better formats isn't included.

catch’s picture

Title: Make setups exportable and support the Features module » Features integration
Status: Active » Needs review
FileSize
3.36 KB

Here's a very rough patch. Doesn't yet attempt to integrate with features' own input format integration. Also relies on hard coded user roles etc. and reverting isn't working yet with latest features beta. Hopefully gets things off to a start though.

dragonwize’s picture

Good work catch. I will review this and hopefully be able to help out soon.

catch’s picture

Reverting now works. So within itself, this is somewhat there, the real problems are how to deal with numeric / arbitrary user roles and format ids. I'm using this for upgrading a site from Drupal 5 to Drupal 6 (which it's perfect for) rather than trying to build features to deploy on multiple different sites so this is likely as far as I'll take it at this point. However I'll continue to try to keep an eye out on this issue, and I also need wysiwyg module support for exactly the same reason.

mrfelton’s picture

registering my interest in this...

EDIT: The seems to do nothing for me (using very latest features)... I see no option to export better formats settings from within features.
EDIT2: I take it back... works perfectly!

rickvug’s picture

Issue tags: +CTools exportables

tagging.

DeeLay’s picture

subscribe

wik’s picture

subscribe

Cyberwolf’s picture

Subscribing.

Mac Clemmens’s picture

subscribing

ManyNancy’s picture

Subscribing

dagmar’s picture

I have recently uploaded http://drupal.org/project/input_formats to deal with the numeric ids for input formats. Please, take a look to this module and provide some feedback :)

Maybe we can make an integration with this patch and import better formats settings using machine_names instead of numeric ids.

Johnny vd Laar’s picture

subscribing

FiNeX’s picture

subscribing

nedjo’s picture

See #624018: Exportables and Features support for WYSIWYG 7.x on Wysiwyg module for relevant approaches and discussion.

lolmaus’s picture

Subscribing

wizonesolutions’s picture

Hi - do you guys think this will make it into Better Formats 2.x? Seems like I'll be applying the patch for now. 1.2 doesn't appear to have it.

Thanks,
Kevin

YesCT’s picture

a lullabot article on a wysiwyg feature mentions this issue is necessary before better formats could be used in a feature.
http://www.lullabot.com/articles/wysiwyg-feature

I mention this because I was setting up a new site, and I thought, Oh great! A Feature I can just grap, they probably use better formats ... but alas they could not. (also subscribing)

Josh Benner’s picture

subscribing

DamienMcKenna’s picture

Status: Needs review » Reviewed & tested by the community

The patch still works with Features v6.x-1.0-rc1. +1

DamienMcKenna’s picture

Status: Reviewed & tested by the community » Needs work

The UI works but the output is incorrect.

  • I made a few changes on the input filters defaults page and saved the changes.
  • On the Features recreate page for an existing feature I selected the better_formats item in the "Edit components" selector.
  • When I selected roles in the list on the left a new component block was added to the right listing all of the rid's in the database.
  • As I clicked roles on the left the numbers the span changed its class from "features-detected" to "features-source".
  • I selected two roles and downloaded the feature.
  • Opening mymodule.info file I see the following:
    features[better_formats][] = "1"
    features[better_formats][] = "2"
    features[better_formats][] = "3"
    features[better_formats][] = "4"
    features[better_formats][] = "5"
    features[better_formats][] = "8"
    features[better_formats][] = "9"
    

    Problem 1: This should instead have only listed the two roles I had selected.

  • Opening mymodule.features.inc I see the following:
    /**
     * Implementation of hook_better_formats_default().
     */
    function mymodule_better_formats_default() {
      $defaults = array();
    
      $defaults[] = array(
        'rid' => '1',
        'type' => 'node',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '1',
        'type' => 'comment',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '1',
        'type' => 'block',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '25',
      );
    
      $defaults[] = array(
        'rid' => '2',
        'type' => 'node',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '2',
        'type' => 'comment',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '2',
        'type' => 'block',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '25',
      );
    
      $defaults[] = array(
        'rid' => '3',
        'type' => 'node',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '3',
        'type' => 'comment',
        'format' => '4',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '3',
        'type' => 'block',
        'format' => '1',
        'type_weight' => '1',
        'weight' => '25',
      );
    
      $defaults[] = array(
        'rid' => '4',
        'type' => 'node',
        'format' => '2',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '4',
        'type' => 'comment',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '4',
        'type' => 'block',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '25',
      );
    
      $defaults[] = array(
        'rid' => '9',
        'type' => 'node',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '9',
        'type' => 'comment',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '9',
        'type' => 'block',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '25',
      );
    
      $defaults[] = array(
        'rid' => '5',
        'type' => 'node',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '5',
        'type' => 'comment',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '5',
        'type' => 'block',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '25',
      );
    
      $defaults[] = array(
        'rid' => '8',
        'type' => 'node',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '8',
        'type' => 'comment',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '0',
      );
    
      $defaults[] = array(
        'rid' => '8',
        'type' => 'block',
        'format' => '0',
        'type_weight' => '1',
        'weight' => '25',
      );
    
      return $defaults;
    }
    

    Problem 2: Clearly this should only list values where "rid" was one of the two roles I selected.

nedjo’s picture

Should not be applied without suitable machine names. Most promising model is the approach used in #624018: Exportables and Features support for WYSIWYG 7.x.

pearcec’s picture

sub

dkingofpa’s picture

Version: 6.x-1.1 » 6.x-1.2
Status: Needs work » Needs review
FileSize
5.24 KB

Reworked patch from #5. The numeric IDs are still exported, but not used for the revert/rebuild.

1) Now uses machine names from the roles table for roles.
2) Now uses machine names from the exportables table for input formats.
3) Only the selected better formats are exported as requested by #22.
4) Exported defaults are now placed in their own file: [module].features.better_formats.inc

I did this against 6.x-1.2 since that was the last released version.

scottrigby’s picture

Status: Needs review » Needs work

@dkingofpa: why is there a left join on {exportables}? I may be missing something

dkingofpa’s picture

@scottrigby: There is a left outer join on {better_formats_defaults} and {exportables} because better formats stores a non-existent input format, 'site default', as id 0. The {exportables} table only stores machine names for existing input formats (for example filtered_html and full_html). Without the left outer join, better formats for all the selected roles may not be exported.

dkingofpa’s picture

Status: Needs work » Needs review

Haven't heard anything more so I'm moving this back to 'needs review'.

scottrigby’s picture

@dkingofpa: Nice - this does seem to work smoothly from testing so far... after enabling exportables & input_formats modules :)

The problem is those aren't set as dependencies; resulting in two errors: missing {exportables} table, and call to undefined function (input_formats_load_by_name()). We could wrap the query/functions in module_exists() - but then users would wonder why exports aren't working.

Personally I'd just add dependencies to better_formats since we always use features to store configs - but not everyone does. Maybe put this in an optional sub-module (better_formats_export) or something?

Either way, features would then need to add better_formats (or submodule) to dependencies[] in the feature when exporting. Then it seems like we'd be covered!

scottrigby’s picture

Status: Needs review » Needs work

Also in better_formats_features_export_render() the table needs to be aliased, otherwise it fails with db prefixes:

-          JOIN {role} ON bf.rid = role.rid
+          JOIN {role} role ON bf.rid = role.rid

I'd re-roll the patch for further discussion, but i think it needs more work, per #29.

dixon_’s picture

Issue tags: -CTools exportables

Really nice to see some work on this! I'll jump in later today and review and test the latest patch!

dkingofpa’s picture

Re-rolled patch from #25.
Fixed table alias as noted in #30 (good catch).
Fixed call to watchdog in export_rebuild to provide useful info.

As per #29...I guess that's an issue for the maintainer, dragonwize. I don't think I'm going to be working on that for a multitude of reasons (module stagnation, D7, don't know what solution dragonwize wants).

dragonwize’s picture

Just to give my thoughts on this:

This is a feature that I personally do not need to see the value in, at least in its current form. However, I do see that many people do and that is great. I see and read every post made in the issue queue, unless the notification fails for some reason, so even though I may not comment on every thing I will chime in when asked or I feel the need.

That being said my opinion, which can always be debated, is that this work continue in this thread with the people who care about the feature participating.

I do not see a patch to the core BF module with these features except to add any API level support for this feature.

I would support this being a separate module as suggested in #29 especially in D6.

D7 has built-in support for string format IDs and much better format support in general. So depending on the level extra changes needed in D7 to make this happen I could see it integrated or as a separate module.

When the code in this queue is sufficiently tested and is reviewed by several people, I will commit it.

tangent’s picture

Status: Needs work » Needs review
Issue tags: +Features integration
FileSize
4.77 KB

I would really like to see this feature get added.

I've created a modified version of the patch, created against 6.x-1.2 but it should also apply to 2.0-dev I believe. It moves most features hooks to a separate include and changes some of the hooks to show friendly names. Better Formats global settings are just drupal variables that can be handled with strongarm so they aren't handled here. This patch works well enough for me.

DamienMcKenna’s picture

Status: Needs review » Needs work

Needs some formatting updates per the Drupal coding standards.

tangent’s picture

Status: Needs work » Needs review
FileSize
4.61 KB

I've re-rolled the patch with code style fixes.

tangent’s picture

Can someone please give my patch a test run (or a review at least) so we can move this issue forward?

logaritmisk’s picture

Status: Needs review » Reviewed & tested by the community

It does what it is suppose to do, I had no issues.

moritzz’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
4.85 KB

As far as I can tell this patch didn't work on "per node" format settings. I therefore optimized and extended it. Check it out. (Because the exported defaults array is now keyed by config type, node type and role issues mentioned above should be fixed.)

moritzz’s picture

Thanks @nedjo. I posted a patch to features' issue queue that adds your code: See #1156778: Export Filters (Input Formats) With Features for Drupal 6

alberto56’s picture

subscribing

mikebell_’s picture

I've applied and tested the patch from #39 and can confirm it's working as expected.

lpalgarvio’s picture

+1 for this

mikebell_’s picture

After using this patch for a few weeks it always seems to be overridden, not had chance to look into this further.

Crom’s picture

I've used the patch at #39 and experienced:

Settings were correctly exported to the feature as far as I can tell.

admin/settings/filters/defaults - roles present and in correct priority order but defaults not correctly set

This caused the settings page to not to be imported properly as the roles didn't have proper permissions for the different formats.

Hope this helps,
Crom

UPDATE: Also, better formats now appears twice in the exported feature .info file. You can delete it of course but it gets re-exported each time you create a new version

Robert Castelo’s picture

Subscribing.

Elijah Lynn’s picture

Is any of this in 6.x-2.x-dev?

dragonwize’s picture

Issue summary: View changes
Status: Needs review » Closed (won't fix)

6.x is now unsupported.