[pmwiki-devel] Newsletter Throttling & Register Shutdown Function
Crisses
crisses at kinhost.org
Wed Nov 1 05:51:09 CST 2006
On Oct 31, 2006, at 9:23 PM, The Editor wrote:
> Finally, after much looking I discovered that the
> register_shutdown_function is a php function, not a pmwiki one. Read
> the documentation and am trying to make heads of it with limited
> success. From the looks of it, solving my needs might be as simple as
> adding a couple lines like this in the ZAP emailer function to begin
> the ZAPnews mail sending routine once the form is submitted, and the
> browser is moved on to the next page.
>
> if (field == maillist) { //in zapdata recipe
> register_shutdown_function('zapnews');
Make sure that matches the function. According to your function
definition it should be "ZAPnews".
> $m .= "Message sent to queue. "; // message returned to screen
> continue;
> }
>
> ZAPnews() { //in zapnews recipe...
>
function ZAPnews() {
sorry to be picky, but it certainly would throw an error
> blah, blah, blah
> sending newsletter code
> }
>
> or better yet:
>
> if (field == maillist) {
> $news="ZAPnewsl($_POST);";
> register_shutdown_function(create_function('',$news));
No -- you're not passing a function to register_shutdown_function.
Just a function name. If you need to pass parameters they are
additional parameters to register_shutdown_function as in:
register_shutdown_function("functionname", "parameter 1", "parameter
2");
> ignore_user_abort()
> $m .= "Message sent to queue. "; // message
> continue;
> }
>
> ZAPnews($formpost) {
function...
> blah, blah, blah
> sending newsletter code
> }
>
> (I wasn't sure the $_POST variables would be available in the
> registered (child?) function.
Yes it will. As long as you don't unset it I guess.
> The little create_function trick is
> supposed to allow you to pass stuff in to the registered function.
No --- you'd be passing the function, I think. And I don't think
that will work.
> One thread also recommended the ignore_user_abort() line, just in
> case.
Yep. But put it inside the called function (ZAPnews).
> But I also found these words:
>
> --QUOTED--
> Note that register_shutdown_function() does not work under Apache on
> Windows platforms. Your shutdown function will be called, but the
> connection will not close until the processing is complete. Zend
> tells me that this is due to a difference between Apache for *nix and
> Apache for Windows.
> --ENDQUOTE--
If you were going to ignore_user_abort() anyway, there's no difference.
> Lastly, I found another little snippet which some say might work
> better. It seems this would work by putting a markup on the page
> displayed after the newsletter form is submitted which produces output
> like:
>
> <img src="maillist.php" width="1" height="1" border="0"
> alt="" />
>
> on that page. This combined with the maillist.php script below. It
> has it's pro's and con's. The pro is it should work on any browser,
> with no change to zap. (Are the $_POST values still available on this
> second page?). Con is I'd have to add the markup on a second page...
No -- doing it this way you will not be passing any values to this
page. It would work if you have a email queue in file format on the
server. It will NOT work if you are expecting to pass current $_POST
information to the php file (other than cookie/session info??). You
can format the call to include $_GET vars... but they will be
viewable in the page source code.
<img src="maillist.php?info=thisvalue" width="1" height="1"
border="0" alt="" />
> --QUOTED--
> Various commenters have described how 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, but the solution I prefer
> is to put the background processing in a separate script which gets
> included as a transparent gif. The only caveat is, of course, if the
> user has images turned off then the script won't be called. Tested
> successfully with IE6, Firefox 0.8, and Opera 7.11
I have no idea if gifs are called by web spiders. I guess they are
for some, not for others. So, for flushing the backlog as if you
were running a cron job the gif trick is probably OK, but for
anything that must be run every time a page is accessed, it's not the
best way to do it.
> Anyway, to make a long story short, I'm a bit confused. Any
> suggestions as far as which approach to use? Or even if I'm
> understanding this correctly? If I can get it to work, this is going
> to be a very nice mailing list manager recipe for PmWiki. Thanks in
> advance!
Hope I helped.
Crisses
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-devel/attachments/20061101/09b01473/attachment-0001.html
More information about the pmwiki-devel
mailing list