Welcome to the fourteenth anniversary release of Akeeba Backup! How time flies... This release has quite a few improvements over its predecessor.
Akeeba Backup 7.3.0 would appear broken after upgrading from 7.2.2 or earlier. Many users complained that Akeeba Backup 7.3.0 wouldn't work after updating to it. We traced this problem down to missing media version query strings when loading the JavaScript files of the component. This caused the browser to load the cached files from the previous version. However, in 7.3.0 we rewrote the JavaScript from scratch. This created an inconsistency which manifested itself as making Akeeba Backup broken for everyone unless they cleared their browser cache. However, most browsers default to only clearing the last hour's cache which is not helpful in this context. This new version addresses this issue by adding back the correct media version query strings.
Removed the System - Akeeba Backup Update Check plugin. This plugin was an anachronism. It was relevant in Joomla 1.0 though 1.6 when Joomla wouldn't notify you of extension updates at all. It was still necessary between Joomla 1.7 and 3.1 inclusive because even though Joomla could notify you about update it wouldn't support paid extensions like Akeeba Backup Professional. Since Joomla 3.2 there was no longer a reason for this plugin. More so the last several years where you have third party services capable of notifying you about extension updates and even install them for you. We decided to remove the plugin altogether as it was no longer relevant and didnt justify spending time to maintain it.
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 the 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.
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. The Dark Mode JavaScript which was not used with our Joomla software is no longer being loaded. All of the JavaScript used for UI elements is now loaded defered and asynchronous of the rest of the page. All of these changes should reduce the first contentful paint time and the cumulative layout shift. In simple terms, our software will feel snappier, with less visual artefacts among different platforms.
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.
Loading all JavaScript defered. This is the conclusion of the JavaScript refactoring we started with Akeeba Backup 7.0 back in December 2019. Now all of the JavaScript files are being loaded defered which means that they start loading asynchronously after the page has finished loading. This improves the page rendering speed, especially on slower connections, and allows you to use stricter Content Security Policy settings on your site if you so wish.
Do not show the Backup on Update icon when Joomla is in record add / edit mode (main menu hidden and status bar locked).. If you use the Backup on Update plugin its icon would appear on all pages, even if you were editing or adding a record in an extension. Clicking on it in this case could cause the page to fail reloading and/or lose work you had already made on the page. We now hide the icon in these cases to prevent any mishaps.
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.
More clarity in the in-component update notifications, explaining they come from Joomla itself. We've had a lot of support tickets and bug reports about updates. The thing is, even though we show you an update notification inside our component the actual detection of new versions and their installation (extension update) are carried out by Joomla itself with code we have no control over. We have now changed the wording of the in-component messages to better clarify where this information comes from and what happens when you click the update button.
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.
Frontend backup URL does not work if the secret key contains the plus sign (+) character due to a PHP bug.
The frontend (a.k.a. legacy or WebCRON) backup URL works by issuing redirections to the next step of the backup
process. These URLs need to include the frontend backup secret key. We used PHP's http_build_query to
do that (through Joomla's JUri API). This is the recommended and “safe” method to handle URL building. However, due
to a bug in said PHP built-in function, if your key contained the + (plus sign) character it would not
be URL-escaped. The server converted the plus sign to a space on the next request and the backup immediately failed
with a 403 error – which is to be expected, since the key sent to the server is incorrect. We have now added a
special workaround for this case, using PHP's urlencode manually. Unlike http_build_query
this PHP built-in function works correctly. That was a real doozy to discover and troubleshoot!
Bug fixes and minor improvements. Please take a look at the CHANGELOG below.
-->We only officially support using our software with the latest Joomla! release branch, 3.9. We strongly advise you to run the latest available version of Joomla! for security reasons. Older versions of Joomla! have known major security issues which are being actively exploited to hack sites.
We offer limited support for Joomla 4.0 which is currently in Beta. Akeeba Backup will run on it, back it up and restore it just fine as of Joomla 4 Beta 3. Please note that since Joomla 4.0 is still in beta it may undergo potentially breaking changes between now and its final release. Joomla 4 specific issues are addressed when we are notified about them or observe them ourselves but they will not be treated as urgent until at least Joomla 4 Release Candidate 1 is released by the Joomla! project.
We only officially support using our software with PHP 7.1, 7.2, 7.3 or 7.4. We strongly advise you to run the latest available version of PHP on a branch currently maintained by the PHP project for security 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.
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 Joomla 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 Joomla adds support for it by end December 2020.
Please note that earlier PHP versions including but not limited to PHP 5.3, 5.4, 5.5, 5.6 and 7.0 are no longer supported and our software no longer works on them.