Every time I try to release a program, I find myself rebuilding modules in other programs (and can understand why GT takes so long between releases <G>).
I'm working on this again, because it's needed for my site to run, and deal with the other programs (ratings, calendar, etc). Everything seems to need an image or two attached, so this got bumped to priority 1+ at the moment.
What this will do, in short:
1) Allow uploads (any type of file) to be attached to a link.
2) will try to figure out if the attachment is a graphic, and if so, process it, thumbnail it, and insert the sizes into the record.
3) Will pick up an "admin" status on a user, and allow them to edit/validate records. This will be greatly expanded, once the overwrite/replace features are added back in.
This is all "user" based, meaning it does NOT go through the admin. It doesn't go through the editors either. It depends on (and is driven by) "USERNAME" and "USER.Status". Alex had mentioned they are going to a more non-admin/frames version, and I guess I was already there <G>. My last mod dates on this were July 11,2001 (it's been awhile) and I'm making _major_ changes to the code. It was working at that time, but changes to Links, better coding knowledge, and flat-out upgrades are required <G>.
Last night I spent a few hours getting rid of $PLUGINS_CFG as a global, and making it local to each routine that needed it, as well as converting from the $LINK_DB format that was being used at that time. Not as easy as you might think, if unnecessary database connects were to be avoided!
This uses an attached table to store image information for a link, and the biggest block for me is disk layout (again). Where to put the images that are uploaded, and then how to reference them. For this release there is only "public" storage of the images, ie: http://domain.com/path/image reference. There will be upload/validate capability, as well as delete, but not modify/update a specific file (you'll need to delete, reupload, re-validate) for now.
I'm trying to generalize the "core" code enough that the basic File and Image routines will be reusable for the "arbitrary attached" tables project, and immediately reusable for the enhanced shopping cart (actually catalog) code. Right now, (as of 2 years ago) there was a lot of hard coding of the fields to make it work -- that needs to be abstracted.
The only external package you'll need is netpbm (http://netpbm.sourceforge.net) . I'm looking at a pure perl replacement, since thumbnailing/processing is only done once (on upload), the overhead will be relatively trivial. The other module, Image::Size seems to be in most perl distributions now, or can be easily loaded from CPAN. If not, since it's a single module, it can be placed in the PUGDOG::Images directory with a minor code edit (and I may be able to make that a parameter as well).
The first release (soon!) will allow image upload, image validation (complex scheme I've explained before using isValidated, isVisible, etc), automatic thumbnails with border, drop shadow and rotation, and selection of a "Logo" image to display, with different parameters (ie: 140x60, .gif only, etc) than the other uploaded images.
The image processing test link is here: http://betterbeads.com/...QL/test_upload_2.cgi
This will incorporate the LogoUpload mod into this plugin. The Logo portion, as described, will use "hard coded" fields in the links record for performance issues. No separate lookups are required for category display, search display, etc. The only time you'll need a lookup is if you want to actually display the attachments in the Link record, rather than the detail pages. The link record will "know" that it hasAttachments (a non-zero number is a "yes" and the value is the number of attachments). The attachments value is verified/validated each time the request is made, so it's always correct (a simple compare, low overhead, with an "update" only if the values do not match). An option will eventually be added to notify the admin when a change like this is made, since that often will be a disk error or "lost" file, or something an admin might want to know about. (regular add/deletes should be reflected in the add/delete code).
The "complexities" of this release are what are slowing it down. Multiple "flags" for validation, modify issues that do not overwrite the old file (so static sites are undisturbed), and other things. There are over 60 configuration values as of now (for the full, final release)
Suggestions on how you plan to use this, are welcomed, so I can code it in at this point. Hopefully the working demo will be on http://betterbeads.com/ in the shopping area in the next week or so. I'm going to try to cut the number of required templates down as well.
Also, I'm not sure how it will finally look in the plugin
1) pretty much as a replacement for add.cgi and modify.cgi.
or
2) a "hook" off the add_success.html template, and an option on the modify.html form
Right now, it's doing a little of both, and that's the schitzophrenic behavior I'm trying to cure <G>. #2 is less elegant, since it requires a link to be sucessfully added (not validated) before it will run, but is probably the most portable and "safe" method for this sort of plugin. (It *will* be a replacement in the auction and classifieds scripts, most likely).
This will eventually be released as a GT/OpenSource licensed product, such that anyone with a valid GT SQL licence can use or modify the program, provided they share all modifications, and do not redistribute altered code. All GT license restrictions will apply, as well as the above. For now, for legal reasons, it will be released as Shareware, with a $25 regitration fee, and a $2500 non-compliance fee, your installation and/or use of the code is implicit agreement to those terms. You'll automatically be moved to the new license when it takes effect. The Postcards plugin is unfortunately in the same condition, and will need to stay at a $45 registration fee for the time being. The new code (ratings, review, calendar, etc) all will be released initially with the GT/OS type license.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
I'm working on this again, because it's needed for my site to run, and deal with the other programs (ratings, calendar, etc). Everything seems to need an image or two attached, so this got bumped to priority 1+ at the moment.
What this will do, in short:
1) Allow uploads (any type of file) to be attached to a link.
2) will try to figure out if the attachment is a graphic, and if so, process it, thumbnail it, and insert the sizes into the record.
3) Will pick up an "admin" status on a user, and allow them to edit/validate records. This will be greatly expanded, once the overwrite/replace features are added back in.
This is all "user" based, meaning it does NOT go through the admin. It doesn't go through the editors either. It depends on (and is driven by) "USERNAME" and "USER.Status". Alex had mentioned they are going to a more non-admin/frames version, and I guess I was already there <G>. My last mod dates on this were July 11,2001 (it's been awhile) and I'm making _major_ changes to the code. It was working at that time, but changes to Links, better coding knowledge, and flat-out upgrades are required <G>.
Last night I spent a few hours getting rid of $PLUGINS_CFG as a global, and making it local to each routine that needed it, as well as converting from the $LINK_DB format that was being used at that time. Not as easy as you might think, if unnecessary database connects were to be avoided!
This uses an attached table to store image information for a link, and the biggest block for me is disk layout (again). Where to put the images that are uploaded, and then how to reference them. For this release there is only "public" storage of the images, ie: http://domain.com/path/image reference. There will be upload/validate capability, as well as delete, but not modify/update a specific file (you'll need to delete, reupload, re-validate) for now.
I'm trying to generalize the "core" code enough that the basic File and Image routines will be reusable for the "arbitrary attached" tables project, and immediately reusable for the enhanced shopping cart (actually catalog) code. Right now, (as of 2 years ago) there was a lot of hard coding of the fields to make it work -- that needs to be abstracted.
The only external package you'll need is netpbm (http://netpbm.sourceforge.net) . I'm looking at a pure perl replacement, since thumbnailing/processing is only done once (on upload), the overhead will be relatively trivial. The other module, Image::Size seems to be in most perl distributions now, or can be easily loaded from CPAN. If not, since it's a single module, it can be placed in the PUGDOG::Images directory with a minor code edit (and I may be able to make that a parameter as well).
The first release (soon!) will allow image upload, image validation (complex scheme I've explained before using isValidated, isVisible, etc), automatic thumbnails with border, drop shadow and rotation, and selection of a "Logo" image to display, with different parameters (ie: 140x60, .gif only, etc) than the other uploaded images.
The image processing test link is here: http://betterbeads.com/...QL/test_upload_2.cgi
This will incorporate the LogoUpload mod into this plugin. The Logo portion, as described, will use "hard coded" fields in the links record for performance issues. No separate lookups are required for category display, search display, etc. The only time you'll need a lookup is if you want to actually display the attachments in the Link record, rather than the detail pages. The link record will "know" that it hasAttachments (a non-zero number is a "yes" and the value is the number of attachments). The attachments value is verified/validated each time the request is made, so it's always correct (a simple compare, low overhead, with an "update" only if the values do not match). An option will eventually be added to notify the admin when a change like this is made, since that often will be a disk error or "lost" file, or something an admin might want to know about. (regular add/deletes should be reflected in the add/delete code).
The "complexities" of this release are what are slowing it down. Multiple "flags" for validation, modify issues that do not overwrite the old file (so static sites are undisturbed), and other things. There are over 60 configuration values as of now (for the full, final release)
Suggestions on how you plan to use this, are welcomed, so I can code it in at this point. Hopefully the working demo will be on http://betterbeads.com/ in the shopping area in the next week or so. I'm going to try to cut the number of required templates down as well.
Also, I'm not sure how it will finally look in the plugin
1) pretty much as a replacement for add.cgi and modify.cgi.
or
2) a "hook" off the add_success.html template, and an option on the modify.html form
Right now, it's doing a little of both, and that's the schitzophrenic behavior I'm trying to cure <G>. #2 is less elegant, since it requires a link to be sucessfully added (not validated) before it will run, but is probably the most portable and "safe" method for this sort of plugin. (It *will* be a replacement in the auction and classifieds scripts, most likely).
This will eventually be released as a GT/OpenSource licensed product, such that anyone with a valid GT SQL licence can use or modify the program, provided they share all modifications, and do not redistribute altered code. All GT license restrictions will apply, as well as the above. For now, for legal reasons, it will be released as Shareware, with a $25 regitration fee, and a $2500 non-compliance fee, your installation and/or use of the code is implicit agreement to those terms. You'll automatically be moved to the new license when it takes effect. The Postcards plugin is unfortunately in the same condition, and will need to stay at a $45 registration fee for the time being. The new code (ratings, review, calendar, etc) all will be released initially with the GT/OS type license.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.