dlmeyer

FWIW, My tests were using PHP 5.5.20 in all instances.

Confirmed: installing ssh-sftp-updater-support plugin does allow the delete-selected operation to complete successfully.

However, it did not resolve the General Settings page issue at this point.

I then did a re-install of WP 4.1 on the site, and afterwards, the General Settings page does load correctly. (ALBEIT, with a consistent 45+ second delay after Timezone field generation/display and the display of the UTC time and the remainder of the page…)

Perhaps the SSH2-related issue with delete-selected is causing files-left-behind from previous installations, which is affecting performance of new version(s)… (And a re-install successfully cleans up the left-behinds…)

Already tried with clean site, Ipstenu.

(Fresh updated site, no plugins added: add ‘Hello Dolly’ — success. Remove ‘Hello Dolly’ — FAIL.)

I found the following [error] logged: When I started looking at the correct error.log…)
————————-
[Fri Dec 19 16:09:33 2014] [error] [client ##.##.##.##] PHP Warning: stream_set_timeout(): No support for ssh2 stream timeout. Please recompile with libssh2 >= 1.2.9 in /export/prod/L/xxxxx.itcs.illinois.edu/public/wordpress/wp-admin/includes/class-wp-filesystem-ssh2.php on line 139, referer: https://xxxxx.itcs.illinois.edu/wp-admin/plugins.php?action=delete-selected&checked%5B0%5D=hello.php&plugin_status=all&paged=1&s&_wpnonce=xxxxxxxxxx
————————-

Same host/environment with WP 4.0.1 yields success – no sign of this error. This implies something new, perhaps an extra step in ‘includes/class-wp-filesystem-ssh2.php’?

I am also encountering this on all sites updated past 4.0.1. It is manifesting as a “The connection was reset” error, however, as my sites’ update functions employ SSH2.

On the server side, I see two attempts for each deletion attempted: It logs the login/open, followed by init messages (umask on, chmod denied), then immediate SFTP finished/close. No file operations are logged at all.

It is acting as if the request to delete is abending during the action…

The original reporter may be accessing their site through a proxy of some sort — the 502 error is what would be reported to them when the “backend”/host server drops the connection like this.

I’ve confirmed that this operation works 100% on WP 4.0.1. The same site updated to 4.1 fails. (NOTE: This is also failing on 4.2alpha…)

(And FWIW, I’m also noting that the Settings -> General page is incomplete — no submit or footer, as if it were abending during page generation. This also tracks with the 4.1 upgrade. I doubt it’s the same problem, but I suppose it might be possible…)