Patch to export taxonomy terms

I definitely like the idea. However, I'm not sure we should automatically include terms whenever a vocabulary is exported; sometimes all you want is the vocabulary itself. With that in mind, here are the rules I'd prefer:

1. When a vocabulary is exported, its terms are _not_ automatically exported; the user can still choose to export them if he/she wishes.
2. When a term is exported, its vocabulary _is_ automatically exported (since you need the vocabulary for the term).

What do you think?

Apart from that, the patch looks good …I haven't taken it for a test drive yet, but the code looks solid; I should be able to try it out shortly.

Thanks for your help with this!
Adam

Hmm …provided that the hook_features_export_options() implementation is working correctly, the features UI should expose a list of taxonomy terms that can be manually selected. However, it does not appear to be doing so.

Been trying to track down the problem this morning in testing; it appears that _exportables_taxonomy_get_terms() isn't working as intended—on a site with several vocabulary terms, it's not returning anything.

I'll look into this further, but I thought I'd mention my findings so far.

Thanks!
Adam

OK, the attached patch resolves the problems I found; still need to test out whether the exported feature works correctly, but I think we're very close.

For info:
There appears to be a problem with the helper implementations of hook_enable(), i.e. __enable(), appearing in both the ...features.taxonomy_term.inc and ...features.taxonomy_vocabulary.inc files.

Since both are included into ...features.inc you get a name clash.

Steven

Is the #5 patch in current dev version of exportables? Thanks in advance.

I answered my question #8 by myself. The patch is not in dev version of exportables.
I tried the patch and included vocabulary and 2 terms of that vocabulary into my feature.

Installing my feature on a fresh site created the vocabulary successfully, but to create both terms I had to visit admin/build/exportables/sync where I checked taxonomy_term and clicked the "Resync" button.

For my use case it isn't possible to check all terms individually when creating a feature.
Does someone know if there is a working taxonomy integration into Features module out there, which can manage a vocabulary and all its terms by one click when composing the feature?
Maybe I start my own patch to solve this issue (then I will use only one features.*.inc file for both - vocabulary and terms - and maybe the reason of my manually "Resync" for the terms is because of "There appears to be a problem with the helper implementations of hook_enable(), i.e. __enable(), appearing in both the ...features.taxonomy_term.inc and ...features.taxonomy_vocabulary.inc files." ?)

If #7 can be solved with one of the suggested options there could be 3 alternatives for taxonomy integration into features module (and maybe 3 different features.*.inc files):
- taxonomy_vocabulary (like in current dev version)
- taxonomy_term (added in patch #5)
- taxonomy_vocabulary_with_all_terms (must be developed)

@dsnopek:
I understand the problem with hook_enable and hook_disable, but maybe we can find a better solution than your suggested 'manual way' (in #10).

Are there good reasons, that you split vocabularies and terms in 2 feature.*.inc files?
I think that we can get same behaviour with only one feature.*.inc file for both and an additional array key 'vocabulary' or 'term' inside the definition.

Then there is only one hook_enable and hook_disable implementation for all items which are covered by exportables module.
This hook implementation will always call both sync commands (in the right order):

  exportables_sync('taxonomy_vocabulary', 'mymodule');
  exportables_sync('taxonomy_term', 'mymodule');

I don't know if exportables_sync checks if there are array elements to synchronize. But also if it doesn't check it yet, it would be easy to implement.

I think that putting vocabularies and terms in one file is a big step towards your '$pipe' solution.

What do you think about it?
I offer some support in solving this problem, because I don't want to create my own solution, when there are already good approaches in the community (and I think that Exportables module is the most promising approach for a clean Features integration for taxonomy at the moment).

Greets,
Martin

@dsnopek:

Thank you for your reply.

I understand you and I did some brainstorming with me :-) if there could be another solution.
Here is my suggestion:

1. We try to auto-generate a simple 'sub-module' CUSTOMFEATURENAME_exportables containing of a .info file and a .module or .install file where we place CUSTOMFEATURENAME_exportables_enable and ..._disable hook implementations containing only your suggested fundtions exportables_sync_module('mymodule') respectively exportables_unsync_module('mymodule') (see #12).
This sub-module will be placed inside the exported feature directory beside all the other .inc files.

2. We add a dependency for this sub-module into our (main) feature.

The sub-module prevents us from 'blocking' a custom hook_enable or hook_disable implementation in the (main) feature. And the sub-module will be installed (and enabled) on the fly, when the (main) feature will be activated (because of the module dependency).

What do you think about it?

subscribing.

@M_Z Creative solution but I don't think that entirely solves the problem and it introduces quite a bit of overhead, imo. The problem still exists what if there are other exportables that need to play around in hook_enable(). The requirement of an extensible system to collection actions is still there.

It's not very different than just having a custom exportables_enable (that is then called from the real hook_enable)

Unfortunately I don't have a great solution suggestion.

I'd also like to point out that this approach doesn't seem to support anything but a base case of adding a vocabulary and terms. For example, if I want to have a feature with a view that filters by a term id.

Views stores it's filters like this

 $handler->override_option('filters', array(
  'tid' => array(
    'operator' => 'or',
    'value' => array(
      '0' => '3282',
    ),
    'group' => '0',
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'type' => 'textfield',
    'limit' => TRUE,
    'vid' => '26',
    'id' => 'tid',
    'table' => 'term_node',
    'field' => 'tid',
    'hierarchy' => 0,
    'relationship' => 'none',
    'reduce_duplicates' => 0,
  ),
));

You'll notice hard term IDs and vocabulary IDs in there.

I suppose the view default function could be changed so that we use the _exportables_fix_.. functions to turn the machine name into a tid. This would require either manual editing or some sort of text replacement script. Neither of these options are very good, in my opinion. Open for suggestions/placation.

For this immediate project we are reserving some term and vocabulary IDs and just doing it that way.

Setting to needs work

Subscribe, reminding myself to update with what I did when time.

got one of the originally patch somewhat working eventually, but not in patches yet.

Attached is a patch 2 with some modifications based on modifications done against the first patch. Haven't tested this patch, and may have missed some.

Some of the issues was null being returned when empty should have, and upsetting of term tid before the term save completely owned the update, though perhaps what needs to be done instead is a separate update function. hmm.

On handling of other exported items, other than by making custom filters or altering the actual output of exported views to include calls to get term/vocabulary information, I don't see it as being possible without interaction on the feature creator to add in calls to get the desired machine name. Hmm..

Subschribing, greetings, Martijn

First is my current working taxonomy term only related patch, adds parent term support.

In the end, I personally don't mind writting my own hook_enables and would prefer that it doesn't do it for me as I end up moving em to the install folder anyway, so I suspect documentation would be acceptable at first, but getting the patch in for some basic support would be really really grand. However, in some respect the enable/disable issue is an overall exportable issue, not terms themselves?

Note though, I'm mostly using exportables for the hooks, and not exporting via features. :>

Actually, perhaps logic can be added that if vocabulary machine name doesn't exist, try and find vocabulary and synch it, but seems messy.

As for views, I use content_taxonomy fields so that views isn't generally an issue, content taxonomy is. I use #693024: Add alter hooks for the "faux" exportables which gives me hook_content_default_fields_alter and update my fields vids to the new one :). hook_views_default_views_alter is already in views, which allows me to do something similar also, so my features work whatever the vocabulary ids are.

/**
 * Implementation of hook_content_default_fields_alter().
 */
function mymodule_content_default_fields_alter(&$fields, $module) {
  _exportables_fix_content_taxonomy($fields,
    array(
      'field_some_field' => 'vocabulary_machine_name',
    )
  );
}

function _exportables_fix_content_taxonomy(&$fields, $replacements) {
  foreach ($replacements as $field => $machine) {
    $replacements[$field] =  exportables_machine_load_id('taxonomy_vocabulary', $machine);
    if (empty($replacements[$field])) {
      unset($replacements[$field]);
    }
  }
  foreach($fields as $key => $field) {
    if (!empty($field['field_name']) && !empty($replacements[$field['field_name']])) {
      $fields[$key]['vid'] = $replacements[$field['field_name']] ;
    }
  }
}
function mymodule_views_default_views_alter(&$views) {
  $views['viewname']->display['default']->display_options['filters']['tid']['vid'] = exportables_machine_load_id('taxonomy_vocabulary', 'vocabulary_machine_name');
}

Opened topic specific to enable/disabling exportables #834888: Enableing modules with exportable hooks/ drupal_write_record, marking this needs review.

subscribe

Since exportabeles 1.x conflicts with stable features, and exportables 2.x is quite different... changing status.

@hefox or @dagmar, is there any point to updating this to 2.x since Features now supports CTools Export API and the module maintainer says "Taxonomy export, and all the UI to sync exportables is not yet in this release, and probably will be delegated in other module." ?

Would that better be handled here: http://drupal.org/node/755986 ?

Likely, but figured module maintainer should likely close it in this case.