Comments

mh86’s picture

Subscribing

DamienMcKenna’s picture

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.

mh86’s picture

Status:Needs review» Needs work
StatusFileSize
new11.17 KB

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.

mh86’s picture

iMiksu’s picture

ao2’s picture

subscribing

bforchhammer’s picture

Subscribing

Matthew Davidson’s picture

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.

mh86’s picture

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.

mh86’s picture

StatusFileSize
new11.59 KB

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.

toleillo’s picture

StatusFileSize
new12.32 KB

Hi,

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

wulff’s picture

Status:Needs work» Reviewed & tested by the community
StatusFileSize
new4.09 KB

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

jec006’s picture

Status:Reviewed & tested by the community» Needs work

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.)

jec006’s picture

Status:Needs work» Needs review
StatusFileSize
new11.56 KB

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.

dixon_’s picture

Title:Big API changes are coming for UUID module» Deprecate uuid_features for Drupal 7
Assigned:Unassigned» dixon_

I've taken a very long and deep look on how to integrate UUID Features with the new API provided by the UUID module. And here's a bit of a drastic conclusion...

Please throw tomatoes on me if you think I'm wrong ;)

Deprecate UUID Features

It turns out that exporting UUID entities with Features only took a 150 line patch to the UUID module it self. So I think that we now should deprecate the D7 version UUID Features. UUID Features has been a great servant, but it's not needed anymore.

The new UUID export functionality depends on Deploy for generating the export. Basically what you need to do, is to create a fetch-only deployment plan of what content you want to export. After that, you'll find it in Features. "NO!? Not a dependency on Deploy for this" -- you think. But let me explain why this is a good thing... :)

Reason 1

uuid_features and modules like defaultcontent all do a good job exporting individual pieces of content. But none of them have a good framework for recursively detecting dependencies. Example: node A has a reference to node B which is tagged with term C. The framework needs to figure out in which order to export everything. The order should be: term C, node B, node A.

Reason 2

Once a piece of content is exported with all its dependencies in the right order all its references can't be made with local IDs. All references needs to be made with UUIDs.

Reason 3

Neither uuid_features or defaultcontent scales well with a decent amount of content. You have to manually select what nodes to export from the Features UI and there's no other way to intelligently query what content to export in a comfortable way.

Summary

Deploy solves problem 1 by having a really good dependency detection framework for deploying (or in our case exporting) content in the right order. It also solves problem 3 by providing a comfortable way of querying what content to export. And UUID it self now solves problem 2 by making all references by their UUIDs.

Most of the bits and pieces are in place already. What's missing is some documentation, blog posts and screencasts on how to do this. But I'm currently working on a payed project needing this. So you'll see it coming in the next few weeks. Meanwhile, you can try figuring it out with latest dev releases of both UUID and Deploy.

mh86’s picture

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 :)

zhangtaihao’s picture

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.

jec006’s picture

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.

jec006’s picture

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.

zilverdistel’s picture

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?

zilverdistel’s picture

Status:Needs review» Needs work
dixon_’s picture

Neither UUID or Deploy aren't in stable state yet. Especially not Deploy. But we are heading in the right direction for something very good. We also have some very good UI and usability improvements coming to Deploy soon. So that will make it a lot easier to deal with plans for exporting content etc.

dixon_’s picture

@jec006 It will be much easier to deal with Deployment plans soon. Deploy is in dev state still and have had no or extremely rough UI up until now.

boombatower’s picture

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.

drzraf’s picture

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 ?

boombatower’s picture

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.

mrfelton’s picture

Status:Needs work» Needs review
StatusFileSize
new12.07 KB

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

drzraf’s picture

StatusFileSize
new1.28 KB

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.

Kristen Pol’s picture

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

tim.plunkett’s picture

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

tim.plunkett’s picture

Title:Deprecate uuid_features for Drupal 7» Restore uuid_features compatibility with uuid
tim.plunkett’s picture

StatusFileSize
new12.1 KB

That last patch had an unrelated hunk. Sorry!

tim.plunkett’s picture

StatusFileSize
new12.43 KB

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

audtroutt’s picture

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

lee20’s picture

Status:Needs review» Reviewed & tested by the community

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

Hydra’s picture

Can confirm that the patch worked as expected!

drclaw’s picture

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...

Cauliflower’s picture

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.

Cauliflower’s picture

StatusFileSize
new12.9 KB

This patch solves the problem described in comment #37.

xjm’s picture

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.

RobLoach’s picture

Version:7.x-1.x-dev» 6.x-1.x-dev
Priority:Critical» Major
Status:Reviewed & tested by the community» Patch (to be ported)
ao2’s picture

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

capellic’s picture

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

lotyrin’s picture

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

Jeffrey C.’s picture

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

dixon_’s picture

Assigned:dixon_» Unassigned
dixon_’s picture

Issue summary:View changes

updated link