Taxonomy terms should be able to export file fields

Here's a patch that adds file field export capabability to UID Features. I based my code on the file field export code in the node_export module. LIke the node_export module, it includes options for module configuration so you can specify which vocabularies should export files, as well as export options to specify whether the files should be packaged as "Inline Base64," "Local file export," or "Remote file export, URL."

There is no integration at present between this taxonomy filefield export functionality and the existing file export functionality that is already built into UUID Features. Taxonomy filefield exports should not conflict with simple file exports, but the configuration options I described above will not not apply to simple file exports. Perhaps that could be done in a future patch.

Here's a re-roll of the patch with a change to improve its handling of local file exports.

Oops, still not quite right. Here's another re-roll.

Yikes, still not right. Fingers crossed that this one works.

Just to be clear, the UUID Features module already works with most field types, such as text fields. The issue is that it doesn't currently support exporting file fields, such as images. My patch adds support for exporting file fields.

The patch is working for me in the installation profile I'm building. As for how it works, the functionality is modeled closely after the file field export functionality in the node_export module. It allows for some configuration settings which specify how files are exported. If "Inline Base64" is selected, it attaches the contents of the file as an encoded ASCII string. If "local file export" is selected, it saves a copy of the file at a designated path, e.g., /profiles/myprofile/imagefiles. If "remote file export" is selected, it simply saves the URL of a web address where the file can be retrieved.

There are advantages/disadvantages to each of these export methods. "Inline Base64" works best for smaller file sizes. The "local file export" option is ideal for creating features that are intended to be part of installation profiles, but it's a little tricky if you try to rebuild a feature and the path to the installation profile is not writeable. (I put some code to address that situation by creating a separate path inside the public:// folder in cases where that is an issue.)

The uuid_term_features_file_field_export() function generates file field code that gets added to taxononomy terms through the uuid_term_features_export_render() function. Depending on which configuration option is chosen, uuid_term_features_file_field_export() adds an array element to the filefield export. Suppose, for example, that the $field contains a single file attachment with language undefined. If the module has been configured to "Inline Base64," uuid_term_features_file_field_export() will add an attribute to $field as follows:

$field['und'][0]['uuid_features_file_data'] = $export_data;

If the "local file export" option has been configured, the element added will be:

$field['und'][0]['uuid_features_file_path'] = $export_data;

If the "remote file" option has been configured, the element added will be:

$field['und'][0]['uuid_features_file_url'] = $export_data;

That's pretty much it as far as how this code does the file exports. When a feature with exported taxonomy terms gets rebuilt, the module uses uuid_term_features_file_field_import() to parse these array elements back into actual files, saves them to an appropriate location, and saves the file reference in the field being rebuilt.

brantwynn: How did you configure the module prior to creating your feature? Did you use the "local," "inline Base64," or "remote file export" configuration? I did most of my testing with "local." There is a bit of an issue with "local" in cases where the filepath in which files get stored upon export in a directory that differs from the directory where files get written when you enable or revert the feature. I could write some documentation explaining that issue. The easiest way to export files is via the "inline Base64" option, but that may not work well for larger files.

brantwynn, did you enable the feature on the same Drupal instance where you created the feature, or did you copy the feature onto a separate Drupal instance and then enable it there?

If you enabled the feature on the same Drupal instance where you originally created the feature, I'm not too surprised if you'd still see "overridden" until you revert, but it shouldn't do that if you're enabling the feature on a separate Drupal instance.

brantwynn: Thanks, I will.

brantwynn: I'm attaching a corrected re-roll of the patch for the latest dev release. In reviewing your patch, I noticed an error. Your patch added the line field_features_rebuild($module); to function uuid_term_features_revert() when it should have added that line to function uuid_term_features_rebuild().

Once I fixed that line, the module works as intended in my tests.

brantwynn: Also, it appears to me that the feature which you exported did not include an actual file attachment. I recreated the feature after adding an image to your "brick" taxonomy term and created a second taxonomy tern named "paper" without a file attachment. If you compare your version of the test_term_import module against my version, you'll see what's happening. Your version of the feature simply creates an empty array instead of a full file export.

brantwynn, which modules do you have enabled on the Drupal instance where you're testing this? I think you may have some modules enabled in addition to the ones I'm using which are adding the extra lines and therefore creating the "overridden" state on your instance. In particular, I think you may have the file_entity module enabled. Drupal core does not add an "image_dimensions" property to the file object like the one you're seeing in your overrides, but the File Entity module does:

http://drupalcode.org/project/file_entity.git/blob/ba55cf24b8e582edd8c3e...

The Features module is rather delicate about the way that it determines whether a feature has been "overridden" or not. It basically generates a big text string representing the PHP code necessary to describe the objects exported to that feature. When you create a feature, it exports that text string and sticks it in a function. When you visit the Features admin page, it regenerates the code that it would produce if you were to recreate that feature, and then it compares the regenerated code against the code that was generated when the feature was previously created. If there are any differences, it labels the feature as "overridden" and shows a diff like the one in your screenshot.

This gets delicate because any Drupal module that modifies the properties of a file object (as is the case with the file_entity module) will change the code that Features generates, which in turn will cause Features to see a difference between the Feature that was generated on my Drupal instance (without file_entity enabled) and your Drupal instance (with file_entity enabled). This in turn will cause it to flag the feature as "overridden."

I suspect that if you re-export the test_term_import feature from your Drupal instance and use it in place of the test_term_import feature that was generated on my Drupal instance, the "overridden" status will disappear. Alternately, you can try creating a Drupal instance with the same modules enabled as I'm using, and it will probably not show the "overridden" status. Here's a list of the modules that I have enabled for my testing:

CORE
----
block
color
comment
contact
contextual
dashboard
dblog
field_ui
file
help
image
list
menu
number
options
rdf
shortcut
taxonomy

CONTRIB
-------
admin_menu
entity
features
uuid
uuid_features

If I'm correct and the File Entity module is responsible for the differences you're noticing, the question then is what I should to to make the overridden message go away. One way to do this would be for me to unset the "image_dimensions" property in filefields before export them. I've already done this with a couple of other filefield attributes that were causing "overwritten" diffs, such as the "fid" and "timestamp" properties. If I unset those properties, however, it will prevent those properties from being included in the file that is created on the destination server when the feature is enabled. Any suggestions for how I should handle this?

Yee-haw! Thanks, Jeffrey C. It's great to see this module getting some serious maintenance.