Opened 14 years ago
Closed 4 years ago
#14465 closed defect (bug) (maybelater)
Update Plugins Hangs while displaying 'updating'
Reported by: | jamesfed | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.0 |
Component: | Upgrade/Install | Keywords: | |
Focuses: | Cc: |
Description
Hi,
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)
#2
@
14 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
@
14 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
@
14 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
@
14 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
@
14 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
@
14 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
@
14 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!
#10
@
12 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
http://codex.wordpress.org/Editing_wp-config.php#WordPress_Upgrade_Constants
#14
@
5 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:
https://www.screencast.com/t/wwFK1I23
(Please turn on your sound on your pc to hear me talk and explain/show the issue).
Thanks!
Kind regards
AngryWarrior
This ticket was mentioned in Slack in #core-auto-updates by pbiron. View the logs.
4 years ago
#16
@
4 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.
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