[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