[wp-hackers] Future Posting Fix Request
ryan at boren.nu
Sat Jul 22 07:43:40 GMT 2006
Computer Guru wrote:
>> We spawn ours out-of-band so that the user doesn't have to wait for it
>> to complete. Others kick their pseudo-cron off from an image tag or
>> the like.
> OK, can't we fall-back to pseudo image tags, or something? Or even make them wait.... I mean, it's worth it for the CGI users if one visit near the time of the publication is 2 or 3 seconds longer than normal. It's just _one_ time (right?), and in exchange their future-publication works....
Processing pings can take a loooong time.
> So you can use it the way you already are, but if CGI is detected, fall back to this 'waiting way' and then from there to IFRAME.... foolproof, no?
We might end up doing an iframe fallback if no other approach pans out.
I would really like to narrow down which environments should be
blacklisted. Not all CGI environments misbehave.
> About the cron jobs though - it _is_ the default for all CGI installations, isn't it? With PHP compiled into Apache, it's not always the default, but AFAIK, all CGI installations have it stock, no?
cron is a *nix thing. We cannot rely on it being installed, running,
and in the shell path. If we could, all of the pseudo-cron
implementations hanging about wouldn't be necessary.
> And IIRC, we're not using any of those commands you listed as being "blacklisted" on hosts, and safe mode exec _should_ only escape all commands in the strings associated...
>>From the PHP docs:
>> With safe mode enabled, the command string is escaped with escapeshellcmd().
>> Thus, echo y | echo x becomes echo y \| echo x.
> Neither of these should inhibit a simple command like
> $ 0 1 * * 0,2,4,6 /usr/local/bin/php /home/user/wp/mycron.php >/dev/null
Yes, safe_mode breaks pipelining, which is no big deal in this case.
But if safe_mode_exec_dir is set, exec is pretty useless with safe_mode
More information about the wp-hackers