Here are some notes that I took while comparing these system, based on a couple hours of poking around and reading code. Anyone feel free to jump in here and correct me on any of this stuff, especially if you've actually /used/ either of these modules before. :P
Subscriptions module came first. This module has been around a long time (since at least 4.3), and gone through many different maintainers. In Drupal 5, chx re-wrote large parts of it to make a 5.x-2.x branch, and the current maintainer, salvis, seems to be very involved and keen. However, due simply to the age of the module, some of the code is a bit convoluted.
Notifications module is a fork of Subscriptions by the Development Seed guys that has some code clean-up and has made the code more modular. So modular, in fact, that one could argue it's been taken to completely insane levels. ;) But it has some nice features like Mailhandler integration (which is also in mail.inc, although I doubt that anyone's used it since it was coded :P), the ability to send notifications via SMS, etc.
Each module employs a "stack" something like the following:
- Basic API functions for managing subscriptions and the queues of what stuff to send to whom: Subscriptions/Notifications modules, which are configured with Subscriptions UI/Notifications UI modules.
- The "Send the notifications out" part. Subscriptions uses the bundled Subscriptions Mail module, Notifications piggy-backs off the Messaging module to provide this. Messaging, in turn, provides sub-modules to send things via e-mail (PHPMailer or regular drupal_mail()), SMS, etc.
- The "What stuff can you subscribe to?" part. Both modules provide a hook that other modules can implement in order to provide subscription forms. So you have sub-modules like subscriptions/notifcations_taxonomy.module, subscriptions/notifications_content.module, subscriptions/notifications_cck.module, etc., each of which explain how those modules innards work to the appropriate module.
What this means in the practical sense is that whichever solution we go with is going to mean module dependency fever: we need at least 5 sub-modules with Subscriptions module (though html_to_text is included in D6), and something like 9-10 with Notifications/Messaging, in order to get the same functionality as our lovely little mail.inc. Furthermore, we wouldn't be eliminating any code, really. We'd simply be moving most of our logic from mail.inc to project_issue_subscriptions/notifications.module. :\
What I would love to see instead is for someone to write a views_subscribe.module (or whatever) that handles the "list of stuff" that should be subscribed to. This would then integrate with either Subscriptions or Notifications module to handle the queueing/actually send mail/SMS/whatever to people stuff. chx has some notes written about this here: http://drupal4hu.com/node/57
Rationale: Project issue already has Views integration (aclight tells me that Views required in D6). So does Organic Groups, taxonomy, CCK, etc. We install something on Drupal.org like Flag module, which allows people to toggle a "subscribe" flag on project issues (or, heck, anything! forum topics, etc). Then the "My issues" view is adjusted to look for those, and views_subscribe is configured to send out notifications of new/updated nodes within that View by whatever means the user choosesn (RSS, SMS, E-mail, carrier pigeon...)
Thoughts?
Comments
Note that the use of a more
Note that the use of a more generic notifications system could then let people subscribe to forum posts and other important pieces that aren't just the project issue queue.
More thoughts from merlinofchaos...
Talking about a mythical views_subscribe.module:
[16:16] Ahh, nuts. I thought he'd gotten somebody to code it. :/
[16:17] And I'm not entirely sure that's quite the right way to do a subscribe-to-view module.
[16:18] Though maybe. It's kind of complicated, because subscriptions work in a different timescale than views.
[16:18] *** djohnson (n=djohnson@c-24-99-196-167.hsd1.ga.comcast.net) joined
[16:18] Hmm. Unless!
[16:19] Unless you have a 'last notified nid' table, which is nid + viewname + timestamp, and your view subscribe automatically adds that filter, comparing it to a 'last notified view' table which is just view + timestamp. Possibly with a subscription id.
[16:19] In fact maybe you use the subscription id and not the viewname.
[16:20] Then, the view automatically brings up results that have not been notified. However, you often need to be notified of changes.
[16:20] Hm.
[16:20] Complex.
[16:21] Though actually, 'nid' is dumb unless you're using views 1. If we're talking views 2, nid is wrong, because it could be multiple kinds of objects.
[16:22] And if you're pretty much hardwired to created/updated times, then that's okay too.
something
http://drupal.org/project/notify_by_views
edit: just realised this is for notify module (which is deprecated), not notifications :(
Glad you asked :) I have
Glad you asked :)
I have already placed my bet on Notifications.. OG for D5 is shipping with some nice integration. D6 will not have any native OG notification but instead leverage Notifications if present. I think Notifications is really tight. I'd like to see it used here. It started as a fork of subscriptions but it has drifted far enough that this isn't really important/relevant anymore.
You are right about Notifications requiring many modules - more than d.o is generally comfortable with. Thats further reason IMO to split off project to its own site so the project module and ratings/reviews/whatever and notifications and all that can flourish. I think Catch eloquently made the case over here.
As for Flag module - it is a plausible solution here. I think the missing link you describe can be serviced by Views Scheduler. I never used that module, so I'm not positive.
.
I've gone back and forth on these two modules. I finally settled on subscriptions but it was almost a coin toss. And now Moshe has me thinking I should have gone with notifications since I use OG on that site. I really hate that so much parallel development is going on with these two modules.
I think what gives noti the edge in this case is the ability to send the notifications to a variety of places. I know a lot of people like email when something they subscribe to is updated but I live in my tracker. I want something to show up there when a watched post is updated. I'm hoping that will eventually be possible.
Whichever one is chosen, could some jquery/js expert please do something about the UI? It sucks in both of the modules.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Flexibility is Key in the long run
I'm betting on Notifications because I see a future in sending updates to IM, Twitter, Jabber and lots of other yet to be announced web services. There seems little doubt in my mind that email is going the way of the dodo long-term, in the mean time, Notifications sets the opportunity to send to anything given a bit more development of the glue or that particular service. Someone could probably figure out some crazy way to mash these notifications into a google map for some unknown reason.
Anyway, flexibility seems like it will always win out in the long run and is one of the reasons I'm so enthusiastic about Drupal as a whole.
I'm going with Flag module.
I'm going with Flag module. I encourage you to take a look at it and review.
http://drupal.org/node/34496#comment-930005
Formatting of content
This is coming from a different angle as I am a non-developer. Possibly this comment should go somewhere else - sorry if this is an inappropriate place. Also I have only looked at Subscriptions and Notifications (and Notify, which I use at the moment and am trying to replace). Apologies to the module developers if I have mis-represented anything - I will of course correct it.
Firstly on the general question about what is a desirable degree of modularity I would say that this is a point in favour of both of Subsciptions and Notifications. It's worth looking at it the other way round, isn't it? - not that you have to have all these modules to get it to work but that actually you don't have to have them all - you only have to have the ones you really need. More than one or two, but not all of them. You don't have to load up code you are not going to use. By implication, the modules are geared towards extensibiity which is surely a good thing not a bad thing.
From that point of view, Notifications is probably better than Subscriptions because it takes that philosophy further eg with features like the messaging framework and Tokens.
With Notifications, I was able to use the mimemail message-type so my nodes came through with italics and bold etc etc preserved from the original post. And I could embed a bit of html in the template and it got translated.
I was surprised with Subscriptions (given the fact that it is such a well-developed, well-thought-out framework overall) to find that it was only going to deliver plain-text emails - following in the footsteps of the current Notify module. And looking in the support forum I noted Salvis saying "I think that trying to send out HTML emails would be
a) difficult to implement correctly and satisfactorily
b) a constant source of feature requests for additional tweaking possibilities
c) a constant source of support requests of the type "why don't my emails look like I want them to?"
The problem with that is that for my site and I am sure many others - including Drupal Groups at a guess - emails from a site are the main form of interaction with it (if getting an email can be described as interaction). Thus the appearance of those emails is particularly important. It is paradoxical if so much attention is devoted to the appearnce of websites but not the emails they send out.
Despite this drawback of Subscriptions, it was also clear from Salivs's post that an html feature would be possible through creating another add-on module. That looks like the way to go - though I wondered if an existing module might do the trick?
Where Subscriptions wins is that it works more effectively out of the tin, with lots of well-thought-out user interface options. In particular, with mail template module installed there is the list of all the different content types each with its own template. Admittedly, actually editing a template is a bit beyond me but at least I could do it if I wanted to.
In this area it was Notifications that seemed relatively deficient. Although you can select notifications by content type it didn't seem to have different templates for the different content types. The Tokens all worked very well, but there only seemed to be one template to put them into. Consequently, if you put a token from one type of cck content (lets call it type [1]) into the template and were notifiying the user of different type [2] you would get the unresolved token from [1].
As a general aside, It's hard for me as a non-tech type to understand why, given that drupal handles putting content etc onto the screen so effortlessly, it should be hard to do the same thing into an email. As far as the website goes, you can put posts of all different types onto the frontpage of your site without having to specify templates and they will all come out appropriately formatted.
Perhaps you could get around this issue with Notifications if you stuck a lot of code into the template, I'm not clear what type of statements can go into a template - php? html? .css? (You see how profound my ignorance is!). But Subscriptions gives you templates for each content type that are created automatically. That looks a better approach. And with Notifications, even if coding would sort the problem, it would nevertheless be beyond the reach of non-technical site-admins like me to do the coding.
Another big plus with Subscriptions is the option to select whether you want to be notified about comments and updates to nodes. With Notifications there is no option to select whether you get notified on an update. So if you have selected to be notified of a particular content type and someone is doing little tweaks to a node, you will keep on getting notified - including with the full body of the node if it has one (eg it could be an entire page). The one thing you don't want your site to do is bombard your users with stuff they may not really want. So that is quite a big one for me.
(Notify module is a pain there. I f you send out a newsletter, the users with Notify turned on will get the newsletter and a notification to tell them they are getting a newsletter! And if they have asked to be given the body of the content they will effectively get the newsletter twice. But let us at least take our hats of to Notify for giving you the option of title, title and teaser, and full body as simple radio buttons for the user.)
Admin-wise, Notifications functions are more scattered around and a little harder to find. But it is much better on queue processing, enabling you to interrogate the status of the queue, reset it etc. Not something you would need to do a lot maybe but good to have when you need it and particularly when you are testing. For example, when you are testing there might be problems with the environment that might interfere with notifications going out properly. By being able to interrogate the queue you get a better handle on where in the processing sny problem might lie. I couldn't find any comparable functionality in Subscriptions.
Watch out for "digests". Subscriptions digests are genuine digests, collating various items of content and presenting it in one email, but in Notifications it just seems to be a single line with a link back to the site. But that isn't really a digest in my view and it is not what a lot of users want. They don't want to have to go back to the site and login, they want the content right there in their email inbox. So this looks a big plus in favour of Subscriptions - unless, again, it is possible to do something more sophisticated with the templates in Notifications.
Overall, I thought subscriptions is closer to being the finished article, which makes the lack of html emails particularly frustrating. And it could do with admin functions for its queues. . Notifications strikes me as a bit more elegant in its architecture and more extensible but I think it could do with a little more focus on what users actually get from it eg the option to select notifications on updates or comments.
Quite a lot more testing to do for me, particularly on how multiple comments in a thread would appear - but I need to get the basics sorted out first.
If anyone can help me get nicely formatted content for different content types out of either of these modules I will be very grateful - to the extent of paying for it if necessary, because they are so fundamental to my site www.naepp.org.uk .
There's so much good stuff in these modules you have to want both of them to be successful. I'd love to see the best features of both in a single suite.
David Gibbens
David Gibbens
Good points
Thanks for this thorough review, David!
After reading through all related pages and reviewing the code and concepts of these modules, I think that Notifications implements a much cleaner architecture design, since the actual sending of messages has been spinned-off into a pluggable Messaging API. So Notifications module itself does nothing more than it ought to do - focusing on notification queues, user interaction, and third party module integration. While there is probably no reason for Subscriptions to also adapt and rely on Messaging, it seems like Notifications has a better thought-out overall design already.
I'm currently investigating which framework I will implement for Guestbook module. So far, it looks like Notifications will be the right choice, since OG also integrates it, and Messaging already provides integration with Privatemsg module. Because a common community site built with Drupal consists of OG, Privatemsg, and (sometimes) Guestbook, it seems to be the way to go.
Thoughts?
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
Current state of play
Thought I had better provide an update in case anyone treats my foregoing comment as current. I am only now in the process of implementing the notification/subscription functionality I wanted - I couldn't seem to move things forward back in 2008.
I am going with the Notifications suite of modules but not on the basis of having conducted a systematic review of notifications and subscriptions. My developer, Peter of LiquidCMS, had good things to say about working with Notifications, and when the relevant modules were enabled on my test-site it was quickly apparent that pretty much all the shortcomings I had previously identified had been addressed, so I did not feel it worth going through a systematic comparison with Subscriptions. Please note, therefore, that the fact I am going with Notifications does not mean that it is better than Subscriptions, just that it is good enough for me.
At the time of writing, I am still using Notify, now under DR6, and I can confirm that the DR6 implementation does address some of the previous shortcomings. In particular you now have the ability to decide which content types to notify. Previously, if I sent out a Newsletter, people also go a Notified of it, which was a bit daft. No longer.
However, one feature that has been added which I am not so keen on is that it now notifies when content is changed as well as added. If you are tinkering around with Stories for example, that can be a bit of a pain. But I think Notifiy remains a good module and so thanks for upgrading it.
David Gibbens
I'd prefer the same mechanism for OG and Project*
As someone who relies heavily on OG and Project* for different sites that I run, I'd definitely be happy to see the same mechanism adopted for both. Like David above, I've recently started looking to replace Notify, and started to delve into Subscriptions until I learned that Moshe had settled on Notifications for OG. Flickerfly's comments about keeping things open to other mechanisms besides email also resonate well for me.
Micah
Flexinode vs. CCK situation here??
I´ve got the need of installing one of these modules.
And I feel pretty much as I felt a year ago (more or less), with Flexinode vs. CCK.
My fate was that I chose Flexinode, and the whole bloody world have chosen CCK.
So I suddenly realised that I had +1000 flexinodes to convert to CCK. (Blessings to flexinode converter module creator).
I just feel that with my luck... it´s pretty much possible that I choose the flexinodish solution to this dilemma.
Cheers,
Rosamunda
Buenos Aires
www.ligadelconsorcista.org
About Notifications
Hi, I just want to drop some notes and comments about Notifications, since I'm the maintainer of that package.
First, replying to some of the comments here, I think I better post all the replies together
Yes, it certainly has a lot of modules. But this is what makes possible to have really lots of features without a gigantic module. At the end the more modules you can enable/disable, the amount of php your site needs to parse is actually less.
So though the installation/configuration may be a bit more complex, the end result is quite more scalable. You are just using the code you need. Besides, if you want some custom feature, you possibly end up building yet one more plug-in for your site instead of patching or using form_alter(), so 'disable the part you don't need/like and build your own' is encouraged
@Michelle
The thing with the UI is that every site out there is a completely different use case so after some thinking we've come to the conclusion that there's not such thing as an UI-for-all solution.
Actually we are building custom UIs for many sites we build, they just plug nicely into the notifications api. So really this is aimed to big sites with very different needs, that is why most of the framework is UI-agnostic, just a big API.
Well, we have this "Notifications UI" thing, that yes, I have to admit it sucks, but it is just a simple approach for quick deployment when you don't have the resources or the time to build your custom one. So it sucks but it works and it covers an insane amount of different use cases /subscription types. Though the main feature of it is that you can just disable it :-)
@davidgibbens, you make a lot of interesting points here:
True, we are not quite there yet, this is a part that needs some work (and will have more work). Though not really in the sense of just sticking together all the notifications in a long, long email (well, that will come too), but in the ability to get different types of digests (i.e. grouped by content type), better templating support and more themeability...
But the main thing is... have you ever got a daily digest by SMS?
No, it doesn't have them (yet). However, from a programmer's pov I think the token support is by far more extendable.
But yes, that's an important missing feature that will be coming.
There's a global admin option now to decide which events should trigger a notification and which ones not, and some hooks for supporting other options.
About an option for end users to pick, currently studying how to fit it into an already overcrowded UI...
So both modules have some advantages and disadvantages. The real breakthrough feature with Notifications though is that we are abstracting the sending part (Messaging), so it supports virtually any sending method, though so far only different mail backends, sms and web-UI (privatemsg and a native one) are implemented. This has some aditional requirements, like the need to use different templates depending on sending method, which makes configuration more complex
I have to say I miss some really simple solution for small sites (I also maintain some), like it was the Notify module, just enable and get nodes and comments by email, but it seems it's not being upgraded for Drupal 6 :-(
But about Notifications framework it will possibly become bigger but with more/smaller modules. We are aiming here at big sites with very complex/different requirements, so a simple 'enable and use' solution is not an option here and any need of having some part working differently will end up in yet one more plug-in so at least you can disable it and code your own.
However for most sites which just need a few basic subscription types and a checkbox, you'll possibly need just 2 or 3 of the modules (yes, I know, the difficult part is to know which ones and how to set them up), we'll possibly address this one with some good howto's.
About Project module I'd encourage that whatever solution is decided, it is done as some sending plug-in, just like Moshe did with 'Notifications OG', so at any point it can be replaced to use a different framework/backend. Anyway, if some feature is needed from Notifications module so Project module can integrate with it, just let us know.
(Or maybe you don't need the whole notifications/subscriptions stack, in which case I'd suggest to look into the Messaging framework only, which does support queueing and cron processing too on its own)
Sorry
I shouldn't have said it sucks. That was rude of me and brought on by frustration with going back and forth on these modules and not being happy with either of them. The problem is that I end up with the "links" section of posts looking like this:
What I would like is something similar to the "share" popup so that it just says "subscribe" in links and clicking it brings up the options.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
UI - share button (or addthis button)
I added a feature request for that Share popup a while ago - http://drupal.org/node/260399
Also, Iwant to reiterate what Jose said - OG has worked hard to integrate well with Notifications but the integration is completely swappable. The subscriptions folks and flag folks are welcome to build their own modules that integrate similarly.
What the world needs now....
Thanks for the constructive input and responses here. There are a few things I wanted to add:
Firstly, I didn't think the UI of either of the two modules was that complicated or user-unfriendly. For the functionality offered I think the UIs about right.
Secondly, re installation, just a tad more information about what the modules do would have been useful but this issue again didn't strike me as severe, I just enabled them one by one to see what they did - though in most cases the titles made that self-explanatory.
My final point is to emphasise a point I made above. There are zillions (lets say hundreds of millions - literally) of people working in back-office type environments all over the place that, if content is added to a site, would like to see it delivered by email. And when it comes by email they want it to be as professional-looking as possible. They don't want to have to log in to a site where half the time they can't remember the freaking login or password. To me, looking around my workplace, this is like a silent majority, we ageing office workers. We don't do Bebo or Facebook. We use SMS for texting our children and trying to find out what the heck they are up to now . Drupal has the ability to deliver the content in a website and it has with both notifications and subscriptions fairly sophisticated mechanisms for registering that content has changed, queueing up relevant notifications etc. But the final user experience when an email hits the inbox (and assuming you have multiple content types) is a long way short of what it needs to be. The non-programmer such as myself does not have the tools to do anything much about it - though we would not have a problem manipulating tokens etc. So these remaining drawbacks are very frustrating.
So finally - to put my money where my mouth is - I would be willing to invest in providing the missing links but I need someone who is willing, able etc to take it on. Because so much functionality is already there it would seem to me a relatively small project. But I guess everyone is busy (or maybe too expensive for me to afford).
David Gibbens
David Gibbens
Notify modules IS upgraded
In case anyone stumbles across this old thread and scrolled to the bottom because they couldn't make sense of the above...
Notify module has been upgraded for D6 for some time now, so if you just want a single module to enable & go, and you don't need an extensible API:
http://www.drupal.org/project/notify
However, I have a standing offer to re-deprecate the module if someone will provide a migration tool & a UI clone for Notifications module.
Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Recently, there were some
Recently, there were some critical (but vague) remarks made about notifications.module:
http://lists.drupal.org/pipermail/development/2009-March/032299.html
Are the details of this disagreement worth exploring when faced with the choice between Notifications and Subscriptions? Is anyone familiar with the details?
Cheers
Is anyone able to get the
Is anyone able to get the custom subscription types for the Notifications Add-On modules to work? I cannot get it to send anything. It doesn't add any items to the queue. However, regular notifications work, so the problem is with the custom subscriptions module. I tried the latest release and now the latest dev version too.
Do these not have a need to integrate with favorites?
Before i get into my comment; a quick reply to one of D.Gibbens remarks above (and not agreeing just because he is a client of mine). I agree that nice, well formed, tpl-able emails is crucial. I am currently reviewing both these odules and this thread has been great.. but one of the strongest points pointed out by Jose for N over S is pluggable msging.. YES, certainly very useful.. but have to agree with Dave, the vast majority of the non-GEEK world doesn't really manage their day to day lives via anything other than email.
ok.. on to my point...
Does the concept of favorites (as in favorites.module) not bare into this discussion? The concept of faves is simple - tag a list of nodes you are interested in. The concept of both N and S is also simple.. notify on "types" of nodes you are interested in (i.e. nodes by a user, tagged with a term, of a certain type, contained within a group, etc). My need/concern is why aren't these integrated? Ideally i would like a simple VIEW of "content i am interested in". And by this i don't mean the items i have tagged as faves; but the "content i am interested in" :)... would be really cool to say i am interested in a taxonomy term - and when i log into site i would see a block with the most recent content "that i am interested in".
I get the architecture issue with why this isn't automatically a part of subscriptions (and i suspect notifications as well; but haven't looked as closely) is that it saves rules re: interests and doesn't maintain a nid table. But possibly not that difficult to add in.
I was just about to start work on a faves/subs integration module and then saw this post and figured maybe faves/notifications would be better.
Peter Lindstrom
LiquidCMS - Content Solution Experts
or perhaps just Views integration
after digging into to this a bit more (i.e. my idea of integration of notifications/subscriptions with the idea of favorite nodes) i think the notifications module is on the right track with it's notifications_views module to add Views support.
They have the ability to list nodes that a user has "specifically" subscribed to. If their views handlers can join the "rules based" subscriptions (i.e. sub to a term or author rather than only a specific node) then i think this very useful feature will be available.
working on it!!
Peter Lindstrom
LiquidCMS - Content Solution Experts
Any Good Tutorials/Screencasts for Messaging & Notifications?
Just wondering if anyone was good enough to review some of the basic functionality and configuration of these modules in a screencast. I haven't found one yet.
Recent Comparisons?
Has anyone published a recent comparison of the two modules? If so, I am quite interested - especially if the comparison considers notifications 6.x-4.0-betaX.
I tried to use Notifications,
I tried to use Notifications, i simply wanted to let users receive notifications via XMPP when a new content updates/adds. But i got lost!! It seems possible but is it really?
for the latest
for the latest comparission
please see http://groups.drupal.org/node/15928