Grant Anonymous users permission to subscribe via emails for posts in my website

I don't think this will ever get implemented, although, I for one would love this feature. It seems like every Drupal module is dependent on the authenticated user role and having a UID to attach to.

But this would be a great feature and I've seen it in many other web apps all over the internet. Anon users are simply presented a form to enter their email address if they try to subscribe to something.

Hello.

I wrote patch which allows anonymous users use subscriptions.
Also this module is very interesting for me and I can be co-maintaner if you want. If it's not possible, I will be happy if you just approve my patch and specify me as author of commit.

Thank you.

Thank you for your patch.

Anyone interested enough to review it?

You are welcome to stick around and help in the queue as a first step towards co-maintainership.

It seems no one is interested. But I think it's very important for this module.

#2132721-2: Display subscriptions_user_suspend_form setting in block claims to be doing this with Rules, Flags, and Subscriptions Rules. What do you think of that approach?

I should see patch for compare these ways. I implemented my method in the way of subscriptions module (just add code into existing functions and few new functions). Also I already tested it on two of my projects.

Any news?

Yes, but yours is a big chunk of code to maintain going forward. And support is not overwhelming, judging by the number of people who cared to review.

If it can be done in a more modular way, that would definitely be preferable.

>If it can be done in a more modular way, that would definitely be preferable.
Sorry, but it's not possible. Because I should modify existing functions. I can be co-maintainer of module if you would not mind and support this code.

Sorry, double comment (DELETED)

Awesome patch! I have installed the patch with no problem and am testing it now. Definitely include in the module and push dev to release. I will post back with any problem I see shortly.

Everything works as far as I can tell.
One important feature needed....

You should do rudimentary testing on emails entered to make sure you only accept things that at least look like an email and also prevent spam.

I think you can use this function, valid_email_address()

Thank you for review.

I added this validation. I hope patch will be applied :)

Updated patch installed and the email validation works great. Thanks!

Noticed another small problem. If I have subscribed as a registered user I can then subscribe again as an anonymous user with the same email. This may not be a huge problem, but in that case the user will get two emails.

Thank you for this report. I will fix this problem on weekend.

hi, I have tried to apply patch, but probably i did it wrong, and applied to the module already istalled. It's give me the error that can't find some Tables in database...
so can you please clarify, how to apply patch? do I have to download module, apply patch localy, and then upload it to the website and then isntall? so it could create requared Tables???

regards,
Kos

@KoshaK

You should use version 7.x-1.x-dev version. Check this.

@eugene.ilyin
Thanks for the advise, but that is the version that I used...

Ok.. have managed to get it working and it's works fine.

One question - as long it's Anonimous subscribers - where I can find the List of them

Thanl you...

I too I have created an implementation of this functionality that works. I would like to contribute it here.

any progress on #17?

@webservant316
Sorry, but now I'm overloaded in office and I have no time for it :(
I will try to check it as soon as possible.

Is there a chance we can add some hooks here and there, so we can keep this functionality in a separate module?

Preventing spam is a huge issue. Probably sooner rather than later, people will ask for email verification, and this will need to grow...

@jazio.net:
Please open a new issue (and post crosslinks). Adding a completely different implementation here would cause confusion, but I'm certainly interested to see your approach.

@salvis,
>Preventing spam is a huge issue. Probably sooner rather than later, people will ask for email verification, and this will need to grow...
I added validation for email. Or you mean the other problem?

So, this patch is interesting for you https://drupal.org/comment/8412157#comment-8412157? Or you will not apply it in the future? As I already told, I can be co-maintainer. Because it can be faster than create patches and wait when them will by approved.

As I already told, I can be co-maintainer. Because it can be faster than create patches and wait when them will by approved.

Thank you for your offer, but this is exactly the wrong reason for wanting to be co-maintainer. Fact is that you continue to ignore my wish to look into implementing this in a more modular way, and this proves that we would not get along.

@salvis

Sorry, but I not understand what you want.

sadly something is broken. don't think I changed the subscription module, but now node updates only send one email to the first subscriber in the queue. the rest are ignored.

Actually, the anonymous patch can only handle ONE anonymous user. I didn't notice it before because I only tested registered users with ONE anonymous user. However, if more than one anonymous user is subscribed email will only go to the first on the list.

In the _subscriptions_mail_send() function it think this code...

      db_merge('subscriptions_last_sent')
        ->key(array(
          'uid'           => $uid,
          'send_interval' => $send_interval,
        ))
        ->fields(array(
          'last_sent'     => REQUEST_TIME,
        ))
        ->execute();

This code marks all anonymous subscriptions in the queue as sent after the first one because the uid and send_interval for anonymous subscriptions are all the same.

What is the fixt?

Also the queue count at admin/config/system/subscriptions does not include anonymous subscriptions.

OK - I debugged and fixed this. Sorry I don't have a means to patch the patch, but here are the fixes to the above patch to get anonymous subscriptions working...

Change lines 63-65 in subscriptions_mail.admin.inc to this

if (empty($record['suspended'])) {
    $active_count += $record['count'];
}

Change lines 139-153 in subscriptions_mail.cron.inc to this

if (!user_is_anonymous()) {
    db_delete('subscriptions_queue')
	->condition('load_function', $queue_item['load_function'])
	->condition('load_args', $queue_item['load_args'])
	->condition('uid', $queue_item['uid'])
	->execute();
}
else {
    db_delete('subscriptions_queue')
	->condition('load_function', $queue_item['load_function'])
	->condition('load_args', $queue_item['load_args'])
	->condition('uid', 0)
	->condition('mail', $queue_item['mail'])
	->execute();
}

I would appreciate any efforts to clean up this patch and get it included in the module.

Thanks, webservant316.

@eugene.ilyin:
This needs to go into a separate module that can be enabled or not. Some of the existing code may need to be changed, but the bulk of the code needs to go into a separate module.

99% of the Subscriptions users are happy with the module as it is. They would be (to put it mildly) very surprised to see their site suddenly offering anonymous subscriptions.

Aside from issues like #30, anonymous users have no way to unsubscribe, and there is no provision for verifying email addresses, i.e. anonymous users can subscribe just any third parties (who cannot even unsubscribe!). As soon as you start getting spam complaints, you'll need an administrator function for reviewing and removing email-only subscriptions.

It would be foolish for me to put code into the main Subscriptions modules that will ultimately force my users to hand-edit their database. Eugene, you don't seem to realize that this is production code. We cannot commit quick hacks just because you think they should be useful and good enough for your site.

I consider the things listed above (unsubscribe, email verification, administrator function) to be minimum functionality to actually use this on a production site, and when you think about implementing them you'll probably realize that the proposed database schema changes are not sufficient. You probably won't get around creating (hidden) users with uids, so that you can properly manage them.

Anonymous users can easily unsubscribe through the unsubscribe link they get in any subscription notification. I tested it as working. However, I still agree that this should be made into a sub-module and that there should also be email verification.

Any thoughts on the final integration of this patch? I am planning to head into production with what I've got working, but if there is no upgrade path to the final solution I could be in trouble.

My company may have $.

No takers?

No one has contacted me yet. The integration I propose seems like it would be very useful.

Checking back. Hey what it needed to get this patch applied to dev? Maybe I can do it myself.

#32 and #33 are surely the biggest pain points.

I think the changes to enable anonymous subscriptions are too intrusive to encapsulate as a sub-module. Instead the better strategy is to include the feature directly in the module as the patch + #32 effectively accomplish. However, an additional settings flag should be added so that anonymous subscriptions are OFF by default.

Also from #33

Aside from issues like #30, anonymous users have no way to unsubscribe

This objection is not true. If an anonymous user subscribes it is true that there is no form on the website for them to unsubscribe on their own initiative. HOWEVER, any email notification they receive can include an unsubscribe link and this link works perfectly to unsubscribe them. This is more than sufficient.

Is there any other objection to moving forward to include this in the module?

Someone does need to combine the patch + #32 and also add a checkbox in the subscription settings page to enable or disable (default) the anonymous subscription feature.

I was planning on upgrading to the lastest dev. I am guessing the features above have not been integrated. I sure would like to see that. Anything I can do? Anyone else?

I think the changes to enable anonymous subscriptions are too intrusive to encapsulate as a sub-module.

I see nothing that cannot be done with hook_schema_alter(), hook_form_alter(), and hook_query_alter(), and possibly a little help from Subscriptions core.

My comment in #1456560-45: Integration into OG? applies here just as well. I tried to guide this in the right direction starting at #10; persistently ignoring my input does not advance it one bit. This feature here is far from complete and it may even require a redesign before it becomes production-ready, as I mentioned in #33. Keeping it separate from Subscriptions core is an absolute must — I will not allow it to creep into core.

Aside from issues like #30, anonymous users have no way to unsubscribe

This objection is not true. If an anonymous user subscribes it is true that there is no form on the website for them to unsubscribe on their own initiative. HOWEVER, any email notification they receive can include an unsubscribe link and this link works perfectly to unsubscribe them. This is more than sufficient.

I disagree. It's nice if the unsubscribe links work, but the site admin may well choose to not send unsubscribe links, because they enable anyone receiving a copy of the notification to unsubscribe the original recipient. For that reason, and because I think that my user types are likely to inadvertently click on those links, I usually remove the unsubscribe link on my sites.

Is there any other objection to moving forward to include this in the module?

We'll start discussing the finer points after we've overcome the blockers...

@salvis. Thanks for you comment. Anonymous subscriptions are essential for my use case and I already have the patch in production along with the bug fix to the patch in #35.

I am still hoping to get help and recruit development and my company has $ to pay. If I cannot get the help I will have to figure out how to build the sub-module myself. I had already just begun to try to assimilate the above patch plus #35 into a clean patch. However, I will restart with the guidance of #42.

However, it may take me awhile so... anyone want to build the sub-module for $? Frankly after looking at the patch plus #35 it really is not that big a job for someone who knows the module and knows Drupal 7 development.

I have moved to the 'watcher' module because it handles anonymous subscriptions natively already. The 'watcher' module does not seem to be as well maintained nor have as large an audience. However, anonymous subscriptions are included. The 'watcher' module did have a few bugs that needed patching, but the patches are more easily maintained than the above patches. Here is my post over there https://www.drupal.org/node/2304525.

If someone ever does write a sub-module as @salvis requests I may be back. Thanks.

@salvis I will work on a submodule 'subscriptions_anonymous'

Great! Please let me know if you need a hook or something like that.

I was wondering if this feature was eventually added to the module.

No, it wasn't. This thread reflects the true current state.

Sorry guys i won't work on this finally, I don't have a use case anymore and no spare time available.. :/

Thanks for letting us know, Delphine Lepers.