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.
Comment | File | Size | Author |
---|---|---|---|
#7 | 1593792-7-unpublishaction.patch | 1.35 KB | minorOffense |
| |||
#2 | add-unpublish-rule-1593792-2.patch | 2.47 KB | jrsinclair |
Comments
Comment #1
jrsinclair CreditAttribution: jrsinclair commentedI understand that this may be impacted by however #1436260: Saving nodes outside Workbench Moderation leads to incorrect state transitions (e.g., "needs review" appearing as published) is resolved.
Comment #2
jrsinclair CreditAttribution: jrsinclair commentedI'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 useaction_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.Comment #3
jrsinclair CreditAttribution: jrsinclair commentedComment #4
thekevinday CreditAttribution: thekevinday commentedLooking 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...
Comment #5
jrsinclair CreditAttribution: jrsinclair commented@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 inworkbench_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 functionworkbench_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 inworkbench_moderation_node.inc
has the following at line 303 (just beforenode_save()
:I think you're right, we need some help from either the Rules or Workbench Moderation maintainers here.
Comment #6
minorOffense CreditAttribution: minorOffense commentedThere's a function now in 1.4 for this
in workbench_moderation.module
Comment #7
minorOffense CreditAttribution: minorOffense at Coldfront Labs Inc. commentedHere's a slightly different take on it. This just unpublishes the currently published revision.
Comment #8
truls1502Tested patch #7 and works smooth.
Comment #9
truls1502The patch I mentioned worked with the module I used 7.x-3.0, so I am changing the version to that issue too.
Comment #10
truls1502