[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