Restore uuid_features compatibility with uuid

Subscribing

It appears that UUID_Features 7.x-1.0-alpha1 is completely incompatible with UUID 7.x-1.0-alpha2, all system APIs have been replaced with a basic entities system, rather than separate sub-modules for nodes & taxonomy.

I've just started to get the uuid taxonomy part back working.
The current patch supports simple fields, including term references. Other references would be possible too, as long as they are supported by the UUID module. Furthermore I've removed the uuid_vocabulary implementation, since Features already comes with a vocabulary export, which perfectly works.
The new UUID module has a great API and I'm pretty sure there are some possibilities to make the UUID Features module more generic as well, but I don't want to completely re-write it.
The current patch is based on another patch for the UUID module (support for term parents), which I'm going to link here afterwards.

see required patch for UUID #1265554: Add support for taxonomy term parents

Tagging.

subscribing

Subscribing

Agree with falling back on Features vocabulary import, but unfortunately it introduces a race condition. #1004478: Node component should revert before exported menu links led to UUID Features acquiring a module weight of -50, which means that with the above patch applied, we try to rebuild taxonomy terms before Features rebuilds vocabularies. Result: UUID Features can end up trying to add terms to nonexistant vocabularies.

This is pretty critical, as it reduces the Features UI to a mess of PHP error messages. Of course a workaround is to manually change the module weight in the system table until the vocabulary is imported.

Thanks for pointing that out. I just hit that bug. Using hook_module_implements_alter() won't work either, as we just have one real hook (hook_features_api) and can't get control over uuid_term_features_rebuild(). On my demo site I adapted the patch to not insert terms with a non-existing vocabulary and reverted the feature afterwards, which worked. Anyway, that's not really a solution and I have to think about a better way.
Will post an update of the patch soon.

Here my updated version. Besides a few small fixes and preventing that a term without a voc every gets saved, I manually invoked the taxonomy vocabulary hook so that these vocabularies are imported first.
This works for me, but doesn't solve all dependency issues. For example, you might have term reference fields on terms, which would need to imported straight after the vocabulary is saved. In this case you would need to revert the components in the correct order via the Features UI. I'm also wondering why the import doesn't happen in the way it is ordered in the .info file, which would solve the dependency issues as well.

Hi,

I attached my uuid_feature module changed. Works with UUID module 7.x-1.0-alpha2. I test only nodes, vocabularies and terms.

Here's a simple patch which only gets rid of the calls to uuid_taxonomy_term_find() and uuid_node_find().

This doesn't work at all for me - the items export but do not import and do not show as overridden when things change. (neither of the patches seem to work in this thread.)

Ok, i made a (very) slight change to the patch from 10 so that the term_hierarchy will get updated correctly and the terms will start appearing in the list of terms for the taxonomy.

I simply removed the line where parent was set to an array as this was causing the issue - no parent should be 0 I believe, or an array of parent terms - I think at some point this will need to be added back in so hierarchical taxonomies can be exported, but ... this is better than nothing.

I didn't know that the Deploy module integrates with the Features module. I'll try that later on and if it works, I agree :)

It's actually the other way around for now. UUID integrates with Features if Deploy is around and uses Deploy functions to render the export.

So far I've found that the easiest way to add stuff to a deployment plan is to create a Rules action set for adding an entity to a plan and build a VBO to use that action for a list of those entities. Please tell me if there's an easier/better way, but this method seems to work fine for me. @mh86: hope this helps.

I'm not seeing how this solves easily exporting a few nodes. It also doesn't appear to be easy to export taxonomy terms that already exist. From what I can tell, i would need to go through and update all of them after creating a rule to add updated terms to a deploy. There doesn't appear to be a good way to add a select set of nodes and terms to a deploy and finally, deploy doesn't appear to be 'done' for d7.

In my opinion, this really just highlights the need for UUID_features. The deploy module adds in 2-3 more steps for simply adding something to a feature, you lose the granularity previously available and you now have 1 (or 2 if you use rules) new major dependencies.

I believe the best action here is to simply finish fixing uuid_features. We can take the dependency detection logic from deploy and integrate it if that is the main issue that people are having.

I agree that this is perhaps a good way to set up a bulk content deploy, however, it doesn't replace UUID_features. The way I want to use UUID_Features is :
* Featurize pages that need to exist, like about and the homepage
* Featurize webforms
* Featurize taxonomy terms from vocabularies that don't change.

The use of deploy makes this a multi-hour setup task, whereas uuid features made it a couple minutes.

I've combined the taxonomy fix with the fixes (which fixed nodes for the most part) from #12. This patch fixes both terms and nodes for me and allows them to be properly exported and imported.

I've included a old-versions-of-drush-friendly version also for profiles (the no-prefix one).

I would recommend using uuid version 1.0-alpha2 to make all this work as the new version causes some minor issues with features if deploy isn't there (i added a patch dixon_) and doesn't seem to be assigning UUIDs to new entities on my setup. Unsure what the issue there is.

The patch in #16 does work to export a webform node (nid=30).

However .. when I try to deploy this on staging my features appears overridden (nid's are different on both sites, it's 30 on staging). Reverting through "drush fr .." doesn't change a thing. When I tried reverting through the features ui, I get the following error:

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '30-1' for key 'PRIMARY': INSERT INTO {webform_emails} (nid, eid, email, subject, from_name, from_address, template, excluded_components, html, attachments) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => 30 [:db_insert_placeholder_1] => 1 [:db_insert_placeholder_2] => 2 [:db_insert_placeholder_3] => default [:db_insert_placeholder_4] => default [:db_insert_placeholder_5] => default [:db_insert_placeholder_6] => Beste, Wij hebben uw vraag goed ontvangen: %email_values Met vriendelijke groeten, CVIA [:db_insert_placeholder_7] => 1,2 [:db_insert_placeholder_8] => 0 [:db_insert_placeholder_9] => 0 ) in drupal_write_record() (line 6884 of /var/www/statik/sites/cvia/htdocs/includes/common.inc).

Reading "Duplicate entry '30-1'" makes me think something gots mixed up with the changing nids. I don't understand why the nid's are being exported anyway. Isn't it the whole point with uuid to get rid of the nids at least concerning deployment? Am I missing something?

I was able to get the deploy with UUID to export content working...seems like it is not really usable (deploy that is) in d7 since it doesn't display any places to select content like in d6. I was (after tweaking code) to get the views aggregator working and export content using features. Definitely looks like a much more interesting, agile, and in general proper approach.

Should we understand that taxonomy export is doable in the current state of deploy (7.x-2.x) and UUID (7.x-1.x) ?
I don't see UUID depending on deploy, I don't see new features from deploy activation... or did I overlooked something ?

The whole process is not entirely intuitive (makes sense afterwards). You have to make a deployment plan which will contain the content you want export. The content from the deployment plan will then show up in features for exporting. Deployment 7.x seems to be fairly unpolished in selecting content in comparison to 6.x. I managed to get 7.x working after messing with the views plugin (which allows you to define a view for selecting content). If this is to be viable then we need a deploy 7.x release.

Note: my terms are probably not correct.

Attached patch is #19 updated (I think) to apply to latest code in git.

it applies to lastest Git and appears to works quite well ! (but I didn't test deeply).
uuid_features_features_api provides uuid_node and uuid_term which are valid and
and (in the case of terms) correctly exported through the UI.

I wanted to find why these don't appear in Drush... it happened to be a typo (see the attached patch)
Anyway the uuid as a feature name is not that intuitive ;)
As another question, why did you removed the vocabulary (which will be quite handy)
(I guessed that it was to reintroduce it later (#966510: Add support for related terms and synonyms and #965450: Add component that exports vocabulary with all its terms) but I wasn't sure)

About Deploy (replying about #1362862: Add Taxomomies to plan), I understood that #887282: Overlap with / duplication of Deploy module stated that Deploy
won't be mandatory for core functionality.

I tried the latest dev code with the patch from #27 and get the following errors:

Notice: Undefined index: f30648b6-5ecf-77f4-89da-1e97c47201c3 in uuid_node_features_rebuild() (line 133 of /var/www/multd7_install/profiles/multilingual_book_demo/modules/contrib/uuid_features/includes/uuid_node.features.inc).

Note that I'm trying to use the feature module in an installation profile so I'm not sure if that is complicating the matter. The feature module has taxonomy terms that have been saved and have the ids like the one noted in the error.

Kristen

I rerolled #27 with the tweak from #28. I didn't have the problem listed in #29.

That last patch had an unrelated hunk. Sorry!

Forgot to remove the file[] entry from the .info file.

This patch (#33) worked for me when I also applied http://drupal.org/node/965450#comment-5837286. I applied this patch after that one.

I did the same thing as audtroutt (#34) and it worked for me as well.

Can confirm that the patch worked as expected!

I can also confirm that the patch in #33 and the patch from #34 (from the link) work as expected.

However, I am getting the same Undefined index: MY-NODE-UUID in uuid_node_features_rebuild() that @Kristen Pol is getting in #29 when I try to import content into a fresh install... is anyone else having the same problem?

I took a look at line 133 of uuid_node.features.inc and it seems like should probably be changed to $nid = isset($nids[$node->uuid]) ? $nids[$node->uuid] : '';, but I'm not sure. I haven't looked through much of the uuid or uuid_features code, so I could be way off...

Confirming comment #37:

I changed

      // Find the matching UUID, with a fresh cache.
      $nids = entity_get_id_by_uuid('node', array($node->uuid));
      $nid = $nids[$node->uuid];
      if(!empty($nid)) {
          $existing = node_load($nid, NULL, TRUE);
          if (!empty($existing)) {
            $node->nid = $existing->nid;
            $node->vid = $existing->vid;
          }
      }

into

      // Find the matching UUID, with a fresh cache.
      $nids = entity_get_id_by_uuid('node', array($node->uuid));
      if (isset($nids[$node->uuid])) {
          $nid = $nids[$node->uuid];
          $existing = node_load($nid, NULL, TRUE);
          if (!empty($existing)) {
            $node->nid = $existing->nid;
            $node->vid = $existing->vid;
          }
      }

But... (maybe not related to this issue):

I've created a page and linked it to a menu item. I made a feature and exported the created node (with uuid_features) and exported also the linked menu-item (with the uuid menu links from the uuid module). After enabling the feature, the status of the feature is overriden. The overriden uuid_node and uuid_menu_links arrays are empty. When I revert the feature, the content and menu item are generated.

Does anybody know why I need to revert ?

When I create a feature with only a page in it, everything went fine.
When I create a feature with only a menu in it, also everything went fine.

This patch solves the problem described in comment #37.

Confirmed that #33 is the correct fix and resolves the issue.

I'm not a maintainer of course, but my two cents is that discussions about whether to deprecate the module are out of scope in this issue (and that this module is still the solution for including entities in features). Therefore, I'd say this fix is worth committing.

Thanks! http://drupalcode.org/project/uuid_features.git/commit/924559b

A guide about what @dixon_ talks about in #15 is at http://ao2.it/77

Updated from 7.x-1.0-alpha1 to 7.x-1.x-dev and all is well.

Could we get an alpha2 release so folks can pin both uuid and uuid_features to compatible versions?

It's still underway. Trying to fix all the issues and bugs before we can make a release.

Closing as outdated because drupal 6 is not supported anymore.