[wp-trac] Re: [WordPress Trac] #9275: Automatic Core Update feature
not working if PHP is not CGI
WordPress Trac
wp-trac at lists.automattic.com
Fri Mar 6 17:24:23 GMT 2009
#9275: Automatic Core Update feature not working if PHP is not CGI
--------------------------+-------------------------------------------------
Reporter: bloggersavvy | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Unassigned
Component: Upgrade | Version: 2.7
Severity: normal | Keywords: reporter-feedback
--------------------------+-------------------------------------------------
Comment(by bloggersavvy):
Replying to [comment:2 DD32]:
> > Instead, after a long wait, browser is presented with a pop-up box
asking what to do with (0kb) file named "update-core.php".
>
> Thats not an issue with the way PHP is installed, Rather it seems to be
an error elsewhere, Possibly could be due to memory requirements or time
required to decompress the upgrade file.
>
> Does The Plugin Upgade/Install work for you?
>
> > After upgrade, the server needs to be changed back to run PHP as DSO
(as errors will appear in admin and front end user interface if not).
> Thats an error in your server config, Theres no reason why running as a
CGI should cause problems, quite a lot of people run it as such. But
changing the way PHP is installed shouldn't be the solution here, You
might mearly need to change your PHP config to have a higher processing
time, or memory usage allowance.
Prior to temporarily changing PHP to run as CGI, I did do the following
myself...
Using htaccess to:
php_value max_execution_time 18000
php_value max_input_time 18000
(Does not resolve the issue.)
Changing php.ini to allow:
max_execution_time = 18000
max_input_time = 18000
memory_limit = 256M
(Does not resolve the issue).
Needless to say, these are outrageous numbers, so if the issue was time or
memory requirements, I think they are ruled out.
This solution (temporarily changing PHP as CGI) was arrived at by
professional Linux hosting administrative support (not me).
Of particular note is that I am able to duplicate this on 4 different
servers (but only if they are running PHP as Apache, from original
install). Servers that are running ('''from the onset''') as CGI don't
experience this issue.
The plugin Upgrade/Install, only works if I first '''manually''' upload
the new plugin files. Otherwise it does not work either. Could there be an
issue with the scripting? I do know from some other PHP programmers (who
advised me) that time outs can be coded into php scripts, to prevent them
from timing out - But I'm not a programmer.
But again, I'm not the expert here (you guys are). I'm pretty sure this is
not 100% server based.
Oh!... and if I leave PHP as CGI, here's an example error (in the front
end:
"Warning: session_start() [function.session-start]:
open(/tmp/sess_6bce16459f08511d06f278814110060e, O_RDWR) failed:
Permission denied (13) in /home/xxxxxxx/public_html/wp-content/plugins/wp-
referer.php on line 36"
I'm really looking forward to any help you can give!
Thanks again.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/9275#comment:4>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list