Make WordPress Core

Opened 13 years ago

Closed 3 years ago

#14465 closed defect (bug) (maybelater)

Update Plugins Hangs while displaying 'updating'

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



Whenever I try to update a plugin the update plugins screen hangs indefinetly.

Example message while this is happening would be-

"The update process is starting. This process may take awhile on some hosts, so please be patient.

Enabling Maintenance mode…

Updating Plugin Link Library (1/1)"

The plugin ulitmately gets updated if I wait a minute or two but this page never refreshes.

I am running WP 3.0.1 but this happend on 3.0.0 as well.

My host is running
MySQL 5.0.90-community
PHP 5.2.13

and my browser is IE8.

Change History (16)

#1 @stevemagruder
13 years ago

  • Cc stevemagruder added

I am seeing the exact same problem as reported in both 3.0 and 3.0.1.

I am using Mozilla Firefox 3.6.8 and my host is running:

MySQL 5.0.90-community
PHP 5.2.13
Apache 2.2.15

#2 @venik4
13 years ago

  • Component changed from Plugins to Upgrade/Install
  • Version changed from 3.0 to 3.0.1

Same problem here with 3.0.1 using both Firefox and IE from two different computers. The plugins actually update, but the update scree never refreshes. The same happens when upgrading or reinstalling wordpress: the upgrade completed, but the screen doesn't refresh. Tried cleaning browser cache and cookies, deleting "upgrade" folder, removing ".maintenance" file, and manually upgrading wordpress. No fix so far. The issue started after upgrade to 3.0

#3 @lupinek7
13 years ago

  • Cc lupinek7 added

I have two separate Wordpress installs on the same hosting account – one is Wordpress 2.9 and the other is Wordpress 3.0. Everything works fine in older version whereas in 3.0 the issue appears.

#4 @shawnkhall
13 years ago

  • Cc shawnkhall added

I'm seeing the exact same behavior on dozens of WP sites hosted on Windows servers or with strict permissions on various Linux servers. I believe the problem is simply that "write" permission is permitted for the WP root, but modify, delete and change permissions are not permitted to the user account the service runs in. And frankly, that's the way it SHOULD be.

My preferred behavior would be to put the .maintenance file within the "uploads" folder, which is one directory that the user SHOULD have appropriate rights assigned, without requiring additional rights manipulation for the root of the site.

I would also prefer to have hooks into this specific function (and wp_maintenance()) in order to alter what exactly is printed during maintenance mode, instead of using a file (/wp-content/maintenance.php) that I have to play with in FTP each time.

I know that I could setup a default .maintenance file with an assignment of 0 to the value for $upgrading and remove rights for the webservice user to write to or delete it, which will effectively always bypass maintenance mode based on the existence of the file...but I would prefer to have both the maintenance mode abilities and the native security from proper file-system permissions.

#5 @stevemagruder
13 years ago

For those with strict permissions on Linux servers, what steps should be followed to work around the issue as reported in this bug?

#6 @shawnkhall
13 years ago

The easiest solution is to create a default ".maintenance" file with the following contents:
<?php $upgrading = 0; ?>

Then remove rights from the web user account to delete or modify the file (execute only). This will effectively bypass the ability for WP to use the "maintenance mode" functionality.

#7 @stevemagruder
13 years ago

It appears I only have access to set to read, write and execute rights. Does this mean I should have only execute rights for the owner? When I set it to read and execute (but not write), this workaround worked once, but then .maintenance got deleted.

#8 @shawnkhall
13 years ago

Some hosts require execute rights, others don't.

The bottom line is: you need to ensure that the rights of the web user do not permit editing or deleting the file. This may require changing group or user ownership or removing certain permissions from the web user. If your host provides rather lenient controls, you might consider changing ownership of the file to root, then removing all rights from it except read by everyone. This should effectively prevent the file from changing. Good luck!

#9 @dd32
12 years ago

  • Milestone changed from Awaiting Review to Future Release

#10 @jazzs3quence
11 years ago

The people who are having this issue: this issue may be resolved by defining some FTP (or other) rules in your wp-config.php

#12 @chriscct7
8 years ago

  • Version changed from 3.0.1 to 3.0

#13 @SergeyBiryukov
4 years ago

#47601 was marked as a duplicate.

#14 @angrywarrior
4 years ago

With the newest version of date 5.2.2. my WPMU systems started having this issue after running the core update and prior to that they been running like swiss clocks without any hitches for a very long time, (over two years).

I have created a short video screencast recording for you guys of the issue:
(Please turn on your sound on your pc to hear me talk and explain/show the issue).


Kind regards

This ticket was mentioned in Slack in #core-auto-updates by pbiron. View the logs.

3 years ago

#16 @helen
3 years ago

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

Hello everyone - I am going to close this ticket not because I don't believe this is happening, but because there aren't really a lot of details here to reproduce the exact circumstances that are causing this, and based on a relative lack of reports and activity my guess is that it's not solely a permissions issue, so there isn't really anything actionable at this point. The screencast link from the last comment is unfortunately not working so I don't have any new information to go on. If this does happen consistently for people, please do reopen this ticket or open a new one with as many environment details as possible.

Note: See TracTickets for help on using tickets.