Reset Workbench Moderation state

I am encountering the same issue as mentioned with similar messages

Warning: Creating default object from empty value in workbench_moderation_store() (line 1785 of /sites/all/modules/contrib/workbench_moderation/workbench_moderation.module).

EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7844 of /includes/common.inc).

As ladybug_3777 mentioned the issue was reported to workbench_moderation here #2331169 but the issue stems from node_clone functionality when assigning properties to cloned nodes. Assuming other modules are also affected. Drupal V7.38, Node Clone V7.x-1.0-rc2

(excuse the line number differences in workbench_moderation module as some custom code was in the mix, the custom code is no where near this functionality)

Hello,

I stumbled upon this page by searching for information on the same error.

Creating default object from empty value workbench_moderation.module:1787  [warning]
WD node: EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7844 of /var/www/includes/common.inc). [error]

The fact is... I don't have the node_clone module enabled! But I have Workbench Moderation 7.x-1.4 and -- I think it's related in my case -- uuid_features 7.x-1.0-alpha4 that I use to feature some nodes.

Hope this helps.

Need more detailed steps to reproduce this.

Thanks for those more detailed steps.

Perhaps you can try switching to the save-edit cloning method and see if it gives the same error?

In either case, workbench moderation's treatment of revisions as drafts might be the problem here. You would need to follow the code flow, and there might need to be some workbench-specific fixup code for an alter hook.

No, I mean in the module settings you can choose between a "prepoulate" mode and a "save-edit" mode. I expect you'll see the same problem with save-edit also, but it's worth a try.

My testing has shown different results, and I get the same error message using both settings (admin/config/content/clone) "Pre-populate the node form fields" + "Save as a new node then edit".

Only when the page being cloned is Published does the error occur for me. If the page being cloned is in Draft or Ready to publish state there will be no error message. In all cases the newly cloned page is a Draft with no Published.

I think the issue lies in the following lines:

if (variable_get('clone_reset_'. $node->type, FALSE)) {
    $node_options = variable_get('node_options_'. $node->type, array('status', 'promote'));
    // Fill in the default values.
    foreach (array('status', 'moderate', 'promote', 'sticky', 'revision') as $key) {
      // Cast to int since that's how they need to be saved to the DB.
      $node->$key = (int) in_array($key, $node_options);
    }
  }

Especially the entry 'moderate'... Shouldn't this be 'workbench_moderation'? I didn't write a patch for this because I am not sure about it, maybe there was another reason for this.

For now I fixed it by adding the following in another module:

/**
 * Implements hook_clone_node_alter().
 */
function MODULE_clone_node_alter(&$node, $context) {
  $node->workbench_moderation = 0;
}

This works because in workbench_moderation_moderate() the following code is being executed:

  if (!empty($node->workbench_moderation['published']) || !empty($node->workbench_moderation['current']->unpublishing)) {
    // Clone the node to make sure our data arrives intact in the shutdown
    // function. It might still be altered before the shutdown is reached.
    drupal_register_shutdown_function('workbench_moderation_store', clone $node);
  }

Thus when cloning, at this point, the workbench_moderation settings got cloned as well so when cloning a published node the following structure will be filled:
$node->workbench_moderation['current']
$node->workbench_moderation['published]
etc.

The current will have the new clone node settings but the published entry will have the original published node settings so it will go through the workbench_moderation_store() function where the following will be called:

  if (empty($node->workbench_moderation['current']->unpublishing)) {
    $live_revision = workbench_moderation_node_live_load($node);
    $live_revision->status = 1;
  }

But for the new clone, workbench_moderation_node_live_load($node) will give back a woeful result which will be saved later inside the workbench_moderation_store() function so you will get the exception...

I just used the same logic as node_clone does when it sets the default values for things like 'sticky', 'moderate', etc so:
$node->$key = (int) in_array($key, $node_options);
which would result in 0. But I assume either 0 or NULL would work.

Hmm, I'm also seeing this issue, and it seems that once the node is saved in this broken state, it remains in this confused state...

I tried iSoLate's suggestion to use a hook alter but that didn't seem to work - possibly because $node->workbench_moderation is an object of states rather than a bool?

We are also experiencing this issue.

Confirmed that the error goes away when using the save-edit method instead of the pre-populate one (admin/config/content/clone).

Attached is a quick patch based on what @iSoLate described in comment #12 -- it seems to work, though I am not sure what the implications are. If we go that route, maybe we will need to update {system} and assign workbench_moderation a higher weight than node_clone's.

Alternatively, how about implementing hook_node_clone_alter() as described in #12 in workbench_moderation ? Made a suggestion here: https://www.drupal.org/node/2331169#comment-11114593

I think there is a better place for workbench_moderation information reset. _clone_node_prepare seems to be the best place because it allows to control a reset to defaults via settings that node_clone module provides.

I ran into this issue as well, only to realize that the configuration of node_clone provided a solution.

On the config page (/admin/config/content/clone), there is a section "Should the publishing options ( e.g. published, promoted, etc) be reset to the defaults?" by checking off the ones that are applicable cloning and using workbench_moderation results in the expected behavior of the cloned node being reset to the content type's default publishing options. Thus, cloning a published node saves the node as unpublished if that is the default publishing option.

I can confirm that #20 is working.
Would be nice to have this documented.

Enhancement over #19. Improved if conditions.

#22 is working for me. Thanks.

So after trying #20, we were still getting the error on cloning content. In order to fix the cloning we used the patch from #22 and that seems to have fixed the issue.

There is a typo on the PHP comments in the patch in comment #22 - is "newly ceared" meant to be "newly created" or "newly cleared"? (I almost just posted an updated patch, but decided I wasn't 100% sure of the intent.)

Sorry for the typo. Corrected the comments.

#26 is working for me!