#34976 closed defect (bug) (fixed)
Plug ins fail to update after WP 4.4 installed
Reported by: | patdundee | Owned by: | dd32 |
---|---|---|---|
Milestone: | 4.4.1 | Priority: | normal |
Severity: | normal | Version: | 4.4 |
Component: | Filesystem API | Keywords: | |
Focuses: | Cc: |
Description
Having various servers all running Linux with latest PHP. These servers all have WordPress on and each WordPress site is always updated using ftp via the WP admin update
Permissions are all correct for ftp user and group togehter with all correct mod settings
I have even made the folders 777 to allow full access and also with all different users and groups with 777 permissions including (root, ftp, www etc)
In earlier versions of WP all plug in updates worked fine. This has only happened since WP 4.4
If i roll back to 4.3.1 all plugins update correctly but will not in 4.4 with the error everyone else is having. (Cannot create directory as it already exists)
I have to think this is an issue with how the update in WP 4.4 via ftp is completing the updates. It is obviously failing to remove the directory (Even with full permissions granted to everyone and trying all users and groups)
If one can roll back a version and the updates work but then move to the latest WP and they do not (Leaving all permissions the same) would this not be an issue with 4.4 not removing existing directory and files during the update.
The fact so many people are having this issue across various systems, together with everyone's plugin update working before the upgrade, then maybe this is omission of WP failing to remvoe relevant directories before updating.
Attachments (2)
Change History (105)
#2
follow-up:
↓ 32
@
9 years ago
- Component changed from General to Plugins
- Summary changed from Plug ins fail to update after WP 4.4 installed to Plugins fail to update after WP 4.4 installed
#3
@
9 years ago
- Component changed from Plugins to General
- Summary changed from Plugins fail to update after WP 4.4 installed to Plug ins fail to update after WP 4.4 installed
Can you provide specific details on how to reproduce the issue? Please remember, this is not a support forum so adding +1 or replaying with "me to0" is not helpful here.
#6
@
9 years ago
Some info on my systems for you
OS Ubuntu Linux 14.04.2
PHP Version 5.5.9-1ubuntu4.14
root directories set to ftpuser and ftpgroup (Have always been)
Updates only via wp-admin (via ftp)
Permissions correct for the above (as always been)
Have tried 0777 on all folders leading down to the plugins (and including the plug in folders)
Have also tried giving permissions to www and root and setting them as the users and group
Still unable to update as it fails to remove existing directory
Resest everything back to its original state
Downgrade to 4.3.1
All plugins and everything else updates fine
#9
@
9 years ago
+1 experiencing the same issue
OS : CENTOS 6.7 x86_64 virtuozzo
PHP : 5.4.37
Have tried 0777 on all folders leading down to the plugins, including the plugin folders, without success. Still unable to update as it fails to remove existing directory. So it is NOT a permissions issue!
Always updating plugins from either WP administration plugins and/or update pages.
Downgrade to 4.3.1 and all plugins and everything else updates fine.
I am using pure-ftpd-1.0.42-2.cp1150.x86_64 as FTP server.
For PHP, FTP support is enabled, and I have experienced this issue after upgrading WP from 4.3.1 to 4.4, I do not know if this issue appears when you perform a clean install of WP 4.4
#10
@
9 years ago
@kioub We know you are experiencing the same issue. Thats why this is a ticket and not a support forum. Please only post helpful information.
#11
in reply to:
↑ 1
;
follow-up:
↓ 12
@
9 years ago
Changing ownership of the plugin directory (recursively) to the webserver user makes no difference. None of the files for the plugin being updated are removed, so therefore, writing the new files fails.
#13
@
9 years ago
I am having the same issue. I think it might have something to do with my PHP handler, which is DSO.
Steps to reproduce:
1) visit /wp-admin/update-core.php
2) select plugin(s) to update
3) enter FTP Password (Hostname and Username already filled in)
4) click "Proceed"
5) get the error seen below:
I also have a site where after failing to update 4 plugins at once (all just like this), it finishes the operation and says "All updates have been completed." but leaves the .maintenance file on the server.
I have all the folder permissions set to allow correct permissions to the same user that I enter for the FTP info.
#14
follow-ups:
↓ 15
↓ 16
↓ 33
@
9 years ago
Can everyone please confirm the exact error message which you're running into? It's not clear from reading this thread.
If it's the failure to delete old plugin error, are the files still on disk untouched? Are you using ftp?
#15
in reply to:
↑ 14
@
9 years ago
Replying to dd32:
Can everyone please confirm the exact error message which you're running into? It's not clear from reading this thread.
If it's the failure to delete old plugin error, are the files still on disk untouched? Are you using ftp?
The update process is starting. This process may take a while on some hosts, so please be patient.
Updating Plugin Yet Another Stars Rating (1/1)
Downloading update from https://downloads.wordpress.org/plugin/yet-another-stars-rating.1.0.7.zip…
Unpacking the update…
Installing the latest version…
Removing the old version of the plugin…
Plugin update failed.
An error occurred while updating Yet Another Stars Rating: Could not create directory. /wp-content/plugins/yet-another-stars-rating/
That is the text of the process. In fact, while watching in terminal, it looks like no files from the old version have been removed.
#16
in reply to:
↑ 14
@
9 years ago
Replying to dd32:
Can everyone please confirm the exact error message which you're running into? It's not clear from reading this thread.
If it's the failure to delete old plugin error, are the files still on disk untouched? Are you using ftp?
Did my screenshot above not post? It has the exact error message I am getting, which is the same as what verdonv posted. It doesn't look like any files from the old version of the plugin to be updated are touched. Also, yes my sites are using FTP, which they have to since my PHP handler is DSO.
#17
follow-up:
↓ 18
@
9 years ago
Additional information: Assuming it's FTP-related, Are you running PHP with the FTP Extension enabled?
If It's FTP related, it could be #28013 or #33432 - could try reverting those changes in your install and see if that helps
I'm unable to duplicate any issues under several fresh 4.4 installs using the FTP Extension, FTP Sockets (compat FTP library) or the Direct handlers. Unfortunately that's all the debugging I can do until next week, if anyone experiencing issues could dive into the upgrader classes and debug it, it'd be appreciated.
#18
in reply to:
↑ 17
@
9 years ago
I think so, at least from phpinfo,
FTP support enabled
I'll try looking at the items quoted this afternoon.
thanks!
Replying to dd32:
Additional information: Assuming it's FTP-related, Are you running PHP with the FTP Extension enabled?
If It's FTP related, it could be #28013 or #33432 - could try reverting those changes in your install and see if that helps
I'm unable to duplicate any issues under several fresh 4.4 installs using the FTP Extension, FTP Sockets (compat FTP library) or the Direct handlers. Unfortunately that's all the debugging I can do until next week, if anyone experiencing issues could dive into the upgrader classes and debug it, it'd be appreciated.
#19
follow-up:
↓ 20
@
9 years ago
I saw this happen when uploading a brand new plugin that was not installed. The error message reported that I was trying to upload an existing plugin.
#20
in reply to:
↑ 19
@
9 years ago
Replying to mordauk:
I saw this happen when uploading a brand new plugin that was not installed. The error message reported that I was trying to upload an existing plugin.
I'm not having any problem installing new plugins. I also tried installing a new one, activating it, deactivating, deleting/uninstalling, and then installing again... all with no issue. I would suspect that you are experiencing something not directly related.
#21
follow-up:
↓ 22
@
9 years ago
I am unable to replicate this but can come close by using different ftp accounts. Could anyone that has access to SSH and is having the issue please run the following commands from WP root and provide a screenshot?
cd wp-contents/plugins && ls -al
or
cd wp-contents/themes && ls -al
Thanks
#22
in reply to:
↑ 21
;
follow-up:
↓ 23
@
9 years ago
[root@xxx public_html]# cd wp-content/plugins && ls -al
total 88
drwxr-xr-x. 21 webshelp webshelp 4096 Dec 10 13:47 .
drwxr-xr-x. 7 webshelp webshelp 4096 Jun 23 10:29 ..
drwxr-xr-x. 2 webshelp webshelp 4096 Aug 1 2014 accessible-dropdown-menus
drwxr-xr-x. 5 webshelp webshelp 4096 Aug 26 08:19 active-directory-integration
drwxr-xr-x. 4 webshelp webshelp 4096 Oct 14 10:00 akismet
drwxr-xr-x. 6 webshelp webshelp 4096 Dec 9 07:49 bulletproof-security
drwxr-xr-x. 6 webshelp webshelp 4096 Nov 24 07:57 capability-manager-enhanced
drwxr-xr-x. 7 webshelp webshelp 4096 Nov 24 07:57 contact-form-7
drwxr-xr-x. 11 webshelp webshelp 4096 Nov 17 08:24 contact-form-7-to-database-extension
drwxr-xr-x. 6 webshelp webshelp 4096 Nov 4 07:42 email-users
-rw-r--r--. 1 webshelp webshelp 30 Aug 1 2014 index.php
drwxr-xr-x. 5 webshelp webshelp 4096 Nov 18 11:16 iwp-client
drwxr-xr-x. 6 webshelp webshelp 4096 Aug 25 2014 mce-table-buttons
drwxr-xr-x. 7 webshelp webshelp 4096 Aug 1 2014 q-and-a
drwxr-xr-x. 4 webshelp webshelp 4096 Dec 19 2014 really-simple-captcha
drwxr-xr-x. 7 webshelp webshelp 4096 Nov 16 08:05 user-role-editor
drwxr-xr-x. 2 webshelp webshelp 4096 Nov 13 08:10 user-switching
drwxr-xr-x. 2 webshelp webshelp 4096 Oct 21 15:31 wp-fail2ban
drwxr-xr-x. 4 webshelp webshelp 4096 Mar 18 2015 wp-optimize
drwxr-xr-x. 3 webshelp webshelp 4096 Nov 26 08:18 wp-postratings
drwxr-xr-x. 4 webshelp webshelp 4096 Oct 13 07:43 wp-super-cache
drwxr-xr-x. 7 webshelp webshelp 4096 Dec 1 10:03 yet-another-stars-rating
[root@xxx plugins]# cd ../../
[root@xxx public_html]# cd wp-content/themes && ls -al
total 20
drwxr-xr-x. 4 webshelp webshelp 4096 Dec 9 07:49 .
drwxr-xr-x. 7 webshelp webshelp 4096 Jun 23 10:29 ..
drwxr-xr-x. 2 webshelp webshelp 4096 Apr 8 2015 help-twentyfourteen-child
-rw-r--r--. 1 webshelp webshelp 30 Aug 1 2014 index.php
drwxr-xr-x. 9 webshelp webshelp 4096 Dec 9 07:49 twentyfourteen
#23
in reply to:
↑ 22
;
follow-up:
↓ 24
@
9 years ago
Replying to verdonv:
[root@xxx public_html]# cd wp-content/plugins && ls -al
total 88
drwxr-xr-x. 21 webshelp webshelp 4096 Dec 10 13:47 .
drwxr-xr-x. 7 webshelp webshelp 4096 Jun 23 10:29 ..
drwxr-xr-x. 2 webshelp webshelp 4096 Aug 1 2014 accessible-dropdown-menus
drwxr-xr-x. 5 webshelp webshelp 4096 Aug 26 08:19 active-directory-integration
drwxr-xr-x. 4 webshelp webshelp 4096 Oct 14 10:00 akismet
drwxr-xr-x. 6 webshelp webshelp 4096 Dec 9 07:49 bulletproof-security
drwxr-xr-x. 6 webshelp webshelp 4096 Nov 24 07:57 capability-manager-enhanced
drwxr-xr-x. 7 webshelp webshelp 4096 Nov 24 07:57 contact-form-7
drwxr-xr-x. 11 webshelp webshelp 4096 Nov 17 08:24 contact-form-7-to-database-extension
drwxr-xr-x. 6 webshelp webshelp 4096 Nov 4 07:42 email-users
-rw-r--r--. 1 webshelp webshelp 30 Aug 1 2014 index.php
drwxr-xr-x. 5 webshelp webshelp 4096 Nov 18 11:16 iwp-client
drwxr-xr-x. 6 webshelp webshelp 4096 Aug 25 2014 mce-table-buttons
drwxr-xr-x. 7 webshelp webshelp 4096 Aug 1 2014 q-and-a
drwxr-xr-x. 4 webshelp webshelp 4096 Dec 19 2014 really-simple-captcha
drwxr-xr-x. 7 webshelp webshelp 4096 Nov 16 08:05 user-role-editor
drwxr-xr-x. 2 webshelp webshelp 4096 Nov 13 08:10 user-switching
drwxr-xr-x. 2 webshelp webshelp 4096 Oct 21 15:31 wp-fail2ban
drwxr-xr-x. 4 webshelp webshelp 4096 Mar 18 2015 wp-optimize
drwxr-xr-x. 3 webshelp webshelp 4096 Nov 26 08:18 wp-postratings
drwxr-xr-x. 4 webshelp webshelp 4096 Oct 13 07:43 wp-super-cache
drwxr-xr-x. 7 webshelp webshelp 4096 Dec 1 10:03 yet-another-stars-rating
[root@xxx plugins]# cd ../../
[root@xxx public_html]# cd wp-content/themes && ls -al
total 20
drwxr-xr-x. 4 webshelp webshelp 4096 Dec 9 07:49 .
drwxr-xr-x. 7 webshelp webshelp 4096 Jun 23 10:29 ..
drwxr-xr-x. 2 webshelp webshelp 4096 Apr 8 2015 help-twentyfourteen-child
-rw-r--r--. 1 webshelp webshelp 30 Aug 1 2014 index.php
drwxr-xr-x. 9 webshelp webshelp 4096 Dec 9 07:49 twentyfourteen
I am assuming you are using "webshelp" as the FTP user when updating?
#24
in reply to:
↑ 23
@
9 years ago
Replying to justingreerbbi:
Replying to verdonv:
[root@xxx public_html]# cd wp-content/plugins && ls -al
total 88
I am assuming you are using "webshelp" as the FTP user when updating?
That's correct
#25
@
9 years ago
In Addition to my original info and as requested her are two of the plugin errors all the others are the same but obviously different names
Using PURE-FTPD also on all servers
The update process is starting. This process may take a while on some hosts, so please be patient.
Enabling Maintenance mode…
Updating Plugin Quform (1/2)
Downloading update from http://www.themecatcher.net/iphorm-form-builder/api/update.php?v=1.7.5&l=c5f2362a8d8797a3b09dd10019580208d014fd2d0e240a7b086323e98177838f&s=http%3A%2F%2Fwww.derbyshireweddingevents.co.uk…
Unpacking the update…
Installing the latest version…
Removing the old version of the plugin…
Plugin update failed.
An error occurred while updating Quform: Could not create directory. /www1/derbyshireweddingevents.co.uk/new/wp-content/plugins/iphorm-form-builder/
Updating Plugin Yoast SEO (2/2)
Downloading update from https://downloads.wordpress.org/plugin/wordpress-seo.3.0.6.zip…
Unpacking the update…
Installing the latest version…
Removing the old version of the plugin…
Plugin update failed.
An error occurred while updating Yoast SEO: Could not create directory. /www1/derbyshireweddingevents.co.uk/new/wp-content/plugins/wordpress-seo/
All updates have been completed.
#26
@
9 years ago
As I control these servers direct, then, if it helps I can allow access to one of the servers direct through webmin and also admin access to two of the sites (which are on the same server) for tech support to investigate first hand. It may be that the tech guys can spot something I am missing (which is not hard to to lol ) on an actual server that is giving these errors.
Both updated to 4.4 no issue but had plug in issue
One site has been rolled back to Wp 4.3.1 after 4.4 update
Other site is on WP 4.4
Both sites have also got the same theme version running and of course are on the same server.
You will be able to see 4.3.1 updates plugins fine
The other will error for you.
Please email me direct if this is of assistance in any way
P
#27
@
9 years ago
In interest of completeness, I am also using PURE-FTPD (and it's virtual users) mechanism.
#28
@
9 years ago
I have discovered that I can delete the existing plugin/theme and it removes the folder. I can then install the plugin/theme without issue. However when trying to upgrade a currently installed plugin/theme causes the error mentioned above.
#29
follow-up:
↓ 30
@
9 years ago
@mnewberry
You can always update plugins that way, but it is cumbersome and time consuming when you have several sites with all different plugins :)
#30
in reply to:
↑ 29
@
9 years ago
Replying to patdundee:
@mnewberry
You can always update plugins that way, but it is cumbersome and time consuming when you have several sites with all different plugins :)
Depending on the plugin too, I'd be worried about losing settings.
#31
@
9 years ago
@verdonv
Thats not a problem, most settings are saved to the database, though not all in some cases.
Just download the plugin folder with FTP, rename it locally and save it.
To be safe, back up database.
Remove plugin from the live site.
Upload/or Install new plugin version.
If settings are lost, just remove the new updated plug in from live server.
Rename original back up on local system.
Upload original back to server.
Same process really as you would do before a WP update
#32
in reply to:
↑ 2
;
follow-up:
↓ 36
@
9 years ago
Replying to SergeyBiryukov:
@SergeyBiryukov
Hi
Can you clean this ticket up for me to get rid of some of the posts that are not needed (including any of mine) so we can keep it clean.
Thanks
P
#33
in reply to:
↑ 14
;
follow-up:
↓ 34
@
9 years ago
Replying to dd32:
Can everyone please confirm the exact error message which you're running into? It's not clear from reading this thread.
If it's the failure to delete old plugin error, are the files still on disk untouched? Are you using ftp?
My server is set up with pureftpd and I get the following when trying to upgrade anything after upgrading to 4.4
The update process is starting. This process may take a while on some hosts, so please be patient.
Enabling Maintenance mode…
Updating Plugin Jetpack by WordPress.com (1/1)
Downloading update from https://downloads.wordpress.org/plugin/jetpack.3.8.1.zip…
Unpacking the update…
Installing the latest version…
Removing the old version of the plugin…
Plugin update failed.
An error occurred while updating Jetpack by WordPress.com: Could not create directory. /www.alansitsolutions.com/wp-content/plugins/jetpack/
All updates have been completed.
#34
in reply to:
↑ 33
@
9 years ago
Replying to adstainer:
Replying to dd32:
Can everyone please confirm the exact error message which you're running into? It's not clear from reading this thread.
If it's the failure to delete old plugin error, are the files still on disk untouched? Are you using ftp?
My server is set up with pureftpd and I get the following when trying to upgrade anything after upgrading to 4.4
The update process is starting. This process may take a while on some hosts, so please be patient.
Enabling Maintenance mode…
Updating Plugin Jetpack by WordPress.com (1/1)
Downloading update from https://downloads.wordpress.org/plugin/jetpack.3.8.1.zip…
Unpacking the update…
Installing the latest version…
Removing the old version of the plugin…
Plugin update failed.
An error occurred while updating Jetpack by WordPress.com: Could not create directory. /www.alansitsolutions.com/wp-content/plugins/jetpack/
All updates have been completed.
@adstainer That is the same as everyone else and is the reason I started this ticket
#36
in reply to:
↑ 32
@
9 years ago
Replying to patdundee:
Can you clean this ticket up for me to get rid of some of the posts that are not needed (including any of mine) so we can keep it clean.
It's fine, we don't generally delete comments in Trac like we might do on support forums, as they all contribute to the discussion in some way, unless it's spam.
This ticket was mentioned in Slack in #core by stephenharris. View the logs.
9 years ago
#40
follow-up:
↓ 42
@
9 years ago
I've been able to narrow down the source of the problem for this on my machine in particular (see this WordPress support thread). Not sure if this is the same for everyone, but hopefully it's helpful:
In wp-admin/includes/class-wp-uploader.php, lines 531-535:
//Create destination if needed if ( ! $wp_filesystem->exists( $remote_destination ) ) { if ( ! $wp_filesystem->mkdir( $remote_destination, FS_CHMOD_DIR ) ) { return new WP_Error( 'mkdir_failed_destination', $this->strings['mkdir_failed'], $remote_destination ); } }
The exists call is returning false when I try to update a plugin. This is wrong. I am able to see the directory referred to by $remote_destination in my OS shell, and it obviously does exist because the failure occurs on the mkdir call—it is unable to make the directory because it already exists.
Digging deeper, in wp-admin/includes/class-wp-filesystem-ftpext.php, lines 329-338:
public function exists( $file ) { $path = dirname( $file ); $filename = basename( $file ); $file_list = @ftp_nlist( $this->link, '-a ' . $path ); if ( $file_list ) { $file_list = array_map( 'basename', $file_list ); } return $file_list && in_array( $filename, $file_list ); }
If I add the following line just before the return statement...
error_log(debug_backtrace()[1]['function'] . ": \npath: $path\nfilename: $filename\nfile list:\n" . print_r($file_list, true) . "\n");
... I see this output in the relevant section of debug.log ...
[11-Dec-2015 18:42:19 UTC] install_package: path: <the expected path> filename: <the expected filename> file list: Array ( )
The file list is empty! It should not be. What's going on here?
#41
@
9 years ago
Similar issue as everyone else, FTP within WordPress 4.4 is not working. Some details below.
FreeBSD 10.2-RELEASE (OS)
apache24-2.4.16_1
php56-5.6.14 (and associated supporting libraries/modules, all 5.6.14)
mysql55-client-5.5.44_1
mysql55-server-5.5.44
WordPress error upon attempted theme installation (theme below is an example):
Could not copy file. /data/www/mmfa/wp-content/themes/sweetheat/404.php
Whenever I try to install a theme, plugin or even re-install 4.4 from the Wordpress dashboard I get the 'Could not copy file.' error; this was working fine under WordPress 4.3.1; same supporting applications as above, filesystem permissions have not been modified from when they were working (they are 775).
Apache24 keeps recording the following in my error log (/var/log/mmfa/error.log) everytime Wordpress tries to call it's FTP function:
PHP Warning: Illegal string offset 'name' in /data/www/mmfa/wp-admin/includes/class-ftp.php on line 730, referer: http://www.mmfa.lan/wp-admin/update.php?action=install-theme&theme=sweetheat&_wpnonce=b60d7920e4
Looks like something is borked in ../wp-admin/includes/class-ftp.php after the 4.4 upgrade, but I'm not a PHP wizard so I can't say what.
Earlier today I was trying to get support through the main wordpress support site, https://wordpress.org/support/topic/ftp-not-working-wordpress-44?replies=10#post-7769293
Thanks.
#42
in reply to:
↑ 40
;
follow-ups:
↓ 43
↓ 45
↓ 46
@
9 years ago
Replying to ralbatross:
For what it's worth, removing the '-a' flag from the ftp_nlist call in wp-admin/includes/class-wp-filesystem-ftpext.php line 333 seems to solve this issue for me.
#43
in reply to:
↑ 42
;
follow-up:
↓ 44
@
9 years ago
That seemed to work for me too. I could only test one site until later tonight, but worked on that one.
Replying to ralbatross:
Replying to ralbatross:
For what it's worth, removing the '-a' flag from the ftp_nlist call in wp-admin/includes/class-wp-filesystem-ftpext.php line 333 seems to solve this issue for me.
#44
in reply to:
↑ 43
@
9 years ago
This is probably not a good ultimate solution as there may be code that relies on the exists function being able to detect hidden files.
Replying to verdonv:
That seemed to work for me too. I could only test one site until later tonight, but worked on that one.
Replying to ralbatross:
Replying to ralbatross:
For what it's worth, removing the '-a' flag from the ftp_nlist call in wp-admin/includes/class-wp-filesystem-ftpext.php line 333 seems to solve this issue for me.
#45
in reply to:
↑ 42
@
9 years ago
Replying to ralbatross:
Replying to ralbatross:
For what it's worth, removing the '-a' flag from the ftp_nlist call in wp-admin/includes/class-wp-filesystem-ftpext.php line 333 seems to solve this issue for me.
I tried the above, it didn't work for me, but I'm not entirely surprised as my error log is pointing to a different variable and called file.
#46
in reply to:
↑ 42
;
follow-up:
↓ 47
@
9 years ago
It worked for me also! Thanks a million. What the -a flag does actually?
Replying to ralbatross:
Replying to ralbatross:
For what it's worth, removing the '-a' flag from the ftp_nlist call in wp-admin/includes/class-wp-filesystem-ftpext.php line 333 seems to solve this issue for me.
#47
in reply to:
↑ 46
@
9 years ago
I believe it's similar to the -a flag on the ls command, which lists hidden files in addition to regular files. Apparently, however, the -a flag is not supported by all FTP implementations.
Replying to kioub:
It worked for me also! Thanks a million. What the -a flag does actually?
Replying to ralbatross:
Replying to ralbatross:
For what it's worth, removing the '-a' flag from the ftp_nlist call in wp-admin/includes/class-wp-filesystem-ftpext.php line 333 seems to solve this issue for me.
#50
follow-ups:
↓ 52
↓ 54
@
9 years ago
Okay, think I see the problem here. Stems from [34733].
The code changed from using ftp_rawlist() to ftp_nlist(). These execute the LIST or NLST commands, respectively. They both list the contents of the directory.
Historically, LIST has returned a wide variety of formats, and parsing those programmatically can be a pain. NLST returns a somewhat more standard format, and is intended to only give the list of filenames in a directory. Different FTP servers will all have different implementations.
It appears that in at least some of these cases, your servers don't support the -a argument (or perhaps any arguments) being passed to NLST. So the normal practice of sending NLST -a to get all files (including hidden ones that may have a period at the beginning of their name) does not work, while LIST -a worked just fine.
Not really seeing a solution except to switch back to ftp_rawlist(). It didn't have these problems in the past. It did have other problems, but maybe those can be solved without ftp_nlist().
Related: #28013
#51
@
9 years ago
@ralbatross
Hi
That also worked on my systems to. Many thanks.
Though I do agree it is probably not the best idea in case other items may use this.
Hopefully WP will come up with a fix for the issue. In the meantime a nice temp fix
Many thanks
#52
in reply to:
↑ 50
@
9 years ago
OK, for what is worth, for my FTP server (pure-ftpd-1.0.42-2.cp1150.x86_64) I can confirm that what is described is the exact case, I provide the output for LIST and NLIST commands when used with and without the -a flag.
LIST
ftp> ls 229 Extended Passive mode OK (|||44948|) 150 Accepted data connection drwxr-x--- 6 scg 99 4096 Dec 11 17:32 . drwx--x--x 15 scg scg 4096 Dec 11 17:27 .. -rw-rw-rw- 1 scg scg 9648 Dec 11 01:05 .htaccess drwxr-xr-x 2 scg scg 4096 Dec 8 05:53 cgi-bin -rw-r--r-- 1 scg scg 1150 Dec 11 05:29 favicon.ico -rw-r--r-- 1 scg scg 418 Dec 8 06:41 index.php -rw-r--r-- 1 scg scg 19930 Dec 8 06:41 license.txt -rw-r--r-- 1 scg scg 7358 Dec 9 09:44 readme.html -rw-r--r-- 1 scg scg 5035 Dec 9 09:44 wp-activate.php drwxr-xr-x 9 scg scg 4096 Dec 8 06:41 wp-admin -rw-r--r-- 1 scg scg 271 Dec 8 06:41 wp-blog-header.php -rw-r--r-- 1 scg scg 1369 Dec 9 09:44 wp-comments-post.php -rw-r--r-- 1 scg scg 2764 Dec 9 09:44 wp-config-sample.php -rw-r--r-- 1 scg scg 2867 Dec 11 01:06 wp-config.php drwxr-xr-x 8 scg scg 4096 Dec 9 12:06 wp-content -rw-r--r-- 1 scg scg 3286 Dec 8 06:41 wp-cron.php drwxr-xr-x 16 scg scg 4096 Dec 9 09:44 wp-includes -rw-r--r-- 1 scg scg 2380 Dec 8 06:41 wp-links-opml.php -rw-r--r-- 1 scg scg 3316 Dec 9 09:44 wp-load.php -rw-r--r-- 1 scg scg 33710 Dec 9 09:44 wp-login.php -rw-r--r-- 1 scg scg 7887 Dec 9 09:44 wp-mail.php -rw-r--r-- 1 scg scg 13021 Dec 9 09:44 wp-settings.php -rw-r--r-- 1 scg scg 28594 Dec 9 09:44 wp-signup.php -rw-r--r-- 1 scg scg 4035 Dec 8 06:41 wp-trackback.php -rw-r--r-- 1 scg scg 3061 Dec 9 09:44 xmlrpc.php 226-Options: -a -l 226 25 matches total
LIST -a
ftp> ls -a 229 Extended Passive mode OK (|||43334|) 150 Accepted data connection drwxr-x--- 6 scg 99 4096 Dec 11 17:32 . drwx--x--x 15 scg scg 4096 Dec 11 17:27 .. -rw-rw-rw- 1 scg scg 9648 Dec 11 01:05 .htaccess drwxr-xr-x 2 scg scg 4096 Dec 8 05:53 cgi-bin -rw-r--r-- 1 scg scg 1150 Dec 11 05:29 favicon.ico -rw-r--r-- 1 scg scg 418 Dec 8 06:41 index.php -rw-r--r-- 1 scg scg 19930 Dec 8 06:41 license.txt -rw-r--r-- 1 scg scg 7358 Dec 9 09:44 readme.html -rw-r--r-- 1 scg scg 5035 Dec 9 09:44 wp-activate.php drwxr-xr-x 9 scg scg 4096 Dec 8 06:41 wp-admin -rw-r--r-- 1 scg scg 271 Dec 8 06:41 wp-blog-header.php -rw-r--r-- 1 scg scg 1369 Dec 9 09:44 wp-comments-post.php -rw-r--r-- 1 scg scg 2764 Dec 9 09:44 wp-config-sample.php -rw-r--r-- 1 scg scg 2867 Dec 11 01:06 wp-config.php drwxr-xr-x 8 scg scg 4096 Dec 9 12:06 wp-content -rw-r--r-- 1 scg scg 3286 Dec 8 06:41 wp-cron.php drwxr-xr-x 16 scg scg 4096 Dec 9 09:44 wp-includes -rw-r--r-- 1 scg scg 2380 Dec 8 06:41 wp-links-opml.php -rw-r--r-- 1 scg scg 3316 Dec 9 09:44 wp-load.php -rw-r--r-- 1 scg scg 33710 Dec 9 09:44 wp-login.php -rw-r--r-- 1 scg scg 7887 Dec 9 09:44 wp-mail.php -rw-r--r-- 1 scg scg 13021 Dec 9 09:44 wp-settings.php -rw-r--r-- 1 scg scg 28594 Dec 9 09:44 wp-signup.php -rw-r--r-- 1 scg scg 4035 Dec 8 06:41 wp-trackback.php -rw-r--r-- 1 scg scg 3061 Dec 9 09:44 xmlrpc.php 226-Options: -a -l 226 25 matches total
NLIST
ftp> nlist 229 Extended Passive mode OK (|||39058|) 150 Accepted data connection . .. .htaccess cgi-bin favicon.ico index.php license.txt readme.html wp-activate.php wp-admin wp-blog-header.php wp-comments-post.php wp-config-sample.php wp-config.php wp-content wp-cron.php wp-includes wp-links-opml.php wp-load.php wp-login.php wp-mail.php wp-settings.php wp-signup.php wp-trackback.php xmlrpc.php 226-Options: -a 226 25 matches total
NLIST -a
ftp> nlist -a 229 Extended Passive mode OK (|||39297|) 150 Accepted data connection 226-Options: -a 226 0 matches total
As you can see the FTP server uses the -a flag internally regardless if I use it or not. That's why it returns all files (including the hidden ones) all the time. Although the -a flag gets ignored for the LIST command it results in a false (empty) result for the NLIST command.
Replying to Otto42:
Okay, think I see the problem here. Stems from [34733].
The code changed from using ftp_rawlist() to ftp_nlist(). These execute the LIST or NLST commands, respectively. They both list the contents of the directory.
Historically, LIST has returned a wide variety of formats, and parsing those programmatically can be a pain. NLST returns a somewhat more standard format, and is intended to only give the list of filenames in a directory. Different FTP servers will all have different implementations.
It appears that in at least some of these cases, your servers don't support the -a argument (or perhaps any arguments) being passed to NLST. So the normal practice of sending NLST -a to get all files (including hidden ones that may have a period at the beginning of their name) does not work, while LIST -a worked just fine.
Not really seeing a solution except to switch back to ftp_rawlist(). It didn't have these problems in the past. It did have other problems, but maybe those can be solved without ftp_nlist().
Related: #28013
#53
@
9 years ago
Since ftp_rawlist() has issues in the past but worked and ftp_nlist() fixes but does not play nice with some server config, maybe we create a fallback.
Hear my case... exists() is a method to check on information WP already has. A double check so to speak. Would it make sense to run ftp_nlist() and if FALSE just double check with ftp_rawlist()? The double check should never really happen to often and would benefit both issues of past and present.
#54
in reply to:
↑ 50
;
follow-up:
↓ 55
@
9 years ago
Replying to Otto42:
Okay, think I see the problem here. Stems from [34733].
Well but that does not explain why reverting to 4.3.1 makes it work again because
Not really seeing a solution except to switch back to ftp_rawlist().
does not apply to 4.3.1. ftp_nlist() has already been used in WP 4.3.1
Version 4.3.1
<?php public function exists($file) { $list = @ftp_nlist($this->link, $file); if ( empty( $list ) && $this->is_dir( $file ) ) { return true; // File is an empty directory. } return !empty($list); //empty list = no file, so invert. }
Version 4.4
<?php public function exists( $file ) { $path = dirname( $file ); $filename = basename( $file ); $file_list = @ftp_nlist( $this->link, '-a ' . $path ); if ( $file_list ) { $file_list = array_map( 'basename', $file_list ); } return $file_list && in_array( $filename, $file_list ); }
The question is why 4.4 is using the -a option at all. Do we need to check for hidden directories?
#55
in reply to:
↑ 54
@
9 years ago
Replying to mensmaximus:
Well but that does not explain why reverting to 4.3.1 makes it work again because
There has been more than one change to that file since 4.3.1.
Switching to rawlist with the -a option happened in [33648]. The problem came when it was switched back to nlist and the -a flag was kept.
#56
follow-up:
↓ 58
@
9 years ago
I tried the removing the -a flag and it appeared to work. There was no error message this time, however it is still stuck in maintenance mode.
#57
follow-up:
↓ 59
@
9 years ago
Yes, removing the -a is not a perfect solution, because it does need to see hidden files, such as the .maintenance file. If your FTP server assumes -a, then that would work, but not all servers will do that by default.
#58
in reply to:
↑ 56
;
follow-up:
↓ 72
@
9 years ago
Replying to adstainer:
I tried the removing the -a flag and it appeared to work. There was no error message this time, however it is still stuck in maintenance mode.
Was it already in maintenance mode before you tried the update? Deleting the .maintenance file should get you out of maintenance mode.
Like you, I removed the -a flag and I have successfully updated two plugins plus two themes. But presumably because I was not in maintenance mode when I started I am not stuck.
My configuration:
cPanel Version 11.52.1 (build 2)
Apache Version 2.2.27
PHP Version 5.4.27
MySQL Version 5.5.46-cll
Architecture x86_64
#59
in reply to:
↑ 57
;
follow-up:
↓ 60
@
9 years ago
Replying to Otto42:
Yes, removing the -a is not a perfect solution, because it does need to see hidden files, such as the .maintenance file. If your FTP server assumes -a, then that would work, but not all servers will do that by default.
Can you list even one FTP server whose NLST
verb does NOT return all files, thus requiring the "-a
" option? Can you even list one FTP server whose NLST
verb even does anything when passed any option?
According to RFC1123, section 4.1.2.7, the NLST
verb's response MUST contain only a simple list of legal pathnames,
- dotfiles are legal pathnames, even if there's a semantic connotation that they are "hidden" by some programs by default. Any FTP server whose NLST
verb does not return all legal pathnames, which would include dotfiles, is breaking the specification set forth by the RFC.
Because of this, I suggest that the correct fix to this bug is to use ftp_nlist()
and remove the "-a
" option, as proposed by @ralbatross in comment #42 above.
#60
in reply to:
↑ 59
;
follow-up:
↓ 62
@
9 years ago
Replying to dossy:
Can you list even one FTP server...
ProFTPd actually has this as a configurable setting:
http://www.proftpd.org/docs/directives/linked/config_ref_ListOptions.html
According to adstainer above, removing -a was not a perfect fix for him, as it left his .maintenance file behind.
Additionally, the original problem in #28013 was that WP_Filesystem_FTPext::exists('.maintenance') returns false on some servers.
The RFC can say whatever it likes. Actual implementations in the wild can vary wildly. Any solution should cover all the various cases, not just be compliant to the RFCs. Compatibility trumps specifications.
#61
follow-up:
↓ 64
@
9 years ago
As @Otto42 wrote you can't rely on RFCs. The root cause for the problem is using dirname( $file ) instead of $file.
WP 4.3.1 is accessing the file or directory directly, e.g. '/htdocs/.htaccess'. Even if the ftp server does not show hidden files for ftp_nlist() command by default it returns the filename if you access it directly.
WP 4.4 is accessing the directory where the file or directory lives. From the example above '/htdocs' is accessed and ftp_nlist() returns the content of the directory as exposed by the ftp server. If hidden files are not shown by default '.htaccess' would be missing.
This is the reason why removing the -a option from 4.4 fails on the .maintenance while it works in 4.3.1.
I don't know why $wp_filesystem->exists() has been changed in 4.4. If the goal was to get rid of $wp_filesystem->is_dir() one could have simply used ftp_size() to check whether $file is a directory as it will always return -1.
If using dirname( $file ) is the way WP should work from now you need to test whether you can see hidden files with ftp_nlist() or not by putting a hidden file to the ftp server before you execute ftp_nlist() and remove it afterwards. If you don't see the file you have to try it again with the -a option set.
<?php public function exists( $file ) { $path = dirname( $file ); $filename = basename( $file ); $ftp_file_name = ".tmp_ftp"; $ftp_file_content = "temporary file to evaluate whether the ftp server returns hidden files by default"; $ftp_file_stream = fopen( 'data://text/plain,' . $ftp_file_content,'r'); @ftp_fput( $conn, $path . '/' . $ftp_file_name, $ftp_file_stream, FTP_BINARY); $file_list = @ftp_nlist( $this->link, $path ); if( !in_array( $ftp_file_name, $file_list, true )) { $file_list = @ftp_nlist( $this->link, '-a ' . $path ); } ftp_delete( $conn, $path . '/' . $ftp_file_name ); if ( $file_list ) { $file_list = array_map( 'basename', $file_list ); } return $file_list && in_array( $filename, $file_list ); }
#62
in reply to:
↑ 60
;
follow-up:
↓ 63
@
9 years ago
It makes me sad that people think it's okay for software to violate the RFC. Every part of my soul screams out with "ProFTPD users should set ListOptions "-a"
and someone should file an upstream bug against ProFTPD to fix their buggy NLST
behavior." :-(
I'd much prefer the mainline WP code be implemented towards the RFC, and detect the special edge cases where we support things that deviate from the RFC (e.g., ProFTPD) and handle then accordingly.
On ftp_connect()
we can issue a FEAT
command and look for MLST
which ProFTPD implements, and an ACCT
command and look for the 502
error response, as ProFTPD's documentation says they don't implement it ("However, the ACCT (Account) command is not implemented."). If ProFTPD is detected, then WP_Filesystem_FTPext::exists()
could use NLST -a
.
I'd be happy to submit a patch that implements this, if everyone agrees.
#63
in reply to:
↑ 62
;
follow-up:
↓ 66
@
9 years ago
Replying to dossy:
It makes me sad that people think it's okay for software to violate the RFC.
Yes RFCs should not be violated. However a RFC is still nothing you have to obey to.
On
ftp_connect()
we can issue aFEAT
command and look forMLST
which ProFTPD implements, and anACCT
command and look for the502
error response, as ProFTPD's documentation says they don't implement it ("However, the ACCT (Account) command is not implemented."). If ProFTPD is detected, thenWP_Filesystem_FTPext::exists()
could useNLST -a
.
Why only implement an edge case bug fix for ProFTP. Following my approach you catch any exception from the rfc.
#64
in reply to:
↑ 61
;
follow-up:
↓ 65
@
9 years ago
Replying to mensmaximus:
[...]
This is the reason why removing the -a option from 4.4 fails on the .maintenance while it works in 4.3.1.
I don't think that's always the case. After I had this problem I ended up in maintenance mode, but I deleted the .maintenance file and the site became live again.
So when I changed the code to remove the -a option I was doing so to a site that was not in maintenance mode. I then updated two plugins and two themes, successfully, and on completion the site which had been temporarily in maintenance mode was live again.
I asked @adstainer "Was it already in maintenance mode before you tried the update?" I think we need an answer to that question before concluding that removing the -a option from 4.4 fails on the .maintenance.
#65
in reply to:
↑ 64
@
9 years ago
Replying to Cornwell:
Replying to mensmaximus:
[...]
This is the reason why removing the -a option from 4.4 fails on the .maintenance while it works in 4.3.1.
I don't think that's always the case. After I had this problem I ended up in maintenance mode, but I deleted the .maintenance file and the site became live again.
It was a guess. I just checked the code and the .maintenance file is handled by WP_Upgrader:maintenance_mode which handsover the deletion to $wp_filesystem->delete(). This function does not rely on $wp_filesystem->exist()
#66
in reply to:
↑ 63
;
follow-up:
↓ 67
@
9 years ago
Replying to mensmaximus:
Why only implement an edge case bug fix for ProFTP. Following my approach you catch any exception from the rfc.
Your approach destructively clobbers a file which you only assume does NOT exist in the target location, requires write privileges to the target location in order to function, and requires potentially up to 3 extra FTP commands *per invocation of exists()
*. Sorry, I think this is a bad solution, for these reasons.
#67
in reply to:
↑ 66
;
follow-up:
↓ 68
@
9 years ago
Replying to dossy:
Your approach destructively clobbers a file which you only assume does NOT exist in the target location, requires write privileges to the target location in order to function, and requires potentially up to 3 extra FTP commands *per invocation of
exists()
*. Sorry, I think this is a bad solution, for these reasons.
But it works with any FTP server not complying to the RFC. And it is just an approach. I never said this is the perfect implementation. This approach can be reached in many ways.
Regarding your objections:
- If you do not have write privileges the whole update will fail.
- The filename can be the result of a nonce or a timestamp or what ever.
- The test can be done right after the login to reduce the overhead to 3 extra ftp commands. Whether -a is necessary can than be stored into a transient or the public $link var (make it an array and change some function calls)
To much changes? Just revert back to the way 4.3.1 does it. But having a solution to catch only one exception and to miss many others is imho no solution.
#68
in reply to:
↑ 67
@
9 years ago
Replying to mensmaximus:
- The filename can be the result of a nonce or a timestamp or what ever.
Maybe even the .maintenance file could be used to check whether hidden files are listed right after the ftp_login. Unfortunately the .htacces file cant be used as it may not exit due to the webserver (nginx admins may delete it)
#70
@
9 years ago
34976.diff is an untested attempt at supporting all these various FTP implementations.
- Attempt a
NLST
listing, if file exists in that list, Great! (This may also list hidden files under some FTP systems) - If it's a hidden file:
- attempt a
NLST -a
listing (4.4 behaviour) - attempt a
LIST -a
listing (4.3 behaviour)
- attempt a
This means that for a hidden file that doesn't exist, there'll be 3 FTP operations, If it does exist, hopefully it'll be found sooner than later. I don't care about the extra FTP cycles in that case.
34976.2.diff is slightly different ordering
- conditionally:
- If hidden, perform a
NLST -a
(4.4ish behaviour) - If not hidden, perform a
NLST
(4.4ish behaviour)
- If hidden, perform a
- If hidden, perform a
LIST -a
(4.3 behaviour) - If hidden, perform a
NLST
This makes the assumption that servers support NLIST -a
, falling back to LIST -a
and NLIST
only when needed, however also not using -a
unless it knows it's needed to, which means that the hidden branches only get hit once or twice, removing the need for caching the result.
I'm leaning towards 34976.2.diff as it should be the most performant and clear-cut option.
Related to this, I just opened #35066 to rename the file, simply so we don't have to deal with FTP + hidden files again.
#71
@
9 years ago
Had the host enable 'Mod_Ruid2' on the server which solved the plugin issue for me.
#72
in reply to:
↑ 58
@
9 years ago
Replying to Cornwell:
Replying to adstainer:
I tried the removing the -a flag and it appeared to work. There was no error message this time, however it is still stuck in maintenance mode.
Was it already in maintenance mode before you tried the update? Deleting the .maintenance file should get you out of maintenance mode.
Like you, I removed the -a flag and I have successfully updated two plugins plus two themes. But presumably because I was not in maintenance mode when I started I am not stuck.
My configuration:
cPanel Version 11.52.1 (build 2)
Apache Version 2.2.27
PHP Version 5.4.27
MySQL Version 5.5.46-cll
Architecture x86_64
Nope. It wasn't in maintenance mode before the update. Also every time I have tried there has been no .maintenance file on the server. I have checked and double checked. Was the first thing I looked for. It remains in maintenance for ages until it times out whether or not the -a flag has been set.
#74
@
9 years ago
Similar issues here, although problem seems to have started before even upgrading to 4.4. In fact I got the message "Unable to locate WordPress Content > directory (wp-content)" when I tried to update.
After some permission setting changes finally managed to update it to 4.4....but then I encountered the update issues with plugins/themes.
Example:
The update process is starting. This process may take a while on some hosts, so please be patient.
Enabling Maintenance mode…
Updating Plugin TinyMCE Advanced (1/1)
Downloading update from https://downloads.wordpress.org/plugin/tinymce-advanced.4.2.8.zip…
Unpacking the update…
Installing the latest version…
Removing the old version of the plugin…
Plugin update failed.
An error occurred while updating TinyMCE Advanced: Could not create directory. /public_html/wp-content/plugins/tinymce-advanced/
All updates have been completed
Once that has happened I get the "Briefly unavailable for scheduled maintenance. Check back in a minute." message which can only be removed by manually deleting the .maintenance file via cPanel 11.52.1.3.
Deleting the plugin/theme and then installing the plugin/theme as new works - after clearing cache, but also results in the maintenance page staying on.
#77
@
9 years ago
- Owner set to dd32
- Resolution set to fixed
- Status changed from new to closed
In 35944:
#79
@
9 years ago
Instead of attempting to fix this for both use-cases, I've chosen to simply revert to 4.3 behaviour.
We may attempt to use the patches i've added here in a future release, but for now, I've reverted it so #28013 has been re-opened.
#80
@
9 years ago
I can indeed confirm that NLIST -a is the culprit for my system.
By removing the -a option, i was able to once again update plugins and themes.
In file: wp-admin/includes/class-wp-filesystem-ftpext.php
Changed:
$file_list = @ftp_nlist( $this->link, '-a ' . $path );
Changed To:
$file_list = @ftp_nlist( $this->link, $path );
After this edit, all worked as expected.
#84
follow-ups:
↓ 88
↓ 91
@
9 years ago
Did that...didn't work. Getting this error message now while trying to update a plugin.
The update process is starting. This process may take a while on some hosts, so please be patient.
Updating Plugin Breadcrumb NavXT (1/1)
An error occurred while updating Breadcrumb NavXT: Unable to locate WordPress Content directory (wp-content).
All updates have been completed
#85
@
9 years ago
Okay, I'm not sure if this is helpful or not, it might be my isolated incident, but I was having the same "update" issue, but I thought maybe it was my browser so I tried using Safari instead of Chrome, and it worked! I was able to update all 20 of my plugins just fine.
#86
@
9 years ago
I also tried @arcain6's solution, and I'm able to automatically update in the interim. Thanks!
#88
in reply to:
↑ 84
;
follow-ups:
↓ 89
↓ 90
@
9 years ago
It seems you are experiencing a different issue. Make sure the login credentials you are supplying to the FTP form are for your particular site alone. Sub-domain sites sometimes have issues when FTP update is initiated from the parent domain's FTP credentials..
Also realize that that particular plugin has had update issues for several versions. It seems to be an issue directly involved with that plugin.
Replying to marceltencaat:
Did that...didn't work. Getting this error message now while trying to update a plugin.
The update process is starting. This process may take a while on some hosts, so please be patient.
Updating Plugin Breadcrumb NavXT (1/1)
An error occurred while updating Breadcrumb NavXT: Unable to locate WordPress Content directory (wp-content).
All updates have been completed
#89
in reply to:
↑ 88
@
9 years ago
The plugin was just an example, doesn't matter what plugin I try to update.
Will check with hosting provider once more as it seems they are able to update plugins from their place. They said they did manage to update some, then reset my login credentials. Worked once, then failed.
Replying to arcain6:
It seems you are experiencing a different issue. Make sure the login credentials you are supplying to the FTP form are for your particular site alone. Sub-domain sites sometimes have issues when FTP update is initiated from the parent domain's FTP credentials..
Also realize that that particular plugin has had update issues for several versions. It seems to be an issue directly involved with that plugin.
#90
in reply to:
↑ 88
@
9 years ago
Replying to arcain6:
It seems you are experiencing a different issue. Make sure the login credentials you are supplying to the FTP form are for your particular site alone. Sub-domain sites sometimes have issues when FTP update is initiated from the parent domain's FTP credentials..
Also realize that that particular plugin has had update issues for several versions. It seems to be an issue directly involved with that plugin.
Replying to marceltencaat:
Did that...didn't work. Getting this error message now while trying to update a plugin.
The update process is starting. This process may take a while on some hosts, so please be patient.
Updating Plugin Breadcrumb NavXT (1/1)
An error occurred while updating Breadcrumb NavXT: Unable to locate WordPress Content directory (wp-content).
All updates have been completed
Looking at what you have posted it is not related to the plug in. It is having problems locating the wp_content folder (where your plug in folder is located) If it cannot locate the wp_content folder it will not be able to update any plugins. Please check your wp_content folder is in the root of the site
#91
in reply to:
↑ 84
@
9 years ago
Replying to marceltencaat:
Did that...didn't work. Getting this error message now while trying to update a plugin.
The update process is starting. This process may take a while on some hosts, so please be patient.
Updating Plugin Breadcrumb NavXT (1/1)
An error occurred while updating Breadcrumb NavXT: Unable to locate WordPress Content directory (wp-content).
All updates have been completed
Looking at what you have posted it is not related to the plug in. It is having problems locating the wp_content folder (where your plug in folder is located) If it cannot locate the wp_content folder it will not be able to update any plugins. Please check your wp_content folder is in the root of the site
#92
@
9 years ago
That is the case. Opened public_html in the FTP and wp-content is in the root directory.
#93
follow-ups:
↓ 94
↓ 95
@
9 years ago
Hosting provider made some changes to the server configuration and it's all working now. 100% updated.
#94
in reply to:
↑ 93
@
9 years ago
Replying to marceltencaat:
Hosting provider made some changes to the server configuration and it's all working now. 100% updated.
Could you share the changes your hosting provider made? That would help me at least til this is fixed.
Thanks!
#95
in reply to:
↑ 93
@
9 years ago
Replying to marceltencaat:
Hosting provider made some changes to the server configuration and it's all working now. 100% updated.
I'm still having issues on my dedicated server updating and installing.. can you share their solution to pass along to my techs?
#96
@
9 years ago
Hello. This may add some insight...
I'm having the same exact issue. After upgrading to WP 4.4 I cannot update any plugins nor can I upgrade to 4.4.1 ...same error messages as everyone else.
WordPress Upgrade to 4.4.1 response:
Unpacking the update… The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php Installation Failed
Attempted plugin update response:
Unpacking the update… Installing the latest version… Removing the old version of the plugin… Plugin update failed. An error occurred while updating Akismet: Could not create directory. /public_html/wp-content/plugins/akismet/
I have been finding messages like this in my apache error logs since the issue began:
(This produced consistently when attempting to upgrade from 4.4 to 4.4.1)
Note: THIS IS A MULTISITE INSTALLATION
[Wed Jan 06 14:09:06.444212 2016] [:error] [pid 6944] WordPress database error Duplicate column name 'signup_id' for query ALTER TABLE blog_resrc_signups ADD signup_id BIGINT(20) NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST made by wp_upgrade, pre_schema_upgrade [Wed Jan 06 14:09:06.444491 2016] [:error] [pid 6944] WordPress database error Can't DROP 'domain'; check that column/key exists for query ALTER TABLE blog_resrc_signups DROP INDEX domain made by wp_upgrade, pre_schema_upgrade [Wed Jan 06 14:09:06.506300 2016] [:error] [pid 6944] WordPress database error Can't DROP 'blog_id'; check that column/key exists for query ALTER TABLE blog_resrc_options DROP COLUMN blog_id made by wp_upgrade, upgrade_all, upgrade_340 [Wed Jan 06 14:09:06.506561 2016] [:error] [pid 6944] WordPress database error Can't DROP 'comment_approved'; check that column/key exists for query ALTER TABLE blog_resrc_comments DROP INDEX comment_approved made by wp_upgrade, upgrade_all, upgrade_340
Note: "blog_resrc_" is not the real prefix.
Before upgrading to 4.4 everything worked just fine.
All file/folder permissions are set correctly and are unchanged since the 4.4 upgrade.
My server (GoDaddy VPS):
CentOS 6 + cPanel
Apache 2.4.16
PHP 5.5.30
MySql 5.6.28
Hopefully this helps!
#97
@
9 years ago
Got a short reply from hosting provider. Note that I am on shared hosting environment.
"We have changed group ownership of plugins and themes to nobody which fixed the issue. "
#98
follow-up:
↓ 101
@
9 years ago
Am afraid that's not going to be the solution...just tried to upgrade to 4.4.1. (though Theme Twenty Sixteen updated without a problem).
Update WordPress
Downloading update from https://downloads.wordpress.org/release/wordpress-4.4.1-no-content.zip…
Unpacking the update…
Warning: copy(/home/plmcom/public_html/wp-admin/includes/update-core.php) [function.copy]: failed to open stream: Permission denied in /home/plmcom/public_html/wp-admin/includes/class-wp-filesystem-direct.php on line 257
The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php
Installation Failed
#99
@
9 years ago
@marceltencaat you will need to upgrade to 4.4.1 manually. After that, it will be able to update as before.
https://codex.wordpress.org/Updating_WordPress#Manual_Update
#100
@
9 years ago
Successfully upgraded to 4.4.1 Very surprised they have not updated the relevant file causing the plugin update issue though.
#101
in reply to:
↑ 98
@
9 years ago
Replying to marceltencaat:
[...]
Warning: copy(/home/plmcom/public_html/wp-admin/includes/update-core.php) [function.copy]: failed to open stream: Permission denied in /home/plmcom/public_html/wp-admin/includes/class-wp-filesystem-direct.php on line 257
[...]
This very clearly is a permissions issue (the user the webserver is running as does not have write permissions to the file wp-admin/includes/update-core.php
), and it's using class-wp-filesystem-direct.php
so it's not even FTP related. At this point, @marceltencaat's issue is not a bug, but a support issue and is probably best handled in the support forums.
#102
@
9 years ago
Interestingly my sites that were affected have auto updated to 4.4.1 successfully. I tested the plugins and themes as soon as it happened and confirmed they are updating properly again.
#103
@
9 years ago
My tech made some changes on my dedicated linux server. This is what he did.. not sure if it will work for you all but here goes:
For the server wide permissions issue - The thing that was wrong here is that HTTPD (the process serving web pages) is running as “nobody” instead of a privileged account. This was likely a change from the CPanel company for security reasons but unfortunately breaks Wordpress with respect to plugin updates and file uploads.
Here is exactly what I did to fix this problem for you:
- Added the nobody user to every user group in /etc/group
- The following CLI
# cd /home
# chmod -R g+w *
The first line (cd /home) changes directory to your /home where all your accounts are located. The second line (chmod -R g+w *) adds write permission to the group for every directory recursively under /home.
Hope this helps.. so far so good on my server, no issues as of yet.
+1 experiencing the same issue
Please let me know if you would like any further information, or testing.
CentOS 6.7
php 5.4.45
apache 2.2.15
SELinux enabled
suphp NOT enabled
All plugins installed via WP plugin installer,
FTP_USER, FTP_PASS, FTP_HOST defined in wp-config
Problems began after updating to WP 4.4, never any issue until then. It appears that when updating a plugin, the old directory/files is not removed, leading to a failure when creating the new directory. It is happening on single installs and multisite installs.