I've been using the features provided by #1226688: Rules Integration Support and they are absolutely fantastic. I can change revision states when certain actions are triggered, and trigger rules execution when revision states change. It all works wonderfully.

I would really like to be able to programatically unpublish content though. Currently, when I change a revision's state from 'published' to 'draft', it changes the state just fine, but does not 'unpublish' the node. It would be extremely helpful to unpublish a node after a fixed period of time through rules. Currently I have no way to programatically unpublish nodes.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jrsinclair’s picture

jrsinclair’s picture

I've rolled a quick-and-dirty patch. Basically I've copied the 'unpublish' code from workbench_moderation.node.inc, which is intended to be used in a form context, not in the context of a rules action. It should probably use action_do() but this would require someone with more familiarity with the code to look at it. For now, the patch is doing what I need it to do.

jrsinclair’s picture

Status: Active » Needs review
thekevinday’s picture

Looking at the code I am wondering about the manual db_update call.

Is there a function that already does this, or were you forced to to the db_update directly?

If there is someway to set the moderation state to unpublished on the node object directly, then the node_save() could handle the database write operation (hopefully this would mean 1 less databae call).

Also, be careful with the node_save().
I have had problems with calling node_save() directly because of two problems:
1) If one of the rules is designed to block a node save depending on certain events, then the node_save() here would bypass that.
2) There is the possibility of a double save.
- In my attempts to get this to work, I gave up and only implemented the pre_save version in which my function does not call node_save.

The real problem is we need to find a way to detect if the current operation is in a pre_save state or not so the rules can determine if they must or must not perform a node_save directly.
Though I am not certain what the proper solution to this is.
Perhaps I should open a support request in the rules module about this situation...

jrsinclair’s picture

@thekevinday Regarding the manual db_update()) call, I agree with you completely. I looked everywhere I could think of in the Workbench Moderation code to find an 'unpublish' function, but was unable to locate one. The only place I could find in the code where this happened was in workbench_moderation.node.inc when the user manually clicks the 'unpublish' link. So, the code in the patch is essentially a copy and paste of the function workbench_moderation_node_unpublish_form_submit().

I agree that this is probably not the best way to do it, but I'm not familiar enough with the module code as a whole to start mucking about with refactoring. I decided to put up a patch though, in the hope that more knowledgable people (like yourself) would comment and/or help improve it.

The node_save() issue is a tricky one. Even the original code in workbench_moderation_node.inc has the following at line 303 (just before node_save():

    // @TODO: do we trust node_save() here?
    node_save($live_revision);

I think you're right, we need some help from either the Rules or Workbench Moderation maintainers here.

minorOffense’s picture

There's a function now in 1.4 for this

function workbench_moderation_moderate($node, $state)

in workbench_moderation.module

minorOffense’s picture

Here's a slightly different take on it. This just unpublishes the currently published revision.

truls1502’s picture

Status: Needs review » Reviewed & tested by the community

Tested patch #7 and works smooth.

truls1502’s picture

Version: 7.x-1.x-dev » 7.x-3.0

The patch I mentioned worked with the module I used 7.x-3.0, so I am changing the version to that issue too.

truls1502’s picture

Version: 7.x-3.0 » 7.x-3.x-dev