As was foretold, we've added advertisements to the forums! If you have questions, or if you encounter any bugs, please visit this thread: https://forums.penny-arcade.com/discussion/240191/forum-advertisement-faq-and-reports-thread/
Options
decoupled php script
Sorcy
Registered User regular
Registered User regular
The company I work for uses a newsletter system on a PERL basis. We have heavily modified this system in recent years and it's starting to break apart on the seams (and in all honesty, I loathe PERL for all of its exploded whalegut-ness).
So I suggested to my boss to create our own newsletter system in PHP, with good documentation, clean classes and strong extensibility built in, right from the start. So far no problem, the only thing I could not wrap my mind around is the actual sending of the messages. We are talking 60000 recipients here in some cases, and it should not be necessary for the user to keep the browser window open until the script is finished.
So, is it possible to start the sending from the browser but somehow to decouple the sending script from the whole browser/server interaction? I would know how to do it in PERL, but as I said, I loathe PERL, and I don't want to go back to it...
So I suggested to my boss to create our own newsletter system in PHP, with good documentation, clean classes and strong extensibility built in, right from the start. So far no problem, the only thing I could not wrap my mind around is the actual sending of the messages. We are talking 60000 recipients here in some cases, and it should not be necessary for the user to keep the browser window open until the script is finished.
So, is it possible to start the sending from the browser but somehow to decouple the sending script from the whole browser/server interaction? I would know how to do it in PERL, but as I said, I loathe PERL, and I don't want to go back to it...
Sorcy on
0
Posts
* Keep a process running in memory, and send it a signal from the web request when you want to start sending mail. The web page and mail sender could be written in any language.
* Have the web request spawn a separate thread to start sending mail, perhaps with a lock to prevent accidental multiple threads. The web page and mail sender would have to be written in the same language.
* Have the web request fork and execute an external script. You'd have to be careful that refreshing the page or something doesn't spawn another process -- maybe atomically create a lockfile. The web page and mail sender could be written in any language.
I believe using system() will leave the parent process waiting for the child (and if you fail to redirect output, it'll definitely hang).
Using fork() and posix_setsid() is one way, but a much simpler (but not necessarily crioss-platform) solution is to hand it off to daemon like 'at':
`echo /usr/bin/php -q $my_php_script | at now`
Haven't played with this at all myself, so can't offer much other advice along those lines.
As Janin mentioned, regardless of the solution you choose. you'll want to pay special attention to is making sure that you limit the number of processes that get kicked off - if someone double-taps the submit you don't want two (or more) processes kicked off, each spewing out 60K messages... If you're sending out that many messages you'd probably want to be able to confirm the action, be able to log what messages were sent (so you know it's working and so you can track problems down if it goes berzerk), and possibly want to be able to restart a failed send from where it left off.
Have to say "bwa?" o_O to your preference of PHP over Perl. In syntax and semantics they're very similar languages... Myself, I like Perl fine. I don't use it for everything though.
My dislike for perl comes from a long history of abuse... actually, I started with perl and my first project was writing a content management system in it. I did that over a year and have since then extended and built upon it continously (this whole thing is five or six years old). The whole thing is one giant bloat of spaghetti code, and most other perl systems I've worked with (like this newsletter system I fought with recently) have been equally bloated spaghetti code monsters.
With perls whole "you can do a thing a thousand different ways" and it's tendency for code obfuscation I have a really hard time reading other peoples code. I do not have the same problem in PHP. I'll admit, PHP does have it's own set of problems, but I can do things much much quicker and in a much cleaner way than I can do in perl. Personal preference, I guess...
But `php -f mailer.php &` will return immediately because it's automatically forked into the background. Assuming that works through PHP, that is, heh.