Unable to update plugins after upgrade to 4.2

I do have this issue as well it also appears for my themes, so I think this is more a generic issue with the updater?!

After I click ok to start the updates, I’m getting a blank screen (well WP admin background and just the title “Update Plugins”, when just picking up a single plugin from the plugins page I get a never ending icon with the message updating.

For me WP is not creating a .maintenance file and keeps accessible.

So no updates currently possible. No entries at my server logs.

Deleting plugin or theme files from my server is working for me via WP admin backend.

I have the same problem, with CentOS 6.6 and php 5.3.3.
But there is an error in error logs saying
“PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 523800 bytes) in /data/www/mysite.com/wp-admin/includes/file.php on line 159, referer: https://www.mysite.com/wp-admin/update.php?action=update-selected&plugins=redirection%2Fredirection.php%2Cwordpress-seo%2Fwp-seo.php&_wpnonce=06cc2873d8”

Tried increasing php memory to 1GB, even after that this error is shown and plugins are not updating.
I could update the plugins before updating to wordpress4.2

I have exactely the same issue as Joerg.

So I have this same issue with one particular host.
I have updated this morning more than 10 wp sites, all with multiple different plugins. All updated fine after the 4.2 wordpress update.

This one particular host, turns out they are also running on CentOS.
So far that is the only common thing that seems to have an issue with updating plugins after 4.2

Update: disabled ALL plugins. Tried to update WordPress SEO by Yoast plugin. Worked

I then tried to re-enable all plugins, except for the plugins that still need updating. Updated the plugins while disabled, worked!
I have tested this on two separate websites.

Conclusion: on CentOS, disable plugins that need updating, update plugins as you normally would, or even with the “update” button off the plugins screen.
That should work.

Someone please confirm this solution!

Confirmed Pyromania666!

It also works in the case of a theme update, where I had to deactivate first and then update the theme to get it to update.

I encountered the same situation on several websites. I’ve narrowed the issue in my case down to wordpress installations which are hosted on sub-domains instead of the main domain (or actually, in addition to the main domain). Any website which was not hosted on a sub-domain updated itself fine on the same exact server. In case of the sub-domains this was not a multi-site install.

jaykrik, that is also the error message I was getting, and my memory allowance is clearly over the amount the error says I need.

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 523800 bytes) in /wp-admin/includes/file.php on line 159

Awesome, thank you perdrix for confirming.

Oddly enough my websites were single site per domain, installed on the root. No sub-domains for either.

Thank you so much Pyromania and Perdrix.
I encountered the plugin-updating-problem this morning, but not on all sites. The sub-domain sites were the problem.
Tried your solution and worked like a charm.

So it is going to be a good weekend after all ??

Thank you so much! de-activating the plugin before trying to update worked perfectly. I too was trying this on a subdomain. I do all my updates on a dev.mysite.com subdomain to test things first. I didn’t have the same problem once I felt okay doing the update on the main www site.

Thanks again!

The problem is caused by the wp_tempnam() function in wp-admin/file.php

It recurses on itself and therefore php will run out of memory. This seems to be called when “enabling maintenance mode” so by deactivating the plugin first, presumably this will avoid maintenance mode.

Unfortunately it seems like a WordPress update itself requires maintenance mode, so this could get interesting when an update is released to fix the problem!

recursive call can be seen below ‘if the folder is falsey…’ – “return wp_tempnam(“…..

function wp_tempnam( $filename = '', $dir = '' ) {
        if ( empty( $dir ) ) {
                $dir = get_temp_dir();
        }

        if ( empty( $filename ) || '.' == $filename ) {
                $filename = time();
        }

        // Use the basename of the given file without the extension as the name for the temporary directory
        $temp_filename = basename( $filename );
        $temp_filename = preg_replace( '|\.[^.]*$|', '', $temp_filename );

        // If the folder is falsey, use it's parent directory name instead
        if ( ! $temp_filename ) {
                return wp_tempnam( dirname( $filename ), $dir );
        }

        $temp_filename .= '.tmp';
        $temp_filename = $dir . wp_unique_filename( $dir, $temp_filename );
        touch( $temp_filename );

        return $temp_filename;
}

Keith

Outstanding analysis Keith. I see you reported it to WordPress Core trac as well… thanks.

Thank you Keith @cloudware, that was exactly the issue, on “some” of my sites.

To be able to update the plugins and themes before the release of 4.2.1 with the fix, I temporarily copied the function wp_tempnam from the same file from WP 4.1.1 and it worked.

Thx again! also for reporting it.

Disable,update and re-enable worked.
Fortunately theme updates does not have issue.
Thank you for the solution..

62 sites affected, will not do it manually, hope a fix is coming soon…

@jaykrik yes, Clouware explained why when disabling it works, but in case of complex multisite with many users it can be difficult to disable re-enable all plugins and themes in use (going to each sub-site. etc), the maintenance mode is there for that.

@stefan, if you look at the modification in the diff file there and modify the file, everything will work perfectly. ok you’ll have to upload that file to 62 sites, but that’s easier than disable-reenable plugins and themes everywhere.

look at the submission here https://core.trac.www.ads-software.com/ticket/32135 the diff file shows that it’s simply modify wp-admin/includes/file.php
replacing line 149
if ( empty( $filename ) || '.' == $filename ) {
with
if ( empty( $filename ) || '.' == $filename || '/' === $filename ) {

Anyway, now that it’s in the trac, it should be corrected for version 4.2.1