Removed support for Internet Explorer. We have removed support for Internet Explorer from our CSS. IE11 will still work with our software but it will always be displaying its mobile view, even on desktop. Microsoft has already announced that it will stop supporting IE11 in Microsoft Teams beginning November 30, 2020 and terminate all IE11 support in August 2021. We decided to remove IE support starting September 2020 because it was adding unnecessary bloat to our code and prevented us from implementing features we needed. Not to mention that this seven year old browser is barely used anymore.
Inherit or set a base font size instead of defining a fixed one. In the past, our software was setting a base font size of 12.5px. While this is a fairly reasonable size for able bodied users on most desktop and mobile displays it doesn't work well for users with accessibility requirements necessitating a bigger font size or users who otherwise need scaled text for any reason. We changed our CSS framework to inherit the document's base font size to mitigate this issue. Akeeba Solo users can also set the base font size in their user profile. If they don't, the browser's default base font size will be used.
Improve default header and body fonts for similar cross-platform "feel" without the need to use custom fonts. Our software used to require two custom fonts Montserrat and Open Sans for header and body text respectively. These fonts were not shipped with it to maintain a reasonable download size. As a result, we fell back to using your platform's default sans-serif font which would sometimes not be the best choice for readability. We are not using your platform's preferred fonts for UI headers and body text, giving our software a more readable and native appearance.
Rendering improvements. We have made a number of changes in our CSS framework to optimize the speed at which pages of our software render. We optimized the custom font loading so it's not a blocking operation. Some UI elements were absolute pixel sizes have been upgraded to use relative sizing to better fit different sized screens.
Added feature to "freeze" some backup records to keep them indefinitely. It used to be that Quota settings were an all-or-nothing affair. Akeeba Backup would simply delete backup archives beyond the configured quotas and that would be it. But what if you have an important backup archive you need to keep forever? For example, the last backup before applying a site redesign, or a backup before you uninstalled an extension and delete information you might need in the future. Enter Frozen Backup Records. You can now set a backup record to Frozen and Akeeba Backup will ignore it when applying the backup quotas. You can manage the frozen / thawed status of a backup record from the Manage Backups page.
Amazon S3: Add support for Cape Town and Milan regions (Pro version). We updated our code to support the newest Amazon S3 regions.
We adjusted the size of control panel icons. The change regarding the base font size could make the text under the control panel icons a bit cramped or cause visual artifacts regarding control panel icon positioning. This change addresses those visual issues.
Now using WordPress' wp_options table to save the system configuration information instead of a file (Akeeba Backup for WordPress). Akeeba Backup for WordPress and Akeeba Solo share a lot of common code. Part of that was the implementation for the System Configuration settings. In the past both software was using a file to store that information. However, this doesn't make much sense in WordPress where we are guaranteed to have a database connection provided by WordPress and a table to store options. Therefore we have now moved all of these settings to the wp_options table.
Using WordPress' nonce system instead of our legacy anti-CSRF token system to avoid “invalid token” errors on some hosts. (Akeeba Backup for WordPress). Akeeba Backup for WordPress and Akeeba Solo share a lot of common code. Part of that was the implementation for the anti-CSRF token (nonce) used to validate requests within Akeeba Backup for WordPress. While our implementation is much more secure than WordPress' it also requires a PHP session which WordPress doesn't provide by default. This wouldn't be such a problem but for WordPress-specific hosts relying on that little "quirk" of WordPress and decide to not configure PHP session support properly. This would cause Akeeba Backup for WordPress to fail on some hosts. We are now using WordPress' nonce system which, despite being less secure, is well supported on all WordPress-specific hosts.
Improved automatic configuration for scheduled and remote backups to work around some weird wp-config.php implementations. (Akeeba Backup for WordPress).
When running a backup outside of WordPress (frontend backup URL, CLI backup script or JSON API) we still need access
to WordPress' database to read configuration settings and, of course, backup WordPress' database itself. This
information is stored in the wp-config.php file. However, that file is also a boot up script which tries
to include other parts of WordPress, only meant to be loaded when processing a WordPress requests. As a result we
cannot include it directly. In the past we had special code to locate and extract this configuration information but
it would fail on some less common WordPress setups, e.g. when there was a big if-block to apply different values in
development and live sites. We are now doing in-memory editing of the file contents to remove the code that included
too much of WordPress and have PHP load and parse the modified file, allowing us to better cater these less common
WordPress configurations.
Improved the custom PHP detection code during restoration. Starting with Kickstart 7.0.1 and Akeeba Backup 7.2.0 we are detecting when you are applying a custom (non-default) PHP version through a .htaccess file at the beginning of a restoration and carry it over throughout the restoration. This code has a few issues, e.g. when the AddHandler/SetHandler code in the .htaccess had leading spaces. Moreover, trying to apply these custom PHP version lines on the restored site's .htaccess could fail in some cases, leading to a mysteriously non-functional restored site. These problems have been fixed.
Fetching back to server the archives from these provides would result in invalid archives: Amazon S3, Backblaze, Cloudfiles, OVH, Swift (Pro version). There were some cases where retrieving large backup archives from remote storage could result in an off-by-one error, corrupting the archive. This issue has been fixed in this version.
Backing up database views could result in invalid SQL in very rare cases.\ When backing up a view whose definition contained the string literal ' view ' (the word view, case-insensitive, surrounded by spaces) would result in an invalid SQL statement at backup time. The problem was a greedy regular expression used to pre-process the SQL statement returned by MySQL and is now fixed. Although not observed in the wild, a similar issue would occur with triggers, procedures and functions containing the respective keyword surrounded by spaces in its definition. This has also been fixed preemptively in this version.
Fatal error when trying to use a non-existent profile. This could happen if the active backup profile was deleted by another user or when trying to run an automated backup with a backup profile you had already removed.
Fixed timestamp in default backup description. The date and time included in the backup description (not the backup filename) was always in UTC instead of the user's timezone.
Backup-on-update must-use plugin was not removed from wp-content/mu-plugins on uninstallation (Akeeba Backup for WordPress). WordPress' plugin uninstallation code does not automatically remove associated mu-plugin files. This would be a problem when you tried updating WordPress manualyl after removing or disabling Akeeba Backup. You'd get a 404 error and the update would fail because of the leftover plugin. This issue has now been addressed.
Access Denied if you rename your user account and change its user ID with some third party tools after having already used Akeeba Backup for WordPress (Akeeba Backup for WordPress). There are some third party plugins which allow you to rename or change the ID of your WordPress user account. However, the user ID was part of the information stored by Akeeba Backup to remember your preferences between page loads. This would end up with your user not having any privileges to take any action in Akeeba Backup for WordPress, including viewing its Control Panel page. We are now avoiding storing the user name or ID in the database and give you the option to reset the temporary storage if an error occurs, from the error page itself.
Bug fixes and minor improvements. Please take a look at the CHANGELOG below.
We only officially support using our software with PHP 7.1, 7.2, 7.3 or 7.4.
While our software still runs on PHP 7.1 we are no longer testing our software with this PHP version or consider it an actively supported environment for our software.
We strongly advise you to run either of the two latest available version branches of PHP on a branch currently maintained by the PHP project for security and performance reasons. Older versions of PHP have known major security issues which are being actively exploited to hack sites and they have stopped receiving security updates, leaving you exposed to these issues. Moreover, they are slower, therefore consuming more server resources to perform the same tasks.
At the time of this writing we have only done some preliminary PHP 8 compatibility testing for the backup engine, PHP 8 being in alpha. We expect to be able to fully support PHP 8 around 2-4 weeks after WordPress implements full PHP 8 compatibility. PHP 8 itself is scheduled for release on November 26th. Our prediction for full PHP 8 support is before the end of January 2021, as long as WordPress adds support for it by end December 2020.
Kindly note that our policy is to officially support only the PHP versions which are not yet End Of Life per the official PHP project with a voluntarily extension of support for 6 to 9 months after they become End of Life. After that time we stop providing any support for these obsolete versions of PHP without any further notice. New version branches of PHP will be supported experimentally starting sometime during their Release Candidate phase and fully about 4 to 8 weeks after the first stable version of that branch is released.
We officially only support the latest WordPress 5.x release.
Our software should also work on WordPress 4.9 and ClassicPress 1.x since we do not rely on any features added in later WordPress versions. However, we no longer test against these versions of WordPress / ClassicPress and do not consider them supported environments for our software.
We fully support single site and multi-site installations of WordPress. Multi-site installations can be converted on restoration from directory-based to subdomain-based or vice versa. You cannot restore a single site backup into a multi-site installation. You cannot restore / convert a blog of a multi-site network installation into a single site WordPress installation (in fact, there is no official WordPress method to do that safely).
Using our software with versions of WordPress earlier than 4.9 may be possible but we cannot provide any support for them. Furthermore, we very strongly discourage using our software with WordPress versions earlier than 4.6 because some WordPress features we rely on for our software to function properly did not exist in these very old, End of Life versions. We generally strongly advise against running old, no longer maintained versions of WordPress for security and performance reasons.
We are actively supporting Joomla 3.9 and 4.0. Joomla 4 support is considered experimental since it is still in beta.
Akeeba Solo should be able to back up and restore sites running on Joomla 1.5 or later. However, some of the restoration features in the Site Setup page may have no effect on sites older than Joomla 3.6. We recommend against using obsolete versions of Joomla. We do not test against them anymore and they include known security vulnerabilities which make them unsuitable for use on production sites.