[wp-hackers] Future Posting Fix Request

Robert Deaton false.hopes at gmail.com
Sat Jul 22 08:33:19 GMT 2006


On 7/22/06, Computer Guru <computerguru at neosmart.net> 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....

Its not the blog owner that has to wait, though. It is an unsuspecting
end user, who can be hit with 20-60 second wait times. Just search the
WP support forums for problems with posting taking a long 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?
>
> 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?

I think you're lost again. Nothing about CGI involves cron, and not
all CGI installations have the problem (whereas the old code that Andy
had did have issues with all environments. So far, the only
environment that has been reported as broken is Apache with PHP as
CGI. I personally use lighttpd with PHP as a fast-cgi module with no
issue at all.


> 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...

On 7/22/06, Ryan Boren <ryan at boren.nu> wrote:
> disable_functions = proc_open , popen, disk_free_space, diskfreespace,
> set_time_limit, leak, tmpfile, exec, system, shell_exec, passthru

_All_ exec related functions are often blacklisted, it is too much of
a headache for managing shared servers leaving anything like this
open, the potential for exploit is far too high.

WordPress should remain free of anything that involves using any exec,
it is simply not even close to being reliable across platforms,
especially windows and shared hosts, which make up quite a bit of the
user base.

-- 
--Robert Deaton


More information about the wp-hackers mailing list