I'm trying to perform some actions after a node has been "published"
I've noted that when a "New Revision" is created, hook_node_update is called twice -- the first time has the new unpublished revision details with the workbench_moderation current state of "published"
I've got the following code:
function mymodule_hook_node_update( $node )
{
watchdog("mymodule", "hook_node_update called");
if( isset( $node->workbench_moderation ) )
{
watchdog("mymodule", "workbench moderation found!");
if( $node -> workbench_moderation["current"]->state == "published" )
{
watchdog("mymodule", "Node has been published. Do something");
dsm($node);
}
else
{
watchdog("mymodule", "Node not yet published. Don't do anything");
}
}
}
When I look at the results $dsm(node), when the node has been published, the body is that of the new (draft) revision! I'm getting the following in the recent logs:
mymodule Node not yet published. Don't do anything
mymodule moderation found
mymodule hook_node_update
Workbench moderation Saved node revision: 43 as live version for node 1.
content page: updated Test Page.
mymodule Node has been published. Do something
mymodule moderation found
mymodule hook_node_updateI've redacted the date/time -- but these are all fired in succession upon creating a New Draft, entering some content and press "Save".
Also, I'm a bit of a Drupal newbie, so if there is some easier way to do this feel free to correct me.
Comments
Comment #1
nickkwest commentedTo sum this up, when creating a new draft from a published node, hook_node_update() is called twice, and the first call is on the current live (published) node, while the second call is of the draft version of the node.
It looks like workbench moderation is updating the live node revision (for some reason) before it creates the draft revision.
This is a problem for you, because you want to execute some code when a node gains the published state, and this is triggering a false positive.
Instead of using hook_node_update() workbench moderation offers hook_workbench_moderation_transition() that should allow you to accomplish your task.
You can find the hook in workbench_moderation.api.php
Here's some sample code that mirrors your code above:
When going from published to draft, this hook won't trigger the "Node has been published" message, whereas the other does. But going from any state to published will trigger it.
All this being said, and this being a viable work around, I'm not sure if Workbench Moderation really needs to update the old revision, that still might be bug worthy.
Comment #2
nickkwest commentedOk, upon further investigation, I can tell you what's going on and why dsm($node) shows the draft version but is "published".
It looks like the first trigger of hook_node_update is being done by Drupal core. This is the initial node save. Then afterward, WM re-saves the node with with the draft state. So it looks like this isn't really a bug, it's just how WM works.
Comment #3
tswaters commentedThanks! That's exactly what I was looking for -- I said to myself, "Now, if only workbench_moderation had a hook I could use when the state changes I would be golden" -- and there you have it, there is one.
It should be noted that I was actually doing my work against 1.1 which didn't have the hook ... I've since updated to 1.2 and everything is working great. Thanks again !
Comment #4
mccrodp commentedI've come across this issue now myself. Upon examining using XDebug, it seems as you've said above but the order of execution is:
As we may use The workbench moderate screen or any other method to change the state of revision, we cannot rely on the useful properties of the node object added on the node/edit & node/add pages, i.e. - workbench_moderation_state_current and workbench_moderation_state_new.
I have been playing around with this and still find there is no obvious way to detect for my use case, this second save causing the issue. My use case is that I need to up update messages in the message stack for new nodes (Published & Unpublished), new draft versions of nodes, updates to draft versions and unpublishing of live revision of the node.
At the moment I have a rather ugly if statement constructed through trial and error with the properties for the node object upon each possible combination.
Revision on it's own cannot be used as revision = 0 on the initial node creation. I may also be able to remove the isset(), but I need to test further. If anyone has any cleaner solution, please let me know. Thanks.