Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.As a follow up to my patch port here: http://drupal.org/node/1611848 i noticed that in some cases I was still having issues where features were considered "Overriden" after loading them on a different server.
Doing a diff of a feature generated on the "overridden" server versus on my original server reveals that revision_uid and various file field timestamp fields were different. For revision_uid, it obviously makes sense that they would differ, but if I've enabled "Reset value on import' with revision author, then revision_uid should be somehow ignored when doing the feature detection.
Similarly, as part of the patch port - even though created/updated timestamps are cleaned up, it seems like all general timestamps should be cleaned up - these are highly volatile data fields, after all.
I would like to help out more directly, but I'm honestly brand-spanking-new to the Features API. If someone could at least point to me the feasibility of this or where to start looking, I'd be happy to spend some bandwidth producing a patch.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | node_export-1826266.patch | 1.15 KB | tobiasb |
Comments
Comment #1
thelee CreditAttribution: thelee commentedAlright, here's a patch with some fixes. It's not complete; there are still some features that still show as Overridden on our servers, but at this point I think it's a fundamental PHP problem or Drupal problem - whatever it is, it's outside the scope of node_export.
Patch should be self-explanatory. Long story short are these bullet points
- consistent representation by sorting the keys of the node object (we had cases where fields on one server came out in a different order than another)
- handling for revision_uid better (now follows behavior of node->uid and also checks for error case where revision_uid is 0)
- checks for invalid seralization in node->data (NULL mismatch with "b:0;" (boolean FALSE which casts to NULL but is not === to NULL)
increases the accuracy of the "overridden" label on our node_export features to like 70%, way better than the 20% or so before. Also see patch port in first comment.
Comment #2
thelee CreditAttribution: thelee commentedComment #3
thelee CreditAttribution: thelee commentedComment #4
ergophobe CreditAttribution: ergophobe commentedThis plus the patch in #1611848: Do a better job cleaning nodes when exporting via features. Helps avoid features thinking a node is constantly 'Overridden'. fixes this for me. Thanks thelee!
It would be great to see these two patches committed. The constant "overridden" has been bugging me for a while.
Comment #5
tobiasb* no changes, just converted the file to utf8 and unix ln
Comment #7
danielb CreditAttribution: danielb commented