Support » Plugin: WordPress Backup to Dropbox » [Plugin: WordPress Backup to Dropbox] Issues with v1.2.1

  • Resolved Matt Jensen


    Hi there

    I have discovered that version 1.2.1 is not working on 6 of my WP sites, both on Linux and Windows WP sites.

    The main problem is that whilst WPB2D reports that it completes successfully, it completes in only about 10 seconds, and it doesn’t backup anything as far as I can see. I saw comments that many people think it is working, yet I believe that it could be a false illusion in a number of cases because of the fact that the plugin says it finishes backing up when it fact it hasn’t. Thankfully reverting to 1.2 resolves the issue on all my sites, which including 5 sites on Windows and 1 on Linux.

    I’ve spent about 6 hours today debugging the issue using the ‘Backup Now’ feature, and comparing the code from 1.2 and 1.2.1. From what I can see, the lines ‘$this->zip_file();’ in both
    are causing the problems. I have been unable to prove this reliably, but it seems that may be I can’t prove it due to some latency, eg. in wp-cron.php (eg. plugin comment of ‘waiting for WordPress to kick off the job’), server caching of files or some other ‘lag’ (on some of my Windows site, ‘touching’ web.config to restart IIS made the code change take effect and cause the plugin to start backing up files, whereas on others it didn’t. I’m not sure how often WP kicks of the wp-cron.php file though.). On some of my Windows sites, commenting that out immediately fixed the problem, on others it did not straight away and I had to revert to 1.2 to fix it. I wouldn’t be surprised though if that commenting out that line causes an exception elsewhere (eg. given there would be no DB zip file to backup as per the plugin code). On my Linux site, I had to revert to 1.2 to get it to work (it was forever stuck on ‘Backing up WordPress path at (/home/mydir/public_html/)’.

    Either way I’m somewhat surprised that the line ‘$this->zip_file();’ doesn’t have a try/catch statement around it or in the function itself, as it seems like a likely place for the code to crash, especially with so many different server configurations around. Additionally surprising that the plugin seems to fall over totally when this fails.

    This also could explain why the backup runs for 10 seconds or so, as it seems plausible that the DB backup would take that long to complete, and then upon failing to zip the file it, just finishes there, and for some reason reports a successful completion.

    Whilst debugging using the ‘Backup Now’ feature , I noticed that admin-ajax.php would always return nothing (0 bytes) when the plugin was not working, and always more than 0 bytes when it was working/there was an update to the page HTML to be made with progress. I didn’t delve in any further than this in debugging the code though, without a more thorough understanding of how the plugin’s code all works. On one site I tried disabling all plugins and changing the theme to ‘twentyeleven’, but 1.2.1 would still not work, whereas 1.2 worked straight away.

    Interestingly, whilst debugging, I tried deauthorising my plugins and deleting the app from within Dropbox, and for about 15 minutes was getting another plugin error that I’ve seen here in this discussion forum, as per this thread:
    Dropbox’s page was saying the plugin was authorised, yet in my settings on Dropbox, there were no App listed, and after clicking WPB2D ‘continue’, it was giving the error as per that thread.

    Then on my 5 other WP sites, they all started giving the same error. I think Dropbox must have got confused for a while. After about 20 minutes the problem went away. Maybe I deauthorised or uninstalled the plugin whilst a backup job was running and Dropbox kinda got locked up.

    Anyway, I hope this helps make the plugin better.

    On Windows, excluding any files still does not seem to get saved in 1.2.1 either, and clicking a checkbox does the AJAX POST to admin-ajax.php, but the response again is 0 bytes. I guess there is a plugin exception in there somewhere. I could possibly look in to it further with some more info about how the plugin works, I realise you got your work cut out for you!


Viewing 11 replies - 1 through 11 (of 11 total)
  • Oh – the other issue is that the plugin DEFINITELY needs logging. Not only for debugging purposes, but for peace of mind that it has actually backed the files up (as it says it does ‘on the box’).

    Plugin Contributor Michael De Wildt


    Thanks ALOT for taking the time to debug these issues! It is a real help and it means I can continue to improve the plugin.

    Lets go through em one at a time.

    On the failing servers, what is them PHP memory limit set to and how big is the SQL file that is dumped by the plugin?

    G’day Mike

    I wouldn’t guess it’s a memory issue, as the plugin has worked in the past/in prior versions – well at least the backup to Dropbox has eventually completed anyway. Maybe it is.

    The sites on my Windows server have 32MB memory. The one on Linux has 256M memory.

    The size of the DB dumps on the Windows Server are:
    Site 1:
    core: 2.18MB
    plugins: 3KB

    Site 2:
    core: 152KB
    plugins: 3KB

    Site 3:
    core: 1MB
    plugins: 505KB

    Site 4:
    core zip: 189KB
    plugins zip: 6KB

    Site 5:
    core: 890KB
    plugins: 1KB

    On the Linux server:
    core: 2.5MB
    plugins: 9KB

    So it looks like the zipping is working in some places.

    I think this further troubleshooting is all going to be guesswork unless we get some logging in place so I can tell you where it actually does fail.

    Interesting that the site on the Linux server which has heaps of memory still fails.


    Plugin Contributor Michael De Wildt


    Gday Matt,

    I have reverted my zip changes because I think there was a race condition between the zip closing and the original SQL file being removed that was causing some sort of fatal error. A try catch would not work in the circumstance because the PHP Zip library does not throw them in some circumstances.

    Can you please re-install the current version and let me know how it goes?

    Regarding logging, the plugin logs on exception. Unfortunately some errors in php fail silently and I cannot log them unless I implement my own PHP error logger which is superfluous because these errors will show in the server logs.


    Hi mate

    Where do I get the latest version? Are you talking about a version 1.2.2? I’ve tried 1.2.1 and it doesn’t work for me, so I don’t see the point in installing that.

    Regarding logging, I’m moreso talking about more granular logging of the plugin’s progress. eg.

    15:00: DB core backed up
    15:01: DB plugins backed up
    15:01: DB zipped
    15:01: Successfully backed DB files up at Dropbox
    15:02: Commenced file backup
    15:03: Created directory at Dropbox /wp-admin/
    15:03: Backed up directory /wp-admin/ with 120 files.

    15:04: Process appears to have gone away. Recommencing backup.

    etc. Maybe even more detail in fact so we know where the plugin falls over.

    This way I can help debug it by telling you where it stops/fails. Otherwise we’re both running almost blind in trying to resolve the issues with the plugin (you only have my info/guesses where the problems are, I don’t know the inner workings of the plugin).

    Lemme know.


    Plugin Contributor Michael De Wildt


    Hey mate,

    Ahh I see what you are saying. Thats a great idea.

    Regarding the fix you can just re install the same version as I have pushed the fix to trunk. It was small enough not to warrant a version bump.

    I will implement better logging and for the next version.

    Let me know how you go with the reinstall.


    Gday Mikey!

    Great Plug-in – I’ve had problems similar to this thread – WPD2D working on some sites but not others. I finally stumbled on this thread, uninstalled and reinstalled with your updated 1.2.1 – Problem solved.

    Some prominence in the support forum and your Blog might be a good idea to alert users given the lack of version bump.

    I’d also welcome the logging as suggested by ‘ultrawebsites’.

    Keep up the great work.


    Hey Mike

    I’m going to have to do this one site at a time, time permitting so I can keep my eye on each one. I’ve just done my own site and it looks to be running great.

    Excellent, thanks!


    Plugin Contributor Michael De Wildt


    Thanks guys,

    Sometimes I like to A-B test issues like this to see if its actually the underlying cause.

    It looks like its definitely the case here and I will bump the version today.


    Looks to be working thanks!

    One more suggestion – it’d be great if any additionally logging that you implement is backed up to dropbox as well – as otherwise when you look at your Dropbox files, you can’t tell when the files where last backed up.

    Either that, or the backup didn’t work recently. What is the expected file date of backed up files in Dropbox? The date of the last time the backup ran, or the date of the ‘first’ time the backup ran successfully?

    At the moment I have to dig through my backed up files to find a recently uploaded image to see whether it has been backed up or not to determine if the backup did successfully run (ie. irrespective of what the plugin reports).

    So backing up a log file would be great, as I could see some time logging dates in it too.

    Keep up the good work.


    Dude – I’ve got a basic site (minimal plugins, basic theme etc.) on Windows, running WP 3.4.1 and WPB2D 1.2.2, and the backup to Dropbox completes in 10 seconds or less, and nothing get’s copied to Dropbox…

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘[Plugin: WordPress Backup to Dropbox] Issues with v1.2.1’ is closed to new replies.