Hi,
I've been rewriting these plugins and modules, as a lot has changed over the years.
First, the File::[copy/etc] routines *should* be installed with perl on your Unix machine. If you are *NOT* running Unix (of some sort) there *are* going to be issues. Windows is *not* Unix, and M$ has tried their hardest to make it _HARD_ to do, trying to keep control over the world. ActiveState Perl has some issues of compatibility, I've only been able to get it to run on 1 of my 3 windows machines over the years. Apple, well, to quote a well known character from a old sitcom "I know Nothing, NOTHING."
GT has rewritten/imported the ::Image routines, and you do not need to install Image::Size, since it's already available as GT::Image::Size (I think). This is one rewrite of the plugins.
I've made significant modifications, fixes, and updates to the various image routines, including how the thumbnails are called.
I have been trying to integrate the various image routines into one more encompassing routine that is easier to maintain, more features, and more logical to use.
There are two distinct versions based on how/where images are stored (actually quite a few more based on features).
One version is for a system that is anonymous, doesn't use logged in users, and images are stored with the link similar to how the built in FILE routine works.
The other version assumes a logged in user, stores the images/files groupd by user, attached to a link (or not) but requires a logged in user FOR ALL IMAGE UPLOADS.
I'm setting up a couple of new sites, which should isolate the upload/thumbnail routines into a plugin. Right now they require the profile system, because of the changes it makes to the database system. I have to take those changes out, put them into a "Tools" plug in, and have them check for the modifications and make those that are needed.
The goal of these rewrites was to create ONE MERGED/EXPANDABLE/SCALABLE system for image/file uploads, that would accomodate *most* needs from shopping carts and site-thumbnails to galleries and stock image sites. In order to do that, some basic logic had to be worked out, distilled, fixed up, etc. I found that the use of a few fields in various tables, and a set of configuration options that could be shared/accessed by the various programs simplified communication, installation, and operation of the programs. *BUT* separating out those features into different plugins, checking dependencies, etc has taken much more time than actually developing those features.
All so you *DON'T* have to worry about various installation issues :)
Unfortunately, going back to the beginning, certain modules *need* to be installed on your server, and perl has to know where they are. This is not something *we* can do, it has to be done by whomever has access to, and/or operates your servers for you.
Oh, and the final word, on this, is while there are probably other ways to do it using PHP, or non-GT-engine perl, the way I've been working on it makes the best use of (at least in my non-guru-abilities) the GT engines, logic, and functionality to integrate tightly, and properly into the "flow" of the programs, templates, and thus your GT-code based sites. Yes, I'm behind schedule, but this isn't my main job. I am close, and if people want to test out various image/upload/gallery/etc features as I've posted over the past 6-8 months, please PM me, and tell me your needs.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
I've been rewriting these plugins and modules, as a lot has changed over the years.
First, the File::[copy/etc] routines *should* be installed with perl on your Unix machine. If you are *NOT* running Unix (of some sort) there *are* going to be issues. Windows is *not* Unix, and M$ has tried their hardest to make it _HARD_ to do, trying to keep control over the world. ActiveState Perl has some issues of compatibility, I've only been able to get it to run on 1 of my 3 windows machines over the years. Apple, well, to quote a well known character from a old sitcom "I know Nothing, NOTHING."
GT has rewritten/imported the ::Image routines, and you do not need to install Image::Size, since it's already available as GT::Image::Size (I think). This is one rewrite of the plugins.
I've made significant modifications, fixes, and updates to the various image routines, including how the thumbnails are called.
I have been trying to integrate the various image routines into one more encompassing routine that is easier to maintain, more features, and more logical to use.
There are two distinct versions based on how/where images are stored (actually quite a few more based on features).
One version is for a system that is anonymous, doesn't use logged in users, and images are stored with the link similar to how the built in FILE routine works.
The other version assumes a logged in user, stores the images/files groupd by user, attached to a link (or not) but requires a logged in user FOR ALL IMAGE UPLOADS.
I'm setting up a couple of new sites, which should isolate the upload/thumbnail routines into a plugin. Right now they require the profile system, because of the changes it makes to the database system. I have to take those changes out, put them into a "Tools" plug in, and have them check for the modifications and make those that are needed.
The goal of these rewrites was to create ONE MERGED/EXPANDABLE/SCALABLE system for image/file uploads, that would accomodate *most* needs from shopping carts and site-thumbnails to galleries and stock image sites. In order to do that, some basic logic had to be worked out, distilled, fixed up, etc. I found that the use of a few fields in various tables, and a set of configuration options that could be shared/accessed by the various programs simplified communication, installation, and operation of the programs. *BUT* separating out those features into different plugins, checking dependencies, etc has taken much more time than actually developing those features.
All so you *DON'T* have to worry about various installation issues :)
Unfortunately, going back to the beginning, certain modules *need* to be installed on your server, and perl has to know where they are. This is not something *we* can do, it has to be done by whomever has access to, and/or operates your servers for you.
Oh, and the final word, on this, is while there are probably other ways to do it using PHP, or non-GT-engine perl, the way I've been working on it makes the best use of (at least in my non-guru-abilities) the GT engines, logic, and functionality to integrate tightly, and properly into the "flow" of the programs, templates, and thus your GT-code based sites. Yes, I'm behind schedule, but this isn't my main job. I am close, and if people want to test out various image/upload/gallery/etc features as I've posted over the past 6-8 months, please PM me, and tell me your needs.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
