Closed (outdated)
Project:
Subscriptions
Version:
6.x-1.x-dev
Component:
User interface
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
2 Feb 2009 at 22:40 UTC
Updated:
27 Sep 2019 at 13:26 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
jwarner commentedFrom how I interpret the documentation here http://drupal.org/node/344030:
"Subscriptions does not support anonymous users -- there's no use in giving them any subscribe permissions."
I believe the answer is no. But I too would like to have a single page where an anonymous user can select boxes and also type in their email address. I'd like to show the user what we have to offer before the commit to registering on our site.
Comment #2
jsr47 commentedI'm afraid you've misunderstood my question: I want to offer a subscription at the time of registration, not offer subscriptions to unregistered users.
Based on a patch for Notify, the following patch does something similar for Subscriptions. It may need work for particular uses: for example, the subscription content-type is hard-coded to "story" since that is what I wanted. The only way to change this (at present) is in the module code itself. I might try to work out a way to create an admin tab for this, but since I don't need to change this much it is low priority.
[Note: I can't find the code I based this on. It was from a Notify patch, but I can't locate it. If you were the author, please say so I can credit you]
Jeff
Comment #3
salvisThanks for sharing your solution. As you point out, this is not a general solution — Subscriptions offers many different kinds and variations of subscriptions.
One-off patches to contributed modules (just like to core) are not ideal, because you have to re-apply them whenever you update. Your code does not need to live inside the Subscriptions module. Why don't you create your own module that has just your code?
Comment #4
jsr47 commentedFirst off, I submitted the patch mainly because I had learned from someone else's patch and it was very helpful to have something to work from. I agree, patching the module is sloppy, but I don't know how to make a module!
But this might be a good time to learn. :)
Comment #5
salvisIt's easy: Pick a module name, such as subscriptions_on_registration, create subscriptions_on_registration.info (follow the pattern of any .info file with a dependency) and subscriptions_on_registration.module files, add the subscriptions_on_registration_user() hook_user implementation and the _subscriptions_on_registration_user_reg_fields() helper function.
Comment #6
jsr47 commentedOK, this might work. Or it might destroy the planet. Do you feel lucky?
Comment #7
salvisPlease don't zip things. Hiding your files inside a .gz virtually guarantees that no one will look at them.
Comment #8
jsr47 commentedMy mistake (again!). I think this needs some work still, so it works with the different types of subscriptions available.
Comment #9
jsr47 commentedHans,
I wonder if you have any ideas on how best to deal with this module. I'm trying to think of how best to allow the admin to select the default type of Subscription during registration. I only use the Nodes module. Ideally, the admin form for this should allow the admin to select the module to use (node, blog, taxonomy?) and then update the rest of the form with valid options...
Jeff
Comment #10
salvisAh, you've come a long way! This provides a good start for those who need this functionality.
Providing full customizability is another matter. Maybe you can leverage the User Defaults and pick one role as the template for initial subscriptions? These subscriptions are entered into the {subscriptions} table with negative rids (role IDs).
Comment #11
salvisComment #12
salvis