gt1329a

You’re right. I removed the .htaccess and it still works.

At least I’ll know what to look for if that ever happens in the future. I’m going to leave the system cron job running instead of scheduling it through wp-plugin just to be on the safe side.

Thanks again for the help. I would probably have never figured that out on my own, unless by pure dumb luck.

Sure enough. I uninstalled XCache and backups from wp-admin started working again. I couldn’t find a configuration setting to exclude particular files from XCache, but putting this in an .htaccess file in wp-content/plugins/updraftplus worked:

php_flag xcache.cacher Off
php_flag xcache.optimizer Off

The strange thing is that I’ve been running XCache on this server much longer than I’ve had UpdraftPlus installed. I wonder what changed just a few weeks ago.

I just purchased an UpdraftPlus Premium license to say thanks so much for your help with this issue.

Interesting. When I disabled all plugins, trying to run a backup still had the same issue as before. However, I saw an error in the WordPress errors.log that I haven’t seen before:

[29-Mar-2015 02:31:56 UTC] PHP Fatal error: Cannot redeclare class UpdraftPlus_BinZip in /var/sites/Encosia.com/public_html/blog/wp-content/plugins/updraftplus/class-zip.php on line 12

Does that mean anything to you?

The system-level cron.d job has been working well for the past week, which is comforting. Thanks for that suggestion.

I suspected plugins too, but was reluctant to try disabling them since my site gets pretty constant traffic and the layout/functionality breaks pretty quickly without some of them enabled. Saturday night is the lowest point for my traffic though, so I’m going to give that a try now.

That was my first thought too, re: running it from a system cron job. I’m going to set that up for now as a stopgap.

I do have PHP error logging enabled in the php.ini:

error_reporting = E_ALL | E_STRICT
error_log = /var/log/php_errors.log

The file is totally empty though. Tailing it while trying to run backups in wp-admin doesn’t result in any output.

As a sanity check, I created a trigger-error.php file with just this in it:

<?php trigger_error("Fatal error", E_USER_ERROR); ?>

And did see an error logged out to php_errors.log when I requested trigger-error.php in a browser. So, it seems like the error logging is working and none are occurring when I try to run a backup.

I don’t know if this matters, but I can even go to the wp-admin page and watch an accurate progress bar for backups triggered from the command line. It seems to just be the triggering that doesn’t work there.

Interesting. Running it from the command line resulted in a full files/database backup without any errors. Going back to the wp-admin interface, backups still hang at 0%.

I wasn’t seeing a zlib error before in relation to this 0% stall. I was just testing to be sure the functions.php gzopen shim is still in effect by pulling it out, seeing that there’s a new error without it, putting it back, and verifying that the error is gone again.

I do have shell access to the server. It’s a VPS at Linode.

I tried commenting that code out of functions.php and now I get this notice at the top of the UpdraftPlus debug tab:

Abort class-pclzip.php : Missing zlib extensions

After uncommenting that bit in functions.php, the zlib error is gone. So, it seems to be taking effect.

I’m looking everywhere I can for more errors, but all I can find in the PHP error log, apache error log, and the WordPress error log are those notices I posted above. After searching, it seems like those are probably coming from other plugins using older, deprecated APIs? Could those affect UpdraftPlus to this extent?

I have this in my functions.php to cover that, which seemed to be working okay until recently:

if (!function_exists('gzopen')) {
function gzopen($filename , $mode, $use_include_path = 0 ) { return gzopen64($filename, $mode, $use_include_path); }
}

Where should I look for other PHP errors?

I’ve tried enabling debug mode in WordPress and sending that to a log file. I see some deprecation notices, but no errors when I trigger a backup. These are the deprecation notices I’m seeing for each request, if it’s relevant:

[16-Mar-2015 14:27:03 UTC] PHP Notice:  add_option was called with an argument that is <strong>deprecated</strong> since version 2.3 with no alternative available. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3497
[16-Mar-2015 14:27:03 UTC] PHP Notice:  WP_User->id was called with an argument that is <strong>deprecated</strong> since version 2.1! Use <code>WP_User->ID</code> instead. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3495
[16-Mar-2015 14:27:03 UTC] PHP Notice:  WP_User->id was called with an argument that is <strong>deprecated</strong> since version 2.1! Use <code>WP_User->ID</code> instead. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3495
[16-Mar-2015 14:27:03 UTC] PHP Notice:  WP_User->id was called with an argument that is <strong>deprecated</strong> since version 2.1! Use <code>WP_User->ID</code> instead. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3495
[16-Mar-2015 14:27:03 UTC] PHP Notice:  WP_User->id was called with an argument that is <strong>deprecated</strong> since version 2.1! Use <code>WP_User->ID</code> instead. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3495
[16-Mar-2015 14:27:03 UTC] PHP Notice:  WP_User->id was called with an argument that is <strong>deprecated</strong> since version 2.1! Use <code>WP_User->ID</code> instead. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3495
[16-Mar-2015 14:27:03 UTC] PHP Notice:  load_plugin_textdomain was called with an argument that is <strong>deprecated</strong> since version 2.7 with no alternative available. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3497