JoomlaPack version 2 onwards is not compatible with Joomla! 1.0.x anymore. In order to use JoomlaPack on those sites you'll have to install the earlier JoomlaPack versions in the 1.2.x range. At the time of this writing the latest published version was 1.2.3.

As long as the Joomla! team continues to officialy support Joomla! 1.0.x so will we for JoomlaPack 1.2.x. Do not expect any new features being implemented on that version, though. The JoomlaPack 1.2.x branch is now in maintenance mode and only severe bugs and security issues will be resolved and rolled out as new versions.

Update - July 2009: Joomla! 1.0.x is no longer officially supported by the Joomla! team. Therefore, we cease active support (bug fixing) on JoomlaPack 1.2.x. You are welcome to report any issues you may have, but a solution is not guaranteed.

By default, JoomlaPack uses AJAX to process the backup steps. There are some instances, though, where AJAX doesn't work as intended. Such cases might be:

In order to resolve this, you should try using the JavaScript Redirects mode.

If you are sure this is not one of the aforementioned cases, first check out the support forums at http://forum.joomlapack.net. If you do not find a relevant entry in the forum, then start a new thread. We will answer to you as soon as we can (usually, it takes 1-3 days, at most a week).

This is, again, a matter of AJAX compatibility. Take a look at the previous question.

	Tip
	The JavaScript Redirects mode is not only applied to the backup process. If you select it, the filters pages will also work in the (slower but compatible) JavaScript redirects mode.

This error masks a system or PHP-level error. We can't be certain what it is, but there are a few ideas you can try:

If this doesn't work for you, ask your host for access to your server's error log. Do note that most hosts give you access to the access log, which is a completely different and - for our purpose - not useful thing. Please start a new thread on our support forum and a. copy & paste the last ten lines of the host's error log b. put in a ZIP file and attach JoomlaPack's log (downloadable from the View Log page, see the flashing link on the top of it) c. write a clear and concise descriptions of what you've done so far and what the problem is exactly. If you have to attach screenshots to help us understand, by all means do so.

There are two possible causes:

In the rare event that you have files with permission settings that do not enable your web server to read them, JoomlaPack can't access them and therefore can't pack them either. This might happen if you upload your files with FTP and don't change the permissions manually. In this case, you should also experience malfunctions on your Joomla! site prior to using JoomlaPack. Sometimes, you can have directories with wrong permissions and files with correct permissions, which makes things a little more complicated, because Joomla! works fine but JoomlaPack doesn't. As a general rule of thumb, the minimum permissions to be on the safe side are:

There will also be missing file when the backup fails.

Sometimes, your archive may appear to be missing files but in fact all files are in there. Read the next entry for details.

This is not a yes or no question. The situation is somewhat complex and requires a little bit of technical explanation. If you want the executive summary, JoomlaPack is unable to produce valid-looking ZIP files under certain configurations. However, the data is intact and you can extract the archive if your archiver software can be set up to ignore CRC errors in the archive. Alternatively, you can use the unzip.php script from the JPA Utils package.

And here goes the technical explanation. The ZIP archive format specifies that a CRC32 checksum must be stored for each file included in the archive. PHP before version 5.1.2, only had a CRC32 calculation function for in-memory data. As a result, JoomlaPack had to read the entire file to memory to calculate its CRC32 hash. However, due to memory consumption limitations imposed by PHP configuration, this is usually not possible for large files. "Large files" for PHP usually means anything over around 1Mb. A workaround was attempted but it was not successful, since PHP is a typeless language and the required bitwise arithmetic could not be performed.

The effect of all of this is that a dummy CRC32 value is stored for those files. Archiver software, adhering to the ZIP standard, check the CRC32 for each file they try to extract and when they come to such a file with a dummy CRC32 they think that the archive is broken and omit the extraction of the offending file. In fact, the file data is correct, the CRC32 is wrong. Some archiver software can be configured to ignore CRC errors and the ZIP will extract just fine.

Since PHP 5.1.2 there was the hash extension available. This PHP extension provides a method for quickly and accurately calculating any file's CRC32 without having to read all of it in memory. In systems with PHP 5.1.2 or better with the hash extension available, JoomlaPack will produce correct ZIP files, adhering to the ZIP standard.

Please note that this is a PHP limitation, beyond our control. We are not irresponsible, releasing a software which doesn't work. The current behaviour is a compromise between required features and technical possibility.

If you really want to extract your ZIP archive you can use our unzip.php command-line script, or the desktop application JoomlaPack eXtract, available for Windows only.

If you used the Download button / links in the component's backend to download your file, it is possible that your browser corrupted the file. For example, all versions of Internet Explorer up to and including 6.0 (before SP1) corrupt the downloads, against all web standards and best practices. If you used FTP to download your backup archive, it is possible that your FTP client was set up to download files in ASCII or AUTO file transfer modes, eventually corrupting your backup archive.

You can overcome this problem by downloading your backup archives using your favorite FTP client, set up to forcibly download files in BINARY mode. If you are looking for a decent FTP client, give FileZilla a try. It's our favored, cross-platform, Free Software FTP client. You can select the transfer mode either in the server connection settings or from the menu just before downloading a file.

There is a compatibility issue with GoDaddy hosting and JoomlaPack, causing dropped database connections. You can enable the "Force database keep-alive during long operations" option to circumvent this behavior. You may also switch to creating JPA archives from the JoomlaPack Options page to further limit the strain put on the server and decrease the probability of failed backups.

Some hosts also proactively halt script execution if they suspect a DoS (Denial of Service) attack. The pattern of normal JoomlaPack operation “too many and frequent hits on the same webpage“ is similar to that of a typical DoS attack. Combined with the long time of the script execution, it might lead some hosts to believe that they are under attack and start blocking the script execution after a while. We have no solution to this problem, because it happens outside the realm of PHP where this software exists.

Your site is not down, it will come back online at most within an hour.

What happens is that most hosts expect you to run a lightweight CMS which performs a few queries per request and that your site is not too popular. Therefore, they impose a maximum number of SQL queries your site can execute within the hour. JoomlaPack needs to read and dump all of your database. If you are on a fast server, this will happen with a very small number of steps and queries. If you are on a dead slow host, however, this has to be done with more queries to the database server, eventually reaching your queries limit.

You can try to "fix" this by doing all of the following:

Before asking this question, have you really tried all of the troubleshooting steps in the documentation of the Backup Now page? 9 out 10 times these are sufficient to resolve your problems. A certain degree of self-help is mandatory, otherwise you will be just wasting your time, as you might be eventually instructed to follow these steps.

First, check out the support forums at http://forum.joomlapack.net. If you do not find a relevant entry in the forum, start a new thread. Do not forget to attach a copy of the plain text JoomlaPack log (downloaded from the View Log page, clicking on the link - do not copy and paste from the text area in this page!). Please zip this file before attaching it to the forum. Support requests without a debug log will waste your time; if it comes down to needing developer's assistance I will ask you to attach it anyway and you'll have just lost a day's worth of response time. Also tell us the exact version of Joomla!, MySQL and PHP you are using. Yes, these are important values, I will have to ask you to provide them eventually.

We will get back to you as soon as we can (typically, it takes 1-3 days, at most a week; most posts are replied within the day, depending on our availability). Again, please make sure you have read the troubleshooting instructions given in the "Backup Now" page's documentation on this User's Guide and the support request submission notes posted as sticky notes in the forums pages. We do not want to seem picky about this, but following these simple rules helps us help you better and faster. Thank you!

If you want to contribute to the project, you have many different options, depending on your skills: