Make WordPress Core

Opened 15 years ago

Closed 15 years ago

Last modified 9 years ago

#9275 closed defect (bug) (invalid)

Automatic Core Update feature not working if PHP is not CGI

Reported by: bloggersavvy's profile bloggersavvy Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.7
Component: Upgrade/Install Keywords:
Focuses: Cc:

Description

When using WP 2.7+ the automatic Core Update feature will not complete. Instead, after a long wait, browser is presented with a pop-up box asking what to do with (0kb) file named "update-core.php".

In order to get this working, the server has to be temporarily configured to run PHP as CGI, not as Apache Module (DSO).

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

Change History (9)

#1 follow-up: @sivel
15 years ago

The upgrade works fine for me when running php through mod_php in Apache.

Apache 2.2.9
PHP 5.2.6

All WordPress files are owned by the same user that Apache is running as.

#2 follow-up: @DD32
15 years ago

  • Keywords reporter-feedback added; 2nd-opinion removed

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.

#3 in reply to: ↑ 1 @bloggersavvy
15 years ago

Replying to sivel:

The upgrade works fine for me when running php through mod_php in Apache.

Apache 2.2.9
PHP 5.2.6

All WordPress files are owned by the same user that Apache is running as.

I'm on Apache 1.3.39 and PHP 5.2.5
I cannot upgrade yet as it would trash the video server (another PHP based site).
Interestingly, the video site has no issues with memory or time outs. (I even disabled the site to test for memory, etc. when trying to upgrade WP from WP 2.7 to 2.7.1).
This issue only began when I upgraded to WP 2.7. Prior to this (WP 2.4 and 2.5) I was testing auto update plugins for the core and the plugins themselves and everything worked smoothly. I removed them in WP 2.5.

#4 in reply to: ↑ 2 @bloggersavvy
15 years ago

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

#5 @scribu
15 years ago

  • Keywords reporter-feedback removed
  • Milestone changed from Unassigned to 2.8

#6 @DD32
15 years ago

Needless to say, these are outrageous numbers, so if the issue was time or memory requirements, I think they are ruled out.

Yep, That pretty much rules out timeouts and memory problems.

The plugin Upgrade/Install, only works if I first manually upload the new plugin files.

In other words, You're not using automatic upgrade at all.

Oh!... and if I leave PHP as CGI, here's an example error (in the front end: .... session_start() [function.session-start]: ... Permission denied

That points out what the problem is, When you're running php under apache, Its running as the Apache username, Now that you've moved to apache + cgi, Its running under a different username, and as such That plugin can no longer open the files it created as the other user

The problem seems to be here that either you dont have *any* transports available to you, Or, Whichever one you do have is having an issue with your server.

Can you tell me which transports are available, & Which is the current one?

You can try disabling the current one, and seeing if the upgrade will work via the next one it flicks onto.

I'm on Apache 1.3.39 and PHP 5.2.5 I cannot upgrade yet as it would trash the video server (another PHP based site)

Thats interesting, So.. WordPress is trying to upgrade the video site instead of itself?

I guess that means you're using FTP, When you connect via FTP, what path do you see? ie. /public_html/wordpress.site/ and /public_html/video.site/ or something different? Whats your ABSPATH (You can find that on the filesystem module page too)

#7 @sivel
15 years ago

  • Cc matt@… added

So as far as I can tell this does not seem to be a WordPress bug and there hasn't been a response in some time. Can we close this as invalid?

#8 @hakre
15 years ago

  • Resolution set to invalid
  • Status changed from new to closed

In my opinion I would assume that this report is bogus. The reporter seem to encounter a misconfiguration of his/her server and there get a timeout / overflow when trying to update via CGI. Infact the reporter states that wordpress works, it's the CGI mode that isn't.

since CGI and SAPI have different PHP-configurations it looks like that the server is simply not well configured in CGI mode.

If the reporter still encounters the problem and is able to reproduce it, he/she can feel free to reopen.

#9 @DrewAPicture
9 years ago

  • Milestone 2.8 deleted
Note: See TracTickets for help on using tickets.