Plug ins fail to update after WP 4.4 installed

[patdundee]

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.

[verdonv]

+1 experiencing the same issue

[justingreerbbi]

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.

[mordauk]

I saw this happen yesterday.

[patdundee]

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

[SergeyBiryukov]

@dd32, could you take a look?

[kioub]

+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

[justingreerbbi]

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

[verdonv]

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.

[verdonv]

Disabling SELinux makes no difference :-)

[The_Tim]

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.

[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?

[verdonv]

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.

[The_Tim]

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.

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

[verdonv]

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.

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

[verdonv]

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.

[justingreerbbi]

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

[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

[justingreerbbi]

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?

[verdonv]

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

[patdundee]

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.

[patdundee]

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

[verdonv]

In interest of completeness, I am also using PURE-FTPD (and it's virtual users) mechanism.

[mnewberry]

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.

[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 :)

[verdonv]

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.

[patdundee]

@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

[patdundee]

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

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

[patdundee]

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

[Kouin]

Adding to that list...

CentOS 6.7.
PHP 5.6.14 and Apache.

[SergeyBiryukov]

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.

[patdundee]

Hi Guys (tech guys)

Is there any update on this issue so far please.

Many thanks

[SergeyBiryukov]

#35020 was marked as a duplicate.

[ralbatross]

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?

[S1L1K0N]

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.

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

See ​this related stackoverflow question.

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

See ​this related stackoverflow question.

[ralbatross]

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.

See ​this related stackoverflow question.

[S1L1K0N]

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.

See ​this related stackoverflow question.

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.

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

See ​this related stackoverflow question.

[ralbatross]

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.

See ​this related stackoverflow question.

[SergeyBiryukov]

#35026 was marked as a duplicate.

[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

[patdundee]

@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

[kioub]

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

[justingreerbbi]

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.

[mensmaximus]

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?

[Otto42]

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.

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

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

[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

[dossy]

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.

[Otto42]

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.

[mensmaximus]

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 );
}

[dossy]

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.

[mensmaximus]

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

Why only implement an edge case bug fix for ProFTP. Following my approach you catch any exception from the rfc.

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

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.

[mensmaximus]

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

[dossy]

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.

[mensmaximus]

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.

[mensmaximus]

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)

[tuncan]

+1 with this problem

Fedora 21
PHP 5.6.15
Apache 2.4.16

[dd32]

34976.diff​ is an untested attempt at supporting all these various FTP implementations.

1. Attempt a NLST listing, if file exists in that list, Great! (This may also list hidden files under some FTP systems)
2. If it's a hidden file:
   • attempt a NLST -a listing (4.4 behaviour)
   • attempt a LIST -a listing (4.3 behaviour)

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

1. conditionally:
   • If hidden, perform a NLST -a (4.4ish behaviour)
   • If not hidden, perform a NLST (4.4ish behaviour)
2. If hidden, perform a LIST -a (4.3 behaviour)
3. 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.

[atimes2015]

Had the host enable 'Mod_Ruid2' on the server which solved the plugin issue for me.

[adstainer]

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.

[BarezSolutions]

Update Failed: Could not create directory.

[marceltencaat]

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.

[dd32]

#35091 was marked as a duplicate.

[dd32]

#35026 was marked as a duplicate.

[dd32]

In 35944:

Filesystem: Revert [33648] and [34733] unfortunately these have caused issues for some servers, while fixing it for others.

See #28013

Fixes #34976 for trunk
Fixes #34976 for trunk

[dd32]

In 35945:

Filesystem: Revert [33648] and [34733] unfortunately these have caused issues for some servers, while fixing it for others.

See #28013
Fixes #34976 for the 4.4 branch
Fixes #34976 for the 4.4 branch

[dd32]

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.

[arcain6]

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.

[BarezSolutions]

Tried what @arcain6 did and it worked for me!
Thanks alot.

[scrashi]

I Tried what @arcain6 did and it worked for me too
thanks!

[ShanghaiTimes]

arcain6's fix worked for me too.
I'm on OSX 10.11/2 (El Capitain) and use normal ftp

[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

[Goingfor2]

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.

[thebeggs4]

I also tried @arcain6's solution, and I'm able to automatically update in the interim. Thanks!

[RLsARc]

Thanks @arcain6 !

[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

[marceltencaat]

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.

[patdundee]

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

[patdundee]

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

[marceltencaat]

That is the case. Opened public_html in the FTP and wp-content is in the root directory.

[marceltencaat]

Hosting provider made some changes to the server configuration and it's all working now. 100% updated.

[Caged]

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!

[aidaguzman]

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?

[mlewitz]

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!

[marceltencaat]

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

[marceltencaat]

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

[Otto42]

@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

[patdundee]

Successfully upgraded to 4.4.1 Very surprised they have not updated the relevant file causing the plugin update issue though.

[dossy]

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.

[adstainer]

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.

[aidaguzman]

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:

1. Added the nobody user to every user group in /etc/group
2. 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.