Akeeba Backup for Joomla! 3.2.b1 Beta

Released on: 2010-12-29 18:00 CST

Highlights of this release

Features marked with "PRO" are available in the Professional release only.

Joomla! 1.5 and 1.6 native. When Joomla! 1.6 RC1 came out, it broke (again!) the installation process for Akeeba Backup. Once more, we have updated our component to install and operate smoothly on the upcoming Joomla! 1.6 system. Moreover, Akeeba Backup supports sites wich have moved their libraries directory off the web root. In this case, the library files will be included in the archive, but you will have to move them to their final off-site location after restoring the backup. Please note that Joomla! 1.6 is not ready for production use yet. You should only use it on private testing sites.

Improved look an feel. Many people complained that the interface looked as if it came from another CMS. As a result, we have redesigned Akeeba Backup's interface to blend in with your Joomla! administrator template. The tabular views of the filters became more intuitive. Search and filtering was added to the Administer Backup Files page. Finally, we added an approximative progress bar to the backup page. Since it's impossible to predict how long the backup will take, the progress bar may jump back and forth a bit during file backup. This is not a bug, it is the expected behaviour.

PRO Amazon S3 multi-part uploads. Amazon recently announced that it is possible to transfer huge files in small chunks to their servers. Akeeba Backup 3.2.b1 introduces support for this feature, allowing single part backup archives and archive parts of up to 2Gb to be transferred to Amazon S3 without a risk of timing out.

PRO Settings encryption. On popular demand, all configuration settings are now encrypted using the industry standard AES-128 encryption scheme. This means that you can safely store sensitive information such as passwords in your Akeeba Backup Configuration settings. Note: You must have the mcrypt PHP extension installed. You can also disable encryption from the Component Configuration page if you wish.

PRO FTP Directory Explorer in practically every page requiring you to fill in FTP settings. This allows you to easily figure out the FTP directory setting without having to fire up an external FTP application.

PRO Remote (cloud storage) files management. Up till now you could store your backup off the server, i.e. in Amazon S3 or a remote FTP server. The downside is that the backup wasn't available any more on your server for immediate restoration. Akeeba Backup 3.2.b1 introduces the ability to fetch remotely stored files back to your own server. Moreover, it can delete remotely stored files or directly download them from the remote storage to your local PC. Only files stored on Amazon S3 and remote FTP servers are currently supported.

PRO Quotas for remote (cloud storage) files. The count and size quotas can now be applied to remotely stored files too. This allows you to force Akeeba Backup to maintain a preset maximum number of archives to the remote storage locations. Currently, only files stored on Amazon S3 and remote FTP servers are supported.

PRO Archive Discovery and Import. On popular demand, you can upload any ZIP, JPA or JPS file anywhere in your site and have Akeeba Backup import it in the "Administer Backup Files" page. Note: for security reasons, this feature won't work if you upload the archive in your site's root.

Changelog

This is a brief list of changes between Akeeba Backup 3.2.b1 and the previous 3.1.5 release:

New features

+ Amazon S3 multi-part uploads
+ Settings are stored encrypted with AES-128 (Professional release) using a site-specific key for maximum security
+ FTP Directory Explorer for the DirectFTP archiver engine and the "Upload to FTP" post-processing engine
+ FTP Directory Explorer for the integrated restoration page
+ The component-wide Parameters button is displayed in the Configuration page as well
+ Date conditional filter
+ Progress meter in the backup page. It's a little jumpy in the file packing stage, but it's better than nothing!
+ Backup sizes are now cached in the database
+ Akeeba Backup now records where it has transferred the backup archives to
+ Download backup sets from remote storage locations (FTP, S3, ...) back to the server
+ Delete backup sets stored in remote storage locations
+ Download backup sets from remote storage locations directly to your PC
+ You can now insert any kind of filters in the tabular view of Files and Directories exclusions
+ You can now insert any kind of filters in the tabular view of Database Tables exclusions
+ Added search and filtering to the Administer Backup Files page
+ Archive discovery and import
+ If you put your Joomla! libraries in an off-site directory, Akeeba Backup will detect that and include them automatically in the backup set
+ Use of secure Download ID instead of username and password for live updates of the Professional release
+ The component configuration button is now in the cPanel to make it more obvious to new users
+ Quotas can now be applied to remotely stored files. S3 and FTP supported for now.

Updated features

~ The DropBox engine will attempt to upload the file again in case of a soft error (e.g. network connection issue) to reduce the chance of failing the upload e.g. when the host delays the SSL initialization
~ Localization of the warnings printed when jQuery is not loaded or the media/com_akeeba folder has wrong permissions
~ Simplified the interface to follow Joomla! styling standards more closely
~ Removed "Download" button from Administer Backup Files page as it doesn't make sense in multipart archives. Use the download links on the right of each backup row instead.
~ Made clear in the integrated Restoration page that you can restore directly to remote servers

Bug fixes

# The Lazy Plugin would not save the backup record properly due to a race condition (different user triggering the backup and triggering the first backup step)
# JSON API: Wouldn't backup with anything but the default profile
# JSON API: Downloads were completely broken
# AKEEBA_JVERSION wasn't defined in the front-end causing backup errors
# PHP notices were causing the backup to fail when display_errors = On in your php.ini file
# Wrong file listing returned by the engine for multipart archives with a part count of 1
# Password fields in post-processing engines were rendered as plain text boxes
# Bug when deleting profiles: it would always make the default profile active
# The Configuration Wizard would fail cold on servers where max_execution_time is 0
# S3: Using time variables in the directory name caused each part to be uploaded to a different directory
# Upload to remote FTP: Using time variables in the directory name caused each part to be uploaded to a different directory
# Dropbox: Using time variables in the directory name caused each part to be uploaded to a different directory
# Azure: Using time variables in the directory name caused each part to be uploaded to a different directory
# File and Directory exclusion wouldn't work with PHP 5.1.x
# Joomla! 1.6 RC1 introduced API changes which cause many sections of the component to cease working
# altbackup.php wasn't working on Joomla! 1.6
# Excluding extensions would fail if error reporting is E_ALL and you're using the Mac platform
# Typo in line 298 of platform.php could cause a fatal error in command-line backups if a date/time tag wasn't used for archive naming
# All Professional edition views could throw Javascript errors if certain characters where included in translation strings, URLs or data items (e.g. passwords, regex filters) accessed on those pages
# Javascript errors thrown if brackets ([, ]) are included in translation strings, URLs or data items (e.g. passwords) appearing in any Akeeba Backup page
# ABI: Database restoration would fail if the absolute path couldn't be calculated properly
# ABI: Configuration sometimes not read if the absolute path couldn't be calculated properly
# Joomla! 1.6's ACL checks would throw off older PHP versions as they didn't understand the FactoryClass::getObject()->method() syntax.
# Database only backup could hang on some servers due to a runaway PHP Notice
# Akeeba Backup would believe that the archive existed locally if it was removed after uploading to remote storage
# The JPS encryption key field in the Configuration page was a plain text instead of a password field
# The JPS encryption key would be blank in all backup origins (i.e. CRON, front-end, XML-RPC and JSON API) except the back-end backup.
# Some translations for the back-end backup notification module wouldn't get installed properly
# Sometimes the front-end backup emails contain literal \n instead of newline characters