Node timestamps, options overridden and cause uuuid_node components to appear modified

We are having the same problem with timestamps. Similarly, what if the actual content (title, body, etc) is modified on the site by an end user? We wouldn't necessarily want those changes to be reverted during an update of the site.

Essentially this means you can't mix in content with other components when creating a feature. Further I think it means we should create a feature to get the default content in place. Then unset it so a person can revert other features on the site with some form of automation. Still investigating what the best process is.

I'm trying to reproduce this problem, but haven't been able to. I create & enable a Feature that contains a number a nodes in it. I then visit my Features admin page ... nothing appears as overridden. Am I missing a step?

UPDATE: I am able to duplicate the problem. Export a feature with nodes on one system, then enable this feature on another system.

'changed', 'last_comment_timestamp' and 'revision_timestamp' do indeed cause the feature to be reported as overridden.

Rather than updating the database entries, couldn't we just simply exclude these timestamps from the export? The attached diff seems to work reasonably well. Do you see any problems with doing this?

I've been using uuid_features on a daily basis. The patch in #13 is working well for us, but I now realize that there are other node properties that should be ignored. For example, the node_load() function will join the users table and insert the 'data' field from it into the node object. A user's data field can contain things like form_build_id = form-b18190f6a7716334a659c03c950e1c34. In other words, stuff that will almost always cause an override to be detected when managing a feature across multiple systems.

Rather than extend my patch in #13 to simply exclude the "data" property as well, I'm wondering if we should take another approach... It's impossible to anticipate everything that can end up in the node object, as any module can add to it. Most things probably make sense in an export, but there will always be exceptions (like 'changed', 'data', etc). Perhaps we should expose a settings page that allows an administrator to modify the list of property exclusions, which will be stored in a drupal variable ('uuid_features_ignored_node_properties'). The default exclusions can include 'changed', 'last_comment_timestamp', 'revision_timestamp', 'data'. Theoretically, if someone changed the exclusions from the default, they could use strongarm to ensure that it is exported into their feature along with their uuid_node content.

I'd be happy to work on this if others agree it is the right way to go. WDYT?

Not sure why I didn't see this before, but uuid_features.module allows other modules to alter the export. This provides a great way for you to exclude timestamps and any other data that might be specific to the nodes in your feature.

So no patch required, just put something like the following in your feature module (or any other module for that matter):

/**
 * Implements hook_uuid_node_features_export_render_alter()
 */
function mymodule_uuid_node_features_export_render_alter(&$export, $node, $module) {
  // don't allow uuid_features to export node properties that can change on deployment
  unset($export->changed);
  unset($export->last_comment_timestamp);
  unset($export->revision_timestamp);
  unset($export->data);
  unset($export->old_status);
  unset($export->date);
  // webform stores nid
  if(isset($export->webform)) {
    unset($export->webform['nid']);
    foreach($export->webform['components'] as $key => $wf) {
      unset($export->webform['components'][$key]['nid']);
    }
  }
}

Fine by me if this issue is closed (although ezra-g's original patch should be considered)...

@ryan_courtnage: The OP's issue is that the nodes created by uuid_features don't inherit the timestamps from the nodes exported by uuid_features. Removing the timestamps from the export indeed fixes the issue with nodes incorrectly being marked "Overridden" in the Features control panel, but it doesn't solve the root problem of actually setting nodes' timestamps when recreating them.

@ezra-g: Your patch in #10 works for me so far, except that I think this line:

+    'changed' => array('table' => 'node', 'column' => 'created'),

should maybe be this:

+    'changed' => array('table' => 'node', 'column' => 'changed'),

(so that it updates the "changed" column later on, not the "created" column).

I've attached a revised patch. Can we get this committed?

Awesome. Thanks, @ezra-g!

The same issue also exists for the 7.x version but the same patch with slight modifications seems to apply to drupal 7 as well.