New mod: notification email for every new message

All files from this thread

File Name	File Size		Posted by	Date
new_message_notification.zip	4.1 KB	open | download	zwerfkat	08/13/2007	Read message

This module allows users to receive a notification email for every new message posted on a forum. Can be enabled/disabled at the users control center for each individual forum (see "Edit Email Settings" after installation).

Installation
============
-extract the zip file and copy "new_message_notification" to your forum's mod directory.
-from the forum's admin panel, add the following Custom Profile:

Field Name: message_notification_user_field
Field Length: 65000
Disable HTML: no (important!)

-finally switch on module "New message notification module"

I want to note here that Phorum has data structure in place in the subscriptions table for this feature. However, in testing, the mail() function in PHP showed to be so slow that sending hundreds of emails on post would result in the posting process timing out. Now, I have not looked at this module. But, I assume it just loops the users and mails them all from PHP.

Brian - Cowboy Ninja Coder - Personal Blog - Twitter

Quote
brianlmoon
I want to note here that Phorum has data structure in place in the subscriptions table for this feature. However, in testing, the mail() function in PHP showed to be so slow that sending hundreds of emails on post would result in the posting process timing out. Now, I have not looked at this module. But, I assume it just loops the users and mails them all from PHP.

If it's something you want to do every single time, rather than in batch, running this sort of thing with the use of ignore_user_abort() or register_shutdown_function() is the way to go. The end user will be none the wiser and you dont have to cope with extra scripts and tracking extra data.

If you have a php with pcntl then you can use those functions to fork within your script and accomplish the same thing.

Otherwise, you need to store the information and deal with it in a batch.
In which case, you need one of the above options but only run the fork or shutodwn function during the time period you want your batch to go out.
Alternatives would include running the 'batch processor' through a cron job or via exec(), but not all hosting providers allow those options.

Now that I'm thinking about it. the "register_shutdown_function()" is probably something that should be considered in the core...in my mind it's the right way to handle this type of processing which can be handled after the user's received all their data and are happily plodding along reading other messages.

Ideally, admins should be able to specify emails be sent "immediately" or "immediately between start time/end time" or possibly some other criteria--once per hour, etc...this could help with some load issues on systems which get heavy use during parts of the day. It's a lot of extra work though, but for now I'd think the shutdown function would be a quick enough modification.

Following several reports on Internet, there might be two pitfalls when using "register_shutdown_function()":

1.You have to be sure the main program is not finished by "exit()".

2. This function doesn't work for time-consuming background processing, because the webpage doesn't close the connection. The workaround using output buffering and header('Connection: close'); seems to work.

As far as I can see Phorum does not use exit() under normal operation and it is using output buffering, or?

It's not using output buffering, but you can make it use buffering by adding an ob_start() to the start of common.php or header.tpl. You can also write a mod that runs ob_start() in the "common" hook.

The main program only runs exit if it's needed. For example when doing a page redirect or when sending RSS or a file.

Phorum 5.2 has a "phorum_shutdown" hook, which makes use of register_shutdown_function().

Having said all this, I think it's a bad idea to use this feature to implement large features like sending mail. IMO, this PHP feature was implemented for doing simple small cleanup work. Time consuming code should not be run at this point. Hence the problems that you might see if you let it run long running code. I really think that the only clean way is to implement a queueing system for the mail, which can process sending mail fully separated.

---

Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce