Compatibility with Notifications (Notifications Content) module? [#1415558]

I've begun evaluating the revisioning module and must say - it does a terrific job of what it promises - very slick!

Unfortunately I've hit a bit of a stumbling block with the Notifications module, which I'm using to allow users to "subscribe" to digest emails of new and/or updated nodes.

The notifications module (which queues emails via hook_nodeapi) doesn't play terribly nicely with revisioning. When an author creates a node, which is held for moderation and subsequently approved (published) by an editor, no emails are sent. It seems that the act of making a revision "live" does not constitute an update or insert in the eyes of nodeapi.

I've been able to get around this by applying the "publish post" action to the "When publishing a pending revision" trigger (as the "publish" action seems to cause a node update). FYI to others out there with Drupal 6 - you need the TriggerUnlock module to do this.

However, this still leaves *one* problem: when editing an existing node, all updates to "draft" revisions cause emails to be sent out (on update). So if an author spends some time editing a post, saving and viewing over and over, a barrage of duplicate emails will go out. I *could* disable the emails on node update - but with no node creation events occuring any more (the initial publish of a new post is considered an update) I would be effectively disabling all emails for node events.

Is there some way to get these two modules to be more aware of each other? Has anyone done this work before?

I'm a pretty experienced developer in other languages (c# etc), and I've got a bit of Drupal experience behind me (though it is a huge beast and there are lots of gaps in my knowledge). I'd be happy to have a play with the notifications module if someone is able to suggest what sort of hooks I might be able to access from the revisioning module. Some tips on what sort of revision information to look for in those hooks to determine when a revision is in moderation (and thus shouldn't be emailed out to subscribers) would be helpful too.

With suitable hooks into the revisioning module I may even be able to define some new events for the notifications module (e.g on First Publish / on Updated Revision) - or at least make the existing create / update more revision-friendly.

Cheers

Daniel

Comments

Comment #1

rdeboer

Melbourne

commented 25 January 2012 at 07:05

Hey thanks for liking Revisioning!

Without spending to much time on this now....

As mentioned on the Revisioning project page, the module adds a number of attributes to the $node object. Can you use some of these to derive the right conditions for emailing/not emailing in an implementation of a hook to decide whether an email should be sent?
For instance you could check $node->is_pending.

Also you may not have to do this programmatically. Would the Rules module not help?

Comment #2

TheDanScott commented 27 January 2012 at 07:32

Hi RdeBoer,

Thanks for your feedback. As you say, there are two possible approaches here: update the notifications module to be more aware of the sort of things revisioning is doing - or update revisioning to provide additional hooks for notifications to use (revisions-specific events such as "publish a pending revision").

I made a post on the Notifications module queue as well, and included some debug output I took from an existing node that was edited and saved (as a new, pending revision). In that output it seems as though the $node->is_pending value is based on the overall "node" - to reflect whether the node has a published revision. It was returning false for my node, even though it had a pending revision.

The complete output I posted is at http://drupal.org/node/981384#comment-5511218

You might want to have a look at my musings in that comment - where I ask if it would make sense to query the database for details of the VID specified in the node object - and let me know if you see any issues with what I suggest there. If you think it's safe/sensible to do then I'll go ahead and have a tinker and post a patch. If you know of any better way to check on the "status" of a revision (given a VID and a node object) then let me know too :)

Cheers

Daniel

Comment #3

rdeboer

Melbourne

commented 29 January 2012 at 22:12

Hi Daniel,

The reason why you are not seeing any of the additional revision info from the Revisioning module is because 'revisioning' comes after 'notifications_content' in the alphabet. Therefore notifications_content_nodeapi() is called prior to revisioning_nodeapi().

We could change this by decreasing the so-called "weight" of Revisioning. However this may have side effects on existing installs of Revisioning.

A better approach may be to call in your own code the function node_load($node->nid, $node->vid). This will load the correct revision (which is cached anyway) and will also invoke revisioning_nodeapi(), which will flesh out goodies like $node->is_pending etc. Try another dpm($node) to see what's in there.

Rik