Detection of zlib causes a fatal error in some environments

It works on my 5.3 installs. I'm guessing that the issue is something else in your setup. Do you have access to your apache error logs? Is there anything listed in there that might help me track down what's happening.

Also, be very careful using this module on IIS. The backup files are protected from direct download by a .htaccess file which does not work on IIS. This means that your backups may be publicly downloadable on IIS. I do not recommend storing backups to server with IIS with the current version. Future versions will allow you to save backups to other locations which will allow you to backup to a directory outside your web root.

Same problem here:blank page. Same version of Drupal on both testing and QA server, 5.3.

Testing server (Everything works fine):
Apache/1.3.33
MySQL database 4.1.22
PHP 5.2.2

QA server (blank page):
MySQL database 5.0.45
PHP 5.2.4
Apache/2.2.4

The QA is on a shared server where I only have access to a limit portion of the error log. But there is nothing listed there about the problem.

Which version of MySQL do you develop against?

I develop on Mac OS X with PHP 5.2.1, Apache 1.3.33 and MySQL 4.1.22, but I have it successfully running in production on MySQL 5.0.45 with PHP 5.2.4 on Apache 2.2.6.

I'm not seeing a common factor here. Are you able to adjust memory limits and timeouts? I can't imagine the main page running afoul of resource limits, but I guess it couldn't hurt to try.

If you try to access the other pages of the tool (admin/content/backup_migrate/restore, admin/content/backup_migrate/files, admin/content/backup_migrate/schedule) do you get blank pages or is it just the main tab that's causing the issue.

admin/content/backup_migrate - White Screen

admin/content/backup_migrate/restore - works!

admin/content/backup_migrate/files - works and both the 'files/backup_migrate' and 'files/backup_migrate/manual' directories were created.
admin/content/backup_migrate/files/scheduled - works, files/backup_migrate/scheduled created

admin/content/backup_migrate/schedule - works

admin/content/backup_migrate - still white screen (thought I'd try again after all of the above worked)

Account is on shared hosting so unable to adjust memory limit. Currently it's set at 32M.
How do I check timeouts?

I just want to note that I'm having the same problem. It seemed to work great with XAMPP on my desktop, but when I tried to install the module to a clean Drupal 5.3 on the production server I get the 500 error at admin/content/backup_migrate. A bunch of other modules I installed at the same time are working fine. I should note that the desktop installation was also upgraded to 5.3 and BackupMigrate worked ok.

It seems like we may have some different issues here. I'm retitling this at the risk of confusing existing people tracking this thread in the hopes that it helps clarify things for people of the future. (Hello future beings).

This module definitely works in 5.3. We've run it on Windows, Mac and Linux (and possibly FreeBSD - not positive about that, though.). Likewise, there are several real-live sites using this module successfully that are 5.3 sites.

That being said, there must be some hosting configurations that have issues. It seems like it may be a resource limit (except in the 500 error case - there might be something else there). The one common thread in our sites running this module is that they all tend to have relatively serious hosting packages (e.g. a VPS or dedicated box or are extremely low-traffic high-powered shared - like our dev boxes). They also all probably run PHP 5 (and I know at least one early version of this module didn't work in PHP4 - not sure if that's still the case, though). I think we've got a smattering of Apache versions there as well, but most are probably 2.x.

So - in an effort to help troubleshoot this, can people having this problem run a phpinfo() and send in the URLs? This feels like a needle / haystack issue - so help looking through the phpinfo's would also be great. We're going to be looking for some common thread through several cases, and it's probably going to have to be a group effort to spot it.

It's worth it, though. It's a nice module - definitely helps simplify development tasks (at least for me).

Drew

This might help, but I'm no expert so it might be a red herring.

By a process of elimination through commenting out code the line that causes the white page is 237

if ( @defined( "ZIPARCHIVE::CREATE" ) ) {

Removing the "@" reveals the following error:

Fatal error: Class 'ZIPARCHIVE' not found in backup_migrate.module on line 237

Commenting out the if block on lines 237-239 enables backup_migrate_backup() to render correctly.

According to PHP manual, this constant is defined in zlib, I have phpinfo'd and tried defined( "ZIPARCHIVE::CREATE" ) on as many different PHP platforms as my client portfolio would allow and there's only one that throws the fatal error:

              zlib       zlib
      PHP     compiled   linked
Ok    4.4.7   1.2.3      1.2.3
Ok    4.4.7   1.2.1.2    1.2.1.2
Ok    5.1.2   1.2.3      1.2.3
Ok    5.2.1   1.2.1.1    1.2.3
Fail  5.2.4   1.2.1      1.2.1

I couldn't see any other obvious Zip related differences (some had --enable-zip, some didn't, some had a Zip section in phpinfo, others didn't) so perhaps it's the version of zlib?

If nothing else this hopefully will give people something to chew on.

In the meantime commenting those lines out works just fine for me.

meerkat: thanks for your hard work tracking this down. Sounds like this is the most likely cause of the blank screen. I'll have to find another way to detect if I can use the zip functions (or jettison that functionality altogether).

Thanks again for all your hard work documenting this

r

I've changed the way the module detects the availlablity of the zip library. This should hopefully clear up these problems.

If you could all download the latest dev release and reopen this issue if this does not fix the problems you've been experiencing.

Thanks for all your help figuring this out, everybody.

R

Great Job! Problem is gone!

Yeah that worked for me too. Thanks!