Nodes should be able to export file fields

I go with the latter. It's definitely something I would like to see in UUID Features.

Hi brantwynn. This looks like an interesting direction to go in. I'll test it when I get a chance.

FYI, I recently submitted a patch recently to the node_export module to make it do a better job of handling node export/imports involving entity references:

http://drupal.org/node/1896384

The issue is that entity references tend to break if the export contains multiple nodes whose node IDs are different upon import. For example, suppose you export the following nodes, which pertain to organizations and software applications and use entity references to specify which applications are being used by each organization, and vice versa.

The entity references indicate that Drupal is being used by Acquia, and Wordpress is being used by the Human Society. Now let's supposed that after exporting these nodes, we import them into a Drupal website where there is already an "application" node with nid 1 for Joomla, and an "organization" with nid 2 for the Red Cross. Since nids 1 and 2 already exist, the exported nodes will be renumbered upon import, beginning with nid 3, so you will get the following:

After the import, therefore, the "Drupal" and "Wordpress" nodes will each have entity references back to themselves, while the "Acquia" and "Humane Society" nodes will now have entity references back to "Joomla" and the "Red Cross," respectively, which is wrong. In order to correct this, the node import needs to correct the entity references so they look like this instead:

My patch to the node_export module gets this working correctly for entity references, but it doesn't handle references created by the references module, which is different:

http://drupal.org/project/entityreference
http://drupal.org/project/references

If the UUID Features module is going to serve as a full alternative to node_export, it is going to have to handle entity references like these, and currently I don't think that functionality exists. UUID Features currently includes soe code that references the "nodereference" module, but no such module exists in Drupal 7. (There was a noderereference module included with CCK in Drupal 6, but in Drupal 7 the References and Entity Reference modules have replaced it.)

Anyway, these considerations don't bear directly on the patch you just made to add file handling, but they do highlight some of the work that nees to be done to make UUID Features function as a real practical alternative to the Node Export module.

Yes, I'll do that, thanks.

@brantwynn: I'd like to do some testing on this, but I'm really slammed with client work right now. I'll see if I can find some time for testing it this weekend.

@brantwynn: Also, I'd just like to comment on your statement in the original ticket that "either this module steps aside to node_export or it becomes a more general solution. If it is to do the latter, it must be able to version and deploy nodes along with their file attachments must be able to version and deploy nodes along with their file attachments."

I agree with Jeffrey C. that it should aspire to do the latter. However, I think the true ambition of this module should be to "version and deploy fieldable entities along with their relationships to other Drupal content including files, taxonomy terms and relationships to other entities." That's a more ambitious goal than merely exporting nodes, which would have been adequate for Drupal 6 but not for Drupal 7 and beyond. I don't think that affects the scope of this particular ticket, but it may affect some decisions about how to architect the code for this module.

Hello guys,

Does the patch in #2 work?

Got this when enabling a feature of about 60 nodes with text and image file fields. After reverting, if the node had an image field none of the date was imported.

Warning: Invalid argument supplied for foreach() in uuid_features_file_field_import() (line 301 of /var/www/vhosts/staging/drupal7/sites/all/modules/contrib/uuid_features/uuid_features.module).

php 5.3.x, postgresql 9.x, drupal 7.20

UPDATE: Disregard my post here - I've gone through many trial & error's with dev and non-dev modules and ended up using "Node Export" via drush to migrate my content (deadlines!). I'm not sure I can reproduce my error again nor do I remember the config that produced this error.

Added update to my previous post. It may just be a wild goose chase or not relevant - I was going through many different configs in a hurry. Thanks for your attention, however.

I tried creating my own feature (attached) and am getting errors when I try to enable it. The error messages are as follows:

Notice: Trying to get property of non-object in file_field_presave() (line 220 of /Users/sheldonrampton/Sites/drupal7/modules/file/file.field.inc).
Notice: Undefined property: stdClass::$uri in file_save() (line 570 of /Users/sheldonrampton/Sites/drupal7/includes/file.inc).
Notice: Trying to get property of non-object in file_field_presave() (line 220 of /Users/sheldonrampton/Sites/drupal7/modules/file/file.field.inc).
Notice: Undefined property: stdClass::$uri in file_save() (line 570 of /Users/sheldonrampton/Sites/drupal7/includes/file.inc).
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 'uri': INSERT INTO {file_managed} (filesize, status, timestamp, uuid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array ( [:db_insert_placeholder_0] => 0 [:db_insert_placeholder_1] => 1 [:db_insert_placeholder_2] => 1362349647 [:db_insert_placeholder_3] => fdc1f00b-4c0a-3c24-6158-9fbcca3e098c ) in drupal_write_record() (line 7120 of /Users/sheldonrampton/Sites/drupal7/includes/common.inc).

Oops, disregard my previous comment. I forgot to apply the patch before doing my testing. Duh.

Hm, I've reviewed this further, and it is working, sort of. I'm attaching an updated copy of the feature I created, which is now working, as is the feature that brantwynn uploaded previously. However, there's a catch. I still was getting getting error messages like the ones I listed above in #17 until I went to admin/config/content/uuid_features and saved the configuration to specify that files should be exported for nodes of my Article content type and taxonomy terms for my Navigation vocabulary.

If I uncheck all of the the CONTENT types at admin/config/content/uuid_features, I get the error messages above. If I uncheck all of the taxonomies, I don't get the error message.

That's as far as I've gotten with tracing the cause of this bug. It appears to me that the module is still trying to export some information about file attachments when nodes are exported, even if the content type of those nodes has been marked to omit file uploads for those content types, and this is what is causing the error message.

Here's a new patch that fixes the bug I noticed. I also removed the lines of code that were exporting configuration settings as part of the feature using variable_set(). This was creating a buggy situation in which an enabled feature would override and change those configuration settings even after I tried changing them via the configuration page. Strongarm does a better job of exporting and reimporting Drupal variables, so people should use that instead.

This raises somewhat the question of whether we should have configuration settings that give people the option of _not_ exporting file fields with certain taxonomies or content types. I think I could argue that those configuration settings are unnecessary and should be removed entirely, but it is also possible that someone will want to have the option of not exporting file fields with their features.

We could just change the wording and logic slightly so that instead of people checking boxes to INCLUDE file field support for specific content types and taxonomies, administrators check boxes to EXCLUDE certain content types and taxonomies.

I tried changing the wording and logic as I suggested, but you're right that it seems more confusing that way. I think you're right that this is ready to be committed, and we can chase the usability issue in a followup.

Alrighty. I'll commit it when I get to use my computer.

Committed! Thanks! :).