Gossamer Forum
Quote Reply
[update] MultiUp
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.
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.
Quote Reply
Re: [pugdog] [update] MultiUp In reply to
I'm getting closer to releasing this, and this will allow images to be attached to a link, and will allow management of the links via a web interface. Admins can find pending images, newly uploaded images etc. It should be fairly easy to tweak the code to allow other views (not user interface changable at this point).

It will also allow other file types to be attached to the link, and *hopefully* will have an easy way to add file checking for that file type. Sort of an

if supported_file_type
check_supported_file_type and apply rules
just check success upload

Where the user enters supported file types, and the program checks to see if a filetype.pm file exists, with the rules/checks for that file type. If not, the routine just uses entered defaults (ie: size, height, width, etc).

Once this is out, the calendar, and other programs will follow.

Lot's of requests for this one.

Right now I'm trying to simplify the number of templates, and the display routines. They are "old" style, and have a lot of things the new template parser makes obsolete.

If you let me know what sort of image management you want/need, *NOW* is the time, really. It's getting down to the wire, and changes to the core codes are not going to be able to be made easily once it's released, since backwards compatibility becomes an issue.

Anyway, getting much closer, all the "hard" parts work, just the interfaces are needing work, but without the interfaces, the plugin isn't much general use ;)

PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [pugdog] [update] MultiUp In reply to

How's this going? I'm quite interested in this plugin.