Subscriptions and Modr8
| Project: | Subscriptions |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Hi,
Thanks for the great module. I have noticed one problem when both Modr8 and Subscriptions are installed: Subscriptions sends out emails for items that are in the moderation queue.
I don't know how you think this should be dealt with. Subscriptions could be easily modified to check for the 'moderate' field and not send out emails if it is set. This does cause a problem, however, because the emails are never sent once the node is approved.
I've patched my install of Modr8 and Subscriptions so they interact better. This might be useful to people, so I'm putting it up here. This needs testing, so don't rely on it for a production site until you have testing it! I don't want to make promises on my programming expertise, but it appears to work on my site.
| Attachment | Size |
|---|---|
| modr8_admin_inc.patch | 1.26 KB |
| subscriptions.patch | 2.54 KB |
| subscriptions_content.patch | 1.29 KB |
#1
I see no need for a subscriptions_modr8_interface() function — why not call subscriptions_queue() directly?
$event['node'] must be a full node object.
In addition, implement the following hook (untested):
<?php/**
* Implementation of hook_subscriptions_queue_alter().
*/
function modr8_subscriptions_queue_alter(&$event) {
if (!empty($event['node']->moderate)) {
$event = NULL;
}
}
?>
Subscriptions does not need any patch for this functionality.
#2
#3
Yes, I agree. At the time of writing, I thought it might be useful to have some flexibility in how Subscriptions responded. You are correct -- subscriptions_queue can be called directly.
#4
Wait, I'm sorry -- I think I overlooked the point of your post! Adding a hook to _queue_alter() should handle what I tried to do in my patch?
[edit]
Thanks for the suggestions, and your patience! You've pointed out much better ways to do this that are less "hacky". I think modr8 still needs to be patched to do what I want, but this is a big improvement.
Thanks for guiding me to the right approach.[/edit]
#5
My pleasure. Maybe you can convince the Modr8 maintainer to add that support (but do make sure that the full node object is sent!).
BTW, note that it's hook_subscriptions_queue_alter(), not hook_queue_alter(), IOW, it's a Subscriptions-specific hook.
Maybe adding a comment would be nice, so:
<?php/**
* Implementation of hook_subscriptions_queue_alter().
*/
function modr8_subscriptions_queue_alter(&$event) {
if (!empty($event['node']->moderate)) {
// Tell Subscriptions to ignore the node under moderation,
// we'll re-queue in modr8_NAMEOFFUNCTION() it when it's released.
$event = NULL;
}
}
?>
BTW, by-lines are useful when you patch code locally (aka hack modules), but they'll never go into cvs on d.o, so you should remove them when posting patches that you hope to get accepted.
#6
Right, got it : _subscriptions_queue_alter(&$event).
I also fixed the ugly $node hack because I learned how to use node_load, so that's fixed too and subscriptions_queue gets a full, real $node object.
#7
This seems to work as expected on my site. Modr8 does need to be patched for it to work, I'm not sure of a way around that other than to create a new modr8 approval form to replace the original.
#8
Please post uncompressed files. It's unlikely that anyone looks inside .gz files...
#9
Oops, sorry.
#10
You might be able to add your own submit function for modr8's form, but this would mean you'd have to duplicate the code to analyze the user input, which would create strong coupling.
I don't know whether it's worth the trouble to have a separate module, since a change is required to modr8_admin.inc anyway. The modr8 maintainer will have to decide.
If he likes having a separate module, then you could move the code in the patch to the add-on module and replace it with a simple call in the patch (untested!):
<?phpmodule_invoke('modr8_subscriptions', 'queue', $nid);
?>
This would also remove the need for checking for the presence of Subscriptions, because it's a dependency of modr8_subscriptions.module.
Some general comments:
Your indenting and white space is not quite standard; also, Drupal uses TRUE rather than True.
Patches are intended to be refined until they can be committed verbatim. A comment like
/* end modification */does not make sense in that context (besides being the wrong type of comment). Once the code is committed, no one cares where it came from or what and how much was modified when. That information is preserved in CVS, but it would be junk in the actual code.
Feel free to move this thread to the modr8 queue when you're ready.
#11
Thanks, I'll review the coding standards. I think the module is closer to the style standard than the patch.
#12
Automatically closed -- issue fixed for 2 weeks with no activity.