Support

Hello John,

The executive summary is that we're working on something like this with a caveat: it will only work if you do not use automatic updates.

Let's simplify a bit what's going in behind the scenes. When WP detects there's an update available it downloads the update file, puts the site to maintenance mode, extracts it on top of the current site, runs maintenance / upgrade code and then sets the site back to live mode. While the site is in maintenance mode you cannot run plugins. This means Akeeba Backup cannot run at this point. We could only do something before it downloads the update file.

The problem is that this hook only allows you to do something fast which can complete inside a single page load. Taking a backup takes a substantial amount of time and requires mulitple page loads. So the time limitation alone is not looking good for taking backups.

Further to that, WordPress may trigger the automatic update at any random point in time, even in the public frontend of your site when a visitor (or a search engine!) is browsing the site. This makes it quite risky running a backup. We had tried that approach with Joomla! with our Lazy Scheduling Plugin back in 2011 but within two years we had identified fourteen (14) failure modes which were not under our control and could not be worked around. Repeating past mistakes does not a wise man make.

I know that other plugins claim to take backups on WP update. However, what they don't tell you, is that they just take a mysqldump of your database and a tar of your site IF you are on a Linux server, IF these commands are available, IF you have enough disk space, IF you have plenty of CPU time and RAM, IF you can run PHP scripts for an unlimited amount of time without timing out, WITHOUT applying exceptions to what gets backed up. It works for small sites on at least passable hosting. But, you know, these are the kind of sites which only get modified once every few weeks or months so it'd make more sense to manually back them up after each content update instead of whenever WordPress updates itself.

The only way we could make this feature work -and which we are currently looking into- is only if you disable automatic updates. Then we can do exactly what we do with Joomla!. You, the Administrator, initiate a WordPress update. We hook to an event e.g. the download update package and redirect to Akeeba Backup. A backup is taken. Then we redirect back to the WP updater code, after setting a temporary variable which says "backup already taken for WordPress version X.Y.Z, let WP continue the update". Therefore we don't redirect again and WP finishes its update.

If you want to use automatic updates you are relinquishing control of the update timing. In this case your only defense against a broken site is frequent, automated, off-site backups. Luckily, Akeeba Backup Professional is explicitly designed to do exactly that. Make sure you are taking daily backups with the CLI script and you ought to be safe.

My best guess would be Q2 2018.

To cut a long story short, Davide is currently occupied with converting our Joomla! extensions to the new CSS framework which is a prerequisite for supporting Joomla 4 - where the majority of our income comes from. I have a 2-week-old girl at home. I do manage to squeeze 6-8 hours of very productive work every day - instead of 10-12. So, even though I could probably promise you March 2018 and be most likely truthful, I'd rather say May 2018 and be much safer. Fair enough? :)

As for your sites with automatic updates, I do recommend frequent automated backups anyway. If your clients do daily updates then do run twice daily backups. If your clients are only likely to visit their site once every month do twice monthly backups. Keep the last 6 or more backups if possible. I keep at least the 30 latest backups and one backup from each past month. This way if poo hits the proverbial fan you can restore their site, fast.

Also, WordPress is a bit better than Joomla when it comes to overwriting newer versions with older ones, mostly because it's written like it's 2001 with direct includes and hard dependencies. If it comes to this, you can always install an older version on top of the new one and then take a backup of the site to fix it up locally, then backup the local site and restore on top of the live to perform the (working!) update.

Don't think about the One Way to do something. Think about the outcome you want to achieve and then work out which process and which tools to use.