The DEV line is now throwing a couple of exceptions when publishing and unplublishing content types with emfields. I believe it's a result of the work done at https://drupal.org/node/1901272.

I believe the problem is caused by the fact that emfield fields are of type file but they don't have any file associated with them. Perhaps it's an issue with emfield but this used to work fine before the change mentioned above and works with current released version of revisioning.

I will submit a patch shortly that I think will resolve this issue.

Comments

pgillis’s picture

Status: Active » Needs review
StatusFileSize
new531 bytes
rdeboer’s picture

Assigned: Unassigned » rdeboer
Status: Needs review » Fixed

Patch applied with attribution. Thanks Pete!
Rik

fbrooks’s picture

Status: Fixed » Active
StatusFileSize
new1.22 KB

There is an issue with using this patch. While using it avoids the exception, it make file types that use the emfield widget subject to the bug reported in https://drupal.org/node/1901272.

The root cause of the exception is the sparsely populated $node_revision->original object set and subsequently passed to hook_node_update instances in _revisioning_publish_revision. When this is eventually passed to the entity_extract_ids through the call to field_get_items in revisioning_node_update, the exception is thrown. It seems to me from reading the API for hook_node_update that there is the generally accepted expectation that if $node->original is set that it contains an object reflecting the state of the object before it was updated.

I am submitting a patch for consideration that addresses the issue by setting $node_revision->original to a full clone of the node revision with status set to false.

Thanks

Frank

rdeboer’s picture

Thanks for the patch Frank!
Hope to review and apply soon.
Rik

fbrooks’s picture

Attached is an updated proposed patch that accounts for the exception on unpublish as well.

rdeboer’s picture

Status: Active » Patch (to be ported)
rdeboer’s picture

Status: Patch (to be ported) » Fixed

Patch applied with attribution.
Thanks Frank.
Rik

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.