Today we have released the first beta of Akeeba Backup and Akeeba Solo 7. This is a major new version with important improvements and changes. In this article we will discuss the highlights of this release and what it means to you.
Unified version numbering
Previously, Akeeba Backup for Joomla followed a different version numbering than our other backup software, Akeeba Backup for WordPress and Akeeba Solo. This was confusing to clients who were using both our Joomla and non-Joomla backup software. Since the restoration script (ANGIE) followed the version numbering of Akeeba Backup for Joomla there was even more confusion when restoring a WordPress or bespoke PHP / MySQL site.
Starting with version 7.0.0.b1 all of our backup products will follow the same version numbering for the major, minor and revision parts. For example, version 7.0.0. If a specific backup software needs an additional release to address an issue affecting only that platform we will add a patch level to the version e.g. 7.0.0.1.
Rewritten backup engine
We have done a massive partial rewrite of the backup engine, the biggest one in the last 5 years. This not only improved performance but it also provides much better information about errors and warnings. Instead of suppressing the root cause of the issue you will see a detailed description which will help you track down the root cause much faster.
At the same time we have rewritten the automated log analyzer (ALICE) to be faster, use less resources and address known issues. In case you have a failed backup and you're using the Professional version of our software it will help you identify the root cause faster. However, do remember, it's only meant to run on failed backups. If you run it on a successful backup it will give you false information. This happens because there are some rare cases where the log file appears to be successful but the browser has displayed an error. ALICE tries to cater for these cases as well.
Of course, if you are a subscriber, you can file a support ticket and give us your log file so we can help you. The improved logging will help us be even more efficient.
We have taken a lot of time to improve the way MySQL PROCEDUREs, FUNCTIONs and TRIGGERs are handled by the backup engine. This will now work reliably when you have in-line or multi-line comments in their definitions. Moreover, they work correctly with the "Main site database only" backup type, i.e. when outputting just a .sql file.
For Joomla only there was a bug which caused a PHP notice at the end of every backup step, saying that the MySQL connection has been closed. This was tricky but it has finally been addressed properly.
Improved cloud backups
The most important set of features in Akeeba Backup Professional is without a doubt its ability to automatically send your backup archives to cloud storage providers. In version 7 we have made several changes and additions to make your experience with this set of features smoother and support even more cloud storage options.
Our Amazon S3 integration now supports the new Bahrain and Stockholm regions. Moreover, it allows you to use the Intelligent Tiering, Glacier and Deep Archive storage classes for much cheaper data storage. Do note that the Glacier and Deep Archive options are incompatible with remote quotas due to reasons that have to do with the way Amazon S3 works when you use these storage classes.
Downloading a backup part file from Amazon S3 to the browser would sometimes result in the contents being displayed inline instead of having the browser ask you to save it. This has to do with the way Amazon S3 handles files when they begin with plain text instead of binary data. We addressed that in two ways: one which fixes files already stored in Amazon S3 and one which prevents the issue from reoccurring for newly uploaded files.
Likewise, Google Storage now supports the "nearline" and "coldline" storage classes for cheaper storage of infrequently accessed data. Remote quotas work fine with these storage classes.
We added the ability to download backup archives stored on Azure Blob Storage back to the web server or through your browser. This was an omission of the original implementation of this feature.
We created a new OneDrive integration which supports OneDrive for Business, including OneDrive accounts which are part of an educational or enterprise Office 365 subscription.
We improved our Dropbox integration to fully support Dropbox for Business accounts with shared team folders. You need to remember to tick the relevant box if you want to upload backup archives to your team's folders.
Regarding the SugarSync integration, you will now need to provide your own access keys following the documentation instructions. We will revoke the old, hardcoded keys over the next year.
Interface changes and improvements
The Joomla edition of our software adds preliminary support for Dark Mode. This uses a dark background and follows the contemporary trend of dark visuals in software. Due to lack of a fully functional dark template for Joomla we consider it experimental. Some things may display a bit weird.
On the Joomla front, we made several changes tracking the progress of Joomla 4 development. The backup status icon in Joomla's Control Panel is now rendered correctly, where you'd expect it to be, instead of being hidden away in a "3rd party" section under the fold. We also added support for Joomla 4's new Download Key management feature. In fact, we contributed changes back to the Joomla project based on our experience of ten years dealing with download keys (Download IDs, as we call them) and the user experience improvements we had implemented in our software some 5 years ago.
A final change pertaining only to Joomla has to do with the CLI scripts. We have created a more robust CLI script architecture which works under both Joomla 3 and Joomla 4, working around issues in Joomla 3 and the radical changes in Joomla 4. You will experience far less of the already rare crashes due to a Joomla issue on all supported Joomla versions.
We have converted all of the view templates of our backup software to (a subset of) the Blade template language which allows us to reuse some interface elements, as well as spot and resolve UI issues more efficiently. During this conversion we actually did spot and fix some minor interface issues.
We improved the error reporting when you are testing an FTP, FTPS or SFTP connection. We will give you much more informative feedback about what has gone wrong with it. Please note that due to PHP limitations some error conditions are still a bit mixed, e.g. we can tell you that either your password or username is incorrect, but we can't tell you which one it is.
The backup and log IDs will now follow the backup record ID you see in the left hand column of the manage backups page instead of restarting at 1 when you delete all backup entries in the Manage Backups page. This is a small change but it helps reduce a lot of confusion about which log refers to which backup in these cases.
We improved the performance of the Transfer feature in the Manage Backups page (the feature that allows you to retry uploading to remote storage). It will also give you much better feedback about what is going on and any errors which might occur, without having to hunt them down in hard to locate and read log files.
We drastically improved the information provided in the Remote File Management popup in the Manage Backups page. You no longer have to sit there and wonder if the backup archive files are being downloaded or something got stuck. You will be given a progress report. Improvements were made for the handling of some rare but problematic download cases. In case of error you will also be given the exact error message from the remote storage integration engine instead of having to hunt it down in a log file.
Changes to Akeeba Backup Core / Akeeba Solo Core
The Core (free of charge) versions of our software were always meant to only include the minimum number of features required to successfully backup, restore and transfer your site. The aim was to help hobbyist users and people who have just started out building sites experiment with their sites without an overwhelming fear that anything they do might result in all their hard work vanishing in front of their eyes. In other words, it was meant to help people who currently have more time than money to spend on their sites, therefore don't mind a bit of extra labor if it means they won't spend money. Moreover, the Core editions were meant to be easier to use than the Professional versions, catering for the less experienced users.
Over the years some Professional features had accidentally ended up in the Core version -- the accidental nature of the transition is why they were still listed as Pro-only in our product pages. This made sense neither for us nor the target audience of the Core version of the software. Giving less reason to users who can plausibly afford a subscription to buy one has had a negative effect both on the sustainability of the project as well as our ability to contribute back to the Joomla and WordPress community, either financially (sponsorships) or with our personal time. We hate freeloading off the community; it's unethical.
To this end we took the difficult decision to move the aforementioned features back to the Professional edition in version 7. The following features are affected:
- Integrated restoration. You cannot restore backup archives directly from the Manage Backups page of the Core version but you can still restore your backups for free using Kickstart.
- Site Transfer Wizard. You no longer have an option inside Akeeba Backup Core to transfer your site. You can still transfer your sites free of charge with Akeeba Backup Core, uploading the backup archive and Kickstart to the new site. The Site Transfer Wizard does not make site transfer possible, it merely copies the backup archive and Kickstart to a remote server for you. The whole site transfer is made possible with Kickstart and the installer script (ANGIE) inside the backup archive, something which has always been and always will be free of charge as explained below.
- Front-end legacy backup feature. This is what you'd use with your server's CRON jobs in conjunction with WGet or cURL or with third party scheduling services such as WebCRON. If you have a scheduled backup using this feature it will no longer work with the Core version. You can still take backups manually with the Core version, from the backend of your site.
- Remote JSON API. This is used with Akeeba Remote CLI, Akeeba UNiTE and third party backup scheduling and control panel services such as BackupMonkey, mySites.guru or Watchful. If you have scheduled backups with this software or services it will stop working with Akeeba Backup Core 7.0. You will need to purchase a Professional subscription to automate your backups with third party services. We understand this may be upsetting for some people; please understand that these services do not pay us for access to the JSON API so any fees paid to them for automation of your backups are going only to these companies. We only point this out because we have had some people contact us with the assumption that part of their fee goes to us; that is not the case. Also kindly note that unlike these services, our software only requires one subscription for an unlimited number of sites. The more sites you have the less you end up paying per site.
- WP-CLI integration (Akeeba Backup for WordPress only). Akeeba Backup Core for WordPress no longer supports WP-CLI. This feature has been moved to the Professional version. Considering that the WP-CLI integration in Core didn't support taking backups there was no reason for its existence in the first place.
We want to explicitly state that you could, you can and you will always be able to take backups of your site as well as extract and restore backup archives on any server (i.e. perform site restoration or site transfer) without paying us anything at all. Taking backups at the backend of your site, using Kickstart to extract the backup archives on any server and running the restoration script (ANGIE) which is contained in the backup archive to restore your site on any server, domain, subdomain or subdirectory are essential features we are committed to make available free of charge for as long as our backup software exists.
We understand that for some users the price of the first year of a subscription may be a bit too steep, especially at the end of the year when you need every last penny to buy presents for your family. We get it. We have families and little children too. We offer a special discount for all of you, as noted in the software itself:
Use the coupon code IWANTITALL to get a special 20% discount on the one-off subscription for one year or, at your option, subscribe instead to the 40% discounted, 3-month recurring subscription which you can cancel anytime.
Offer valid until February 29th, 2020 00:00 EEST and only for the subscription products AKEEBABACKUP, BACKUPWP and SOLOPHP. One coupon use per user. Our standard coupon terms and conditions apply.
This is a beta – but we encourage you to use it in production
The version we are releasing today, 7.0.0.b1, is labelled as a beta. Normally we warn our users not to use beta versions on their production sites. However, we strongly encourage you to install this particular version on your production sites. It's very well tested and doesn't have a significantly higher risk of bugs than a regular stable version. In fact, in this version we caught and resolved some weird bugs which were present throughout versions 6 and 5, i.e. between 6 and 48 months, but nobody had reported so far.
The main reasons for labeling this a beta have to do with the changes in the Core version and the timing of the release. We understand that the changes we made in feature availability of the Core version may require some of our users to upgrade to the Professional version. In some businesses and organizations it requires getting an approval.
Which brings us to the next reason, timing. We realize that this version is released just before the holiday season when people go on vacation, e-shops are busy fulfilling orders and there's not enough time to deal with the changes we introduced. Releasing a stable version 7, immediately discontinuing support for version 6, would be immensely disruptive to some users. We don't want to disrupt anyone's business. Quite the contrary! As a result we chose to release this version as a beta, continuing to provide limited support for version 6 in the meantime.
Why not wait after January? Well, we could do that but we reckon that would be disruptive. We'd be giving you zero warning about the changes in our software, essentially putting a gun to people's heads. That's not our intention. We want our users to have ample time to evaluate their options. We believe that a month to a month and a half is an adequate amount of time.
Therefore we expect the officially stable version 7 to be released between January 7th, 2020 and January 20th, 2020. At this point all support for earlier versions will cease.
Have fun and keep your sites safe with Akeeba Backup 7!
Update January 2020 – All the features that got implemented between beta 1 and stable
The article up to this point discussed everything we implemented in Beta 1 in early December 2019. In the following 2 months of beta and release candidate releases we implemented a lot more features and enhancements that are worthy of mentioning.
Custom description for backups taken with the Backup on Update plugin. This had been an obvious omission. Well, obvious once someone pointed it out. By default, the automatic description will tell you which version of Joomla was being updated when the automatic backup was taken.
Remove TABLESPACE and DATA|INDEX DIRECTORY table options during backup. These are very rarely used options in the context of web applications. In either case they are absolutely specific to the database server since they define paths on the disk where individual table data is going to be stored. These options don't make sense when transferring a site, or restoring it after a complete disaster, therefore they were dropped.
Obsolete backup quotas would fail to run on some sites. Newer versions of MySQL and MariaDB treat NULL and empty strings differently. Newer versions of Joomla changed the connection options to MySQL to no longer tell it to ignore the NULL and empty string differences. The end result was that obsolete backup quotas would stop working without an error for no immediately obvious reason.
Upload to OVH now supports Keystone v3. This will be mandatory starting mid-January 2020.
An error in an early backup domain could result in a forever-running backup. This seems to have been an issue since at least 2015 but would manifest itself very rarely. We finally got enough information to reproduce and fix this.
Common PHP version warning scripts. All of our software will now include unified messaging about versions of PHP that have entered their Security Support stage of life, have recently gone End of Life, have gone End of Life a long while ago or are not supported at all by our software. This will help you better plan your PHP updates.
Reinstated pCloud support. We gave pCloud access to a dev site of ours and they were able to find and fix the bug in their OAuth2 server which prevented our clients from using the pCloud integration.
Improved Dark Mode. We reworked the entire Dark Mode CSS and added the necessary tweaks to make it look even better. Do note that we treat Dark Mode as an accessibility feature, not a design trend.
Improved PHP 7.4 compatibility. PHP 7.4 went stable around the time we released beta 1. We are now using it as our default development version of PHP which let us identify and resolve numerous compatibility issues with it. None of them was causing functional issues but we fixed them nonetheless since we consider full support for modern PHP a very important feature.
Improved Joomla 4 styling. This is considered work in progress since Joomla 4 is still in active development and its CSS is far from being anywhere near final.
Clearer message when setting decryption fails in CLI backup script. Previously we stated that your PHP CLI didn't support encryption even when it was not the case (e.g. the decryption key had changed since you last saved the backup profile). The new messages convey the actual failure reason.
Removed all Javascript eval calls with calls to the JSON library. These were leftovers from a bygone era and triggering false positives in some malware scanners.
The database dump was broken with some versions of PCRE. Newer versions of PCRE, like the one used in Ubuntu 18.04 and later or most PHP 7.4 builds, silenty dropped support of a feature we were using in the new backup engine, causing database dumps to fail. We are now automatically detecting this and applying a workaround without any perceptible performance impact.
Site Transfer Wizard was broken on case sensitive filesystems. Sorry about that. Apparently updating the Mac which was used to run the tests changed its filesystem to case-insensitive, meaning we missed that bug. We changed our testing process to use a case-sensitive Linux machine instead.
ANGIE: Options to remove AddHandler lines on restoration. Have you ever restored a site on a different server only to find that it either not loads or downloads the .php file as text? That's because your site was using an AddHandler line to tell your old server which PHP version to use. These are server-specific and the new server did not understand it. Now you can remove these lines on restoration to prevent this kind of issue. You may still have to go to your hosting control panel and select the PHP version depending on your host and whether its default PHP version is simply too old to be usable.
Fixed OAuth authentication flow. A bug prevented authentication with some remote storage providers such as Google Drive.
Fixed fatal error under Joomla 3.8.x. There was a wrong bit of inline documentation about the deprecation status of some Joomla APIs used by Akeeba Backup. We accidentally used a version of them that's only available on Joomla 3.9, thinking they also exist in 3.8. The change was reverted.