Hey guys I really need to implement the zip system into coppermine.
I have checked the standalone version they have a file like this
--see below --
Can somebody take a look and make up a quick fix for cpg please?
I need to add it to the gallery just above the movie stripe
If somebody wants to build it custom for me I am also willing to pay for it
Thanks

define('IN_COPPERMINE', true);
define('THUMBNAILS_PHP', true);
define('INDEX_PHP', true);
require('include/init.inc.php');
include ('include/archive.php');


// zipdownload allowed, go ahead...

$filelist= array();

if (count($FAVPICS)>0){
$favs = implode(",",$FAVPICS);

$select_columns = 'filepath,filename';

$result = db_query("SELECT $select_columns FROM {$CONFIG['TABLE_PICTURES']} WHERE approved = 'YES'AND pid IN ($favs)");
$rowset = db_fetch_rowset($result);
foreach ($rowset as $key => $row){

$filelist[] = $rowset[$key]['filepath'].$rowset[$key]['filename'];

}


$flags['storepath'] = 0;
$cwd = './albums';

$zip = new zipfile($cwd,$flags);

$zip->addfiles($filelist);

$zip->filedownload('pictures.zip');
}

btw I dont need a favorite pic download but all pics in each album - only the full size ones.

Thanks

ASAP = short notation for "Any System Approved Program" ?

If so no-one built a ASAP ZIP script for Dragonfly yet

no sorry
ASAP short for as soon as possible
I am willing to pay for it if any of you can code it custom for me
Going to use it on linux dedicated servers (Red Hat Enterprise)
Currently using 8.3 cpgnuke with GD2

So you want a option to backup all "big" images on a album basis ?

exactly.
and add a link somewhere for example above the movie stripe that reads:
"Download this album complete here"

No luck with this guys?
I will pay $100 paypal or epassporte to whoever can hook me up with a solution
or donate it to the site if it's done by a member of the team
It needs to work with the 8.3 cpgnuke version
and please work on it guys
it's not such a difficult thing for you!
the zip funtion can be server side implemented with the zip module or done by php and you already have that coded by the coppermine standalone team

Hit me up on ICQ 333548380 or messenger at jovigirl @ eresmas.com

jovigirl wrote:

No luck with this guys?

No offense, but while I think this feature has some use, it's a bit much to expect someone to jump right on it. There's still a lot of work to be done on the core, as well as rolling out higher priority features and enhancements. Patience is a virtue.

The other issue would be that development is really focused on Dragonfly (9.x), and not on the 8.x code. New features from the team are going to go in the current version. Unless you want to hire a code mercenary to do it for you...

jovigirl wrote:

I will pay $100 paypal or epassporte to whoever can hook me up with a solution or donate it to the site if it's done by a member of the team It needs to work with the 8.3 cpgnuke version

Offering a nice carrot makes it easier to get coders, yes.

jovigirl wrote:

and please work on it guys it's not such a difficult thing for you! the zip funtion can be server side implemented with the zip module or done by php and you already have that coded by the coppermine standalone team

I took a look at the Coppermine 1.3.2 code and I think you've made a few incorrect assumptions.

First, if I'm reading the DB query correctly, Coppermine 1.3.2 only implements ZIPping files selected in the Favorites table, which I don't even think CPG-Nuke or Dragonfly implement. I think your intent is to be able to ZIP on an album-by-album basis, which would seem to have utility.

The "zipdownload.php" code is useless as a starting point for a number of reasons. First, if I'm reading the manual correctly, PHP only supports ZIP read-only access natively (assuming it was compiled in). You'd have to support writing archives, either by making a system() call or adding a class. Coppermine 1.3.2 goes the latter route and adds support classes in "include/archive.php". Looking at that, it appears to build the ZIP data structures in memory, and seems to be pretty rudimentary. It might be entirely suitable to the task in terms of efficiency and speed, I'm not really able to qualitively judge it.

Next, the code creates the ZIP each and every time someone clicks the link. This is terribly resource-intensive and wasteful. If the archive's created entirely in memory, and you're ZIPping up a lot of large graphics... you could starve out the server's memory really, really fast. Probably a lot faster than any of us would care to think. Ideally, the process should check to see first if the archive exists, then check to see if the archive is older than the newest picture in the gallery. If both of those conditions are true, it should create the archive and save it to the album (let's say in "albumname/.archive/album_name_date.zip" or something similiar to keep the zip handy, but out of the way of the album indexer). This adds considerable complexity to the checking routines and file I/O that are not extant in Coppermine 1.3.2 currently. The best solution to this may be very well to create the ZIPs outside of the structure of the CMS with a cron script (PERL could do this easy as PI) and just create links to the location of the ZIPs (the CMS could check to see if the file exists first as a cheap and easy way of enabling/disabling downloads, and maybe display how out-of-date or fresh the archive is).

There's the not-inconsiderable problem of running up against max_execution_time, or eating up the space in /tmp creating the ZIP, or in /albums writing it out for reuse. All conditions which need to be considered and handled.

I'd think that the feature should have at a minimum a global configuration setting to enable/disable it, if not both a global and per-album configuration. Either of which would require additional work on the various control panel interfaces and the DB.

Finally, proper error-checking and user input validation would need to be performed in order to stack up to the project's coding standards.

Having said all the above, I think the feature request has merit, but the scope of the effort is more than just a simple port - as I don't think that Coppermine 1.3.2 is really doing what you want, and I'm pretty sure it's not doing it well. As it stands, I could see turning on this feature could very well devastate the performance of a host. Doing it roight is probably well worth the $100 bounty you've offered.

DJMaze wrote:

So you want a option to backup all "big" images on a album basis ?

RAOTFLMAO. Dude.

To summarise darkgrue: This is both difficult and a bad idea.

Still for 96 bucks, it's tempting; just so long as my host doesn't allow it on -my- server.

Actually it shouldn't be too difficult, let's see I can have "many" albums each with "lots" of "big" pictures. Times that by "several" users doing this, say for the sake of argument, "many" times per day. Now subtract ...

I can write on a "per image" basis.
A whole album is a whole different story, as darkgrue said.

Being more helpful now

Perhaps won't be so bad. It would need a couple of album settings, one for choosing whether to zip or not and one to define the size of a "big" image, maybe defaulted to 1Mb.

Then you could add the zip functionality to the picture loading routine, so that when a picture is loaded, if zip=yes and size >= "big" the image is zipped. That way there is some control over the number of compressions, with a maximum of one zip per "big" picture in the album.

The draw back is that the zip settings for an album couldn't be changed after the album was created.

You would then have to decide whether a downloader was forced to take the zipped image or if you’d offer a choice. I suggest that the former is simpler and saves space because the original image can be deleted (after a thumbnail was taken for display purposes).

ZIPping images for download on a per-image basis would be pointles... unless your gallery contained a lot of raw-format pictures. Bitmaps, and the like. JPEG and GIF wouldn't benefit so much.

ZIP (like most compression algorithms) is really bad at re-compressing compressed data. You'd only end up with a file that was more or less the same size (might be a little smaller, could even be bigger).

In my opinion, the real advantage to ZIPpping would be to allow users to retrieve a large number of files all at once, rather than navigating and saving each picture at once, with the archive being a convenience to send it all as one bundle-file. But there are issues with that, as we've already mentioned...

Yes, that's a fair comment.

I didn't think the request was for grouping but rather compression of "big" images, but that might actually be "big" albums instead. I have no idea if the files will actually be reduced much. Even a few percent might make it worth it for high volume downloads.

Having re-read it I think that you're right. Perhaps this could be done for read-only albums where the album was zipped during the album locking routine.

Quote::

In my opinion, the real advantage to ZIPpping would be to allow users to retrieve a large number of files all at once, rather than navigating and saving each picture at once, with the archive being a convenience to send it all as one bundle-file

This is exactly the idea

I am no php guru at all
but I think the process could be something like SELECT images where album = (the album # from the query string) & approved = yes & size = big
then something like "get path for every image"
save a copy to some folder with 777 permissions (there could be a "zip" folder created inside the default albums directory)
zip files and insert the zip archive into that folder
remove all copied images
remove zip after downloading (optional since it can be done via a cron script or in other ways)

Thanks for at least thinking of it
The $100 bid stands.
I know you are currently working with the dragonfly version, but I dont think it will be too difficult to make a script that will wok for both cpgnuke and dragonfly since it only has a database query that can easily adapted to both versions
Correct me if I am wrong.

Thanks everyone

jovigirl

DJMaze wrote:

I can write on a "per image" basis. A whole album is a whole different story, as darkgrue said.

I would be interested in that