Gossamer Forum
Home : Products : Gossamer Links : Development, Plugins and Globals :

Image uploads, Gallery, Thumbnails, etc

Quote Reply
Image uploads, Gallery, Thumbnails, etc
About a year ago, I was 90% ready to release this program. In the past 2-3 weeks, I have recovered about 90% of the 90%, and have been making it Links 2.1.1 compatible.

Image processing and file uploads:

1) Image uploads (logo/graphic mod is working)
2) Automatic thumbnailing, rotation, drop shadow, etc is working.
3) size checking for GIF, JPG and PNG images, (pixels and total bytes)
4) etc on the above
5) Slide-page display format is working, but needs to be moved into the templates, rather than .cgi
6) Logo display allows logo to be validated, as well as the link, so that the logo can be approved, pending payment, or a link can be deactivated for payment, yet still have a valid logo if payment is again made, etc. This dual flag is great for other purposes, and should be included in the general upload.
7) validations all go through the standard validation pages, but add extra features for admins and editors. "Admin" area hooks will be added as time permits.
8) all this coexists peacefully with Yogi's upload mod

It looks like I will have to finish up my upload system, and then pull this into a single plug in. Time has been my biggest scarce resource, so it's going slowly. But, I was able to finally recover large portions of my previous code, and actually surprised myself how far along I was (or maybe I blocked it out, as it was too depressing to think I had been so close....).

Anyway, despite the features built into Links, and other plugins, the Logo mod still has advantages for it's single-minded purpose of adding a [commercial] logo to a link. The logo can be uploaded, checked for size (using Image::Size) and depending on your version of GD.pm and other utilities, checked to be GIF, JPG, PNG, etc.

Image Gallery:

I had several posts on this in the past, early to mid 2001, about the features and what were still the stumbling blocks.

The biggest is disk storage/layout.

While I want to be flexible, I think it's only fair to impose some restrictions, and rules. It simplifies the coding, the support, and management of the program. Before I enforce these rules, I am still open to hearing about what you need or want in a Gallery/Image program.

1) I work on Unix systems, it will take advantage of Unix/Unix-like file system features. Windows users will have to adapt. Unix file systems and mount points allow for more flexibility than Windows allows.
2) I work on Unix systems, so the utilities I use are designed for Unix systems. if they don't exist, or run right on Windows... get a new server ;)
3) for small file systems, using the Link ID + file name is sufficiently unique. For large systems, it's wholly inadequate. Allowing Links to manage the file system is *not* a good idea for large sites.
4) this system is designed for Admins and a limited number of people to upload/add to the database, not for a general upload system. There are several reasons for that, the biggest is that is the type of system I need, and stock agencies, and such would need. "free" access to uploads is not a good thing any more. This simplifies the file system, such that images can be FTP'd to the server, then added in, upload areas can be selected during import or additions, and the program doesn't have to try to be a mind reader and super natural in it's ability to manage files. You can designate upload areas, but you will need to manually/automatically have the files moved to a more permanent location on a regular basis.
5) an on-disk system for reconstruction of the image database, similar to a files.bbs, where the data recorded in the database for each image is written to an image_name.txt file in the same directory as the images. I had thought to put them in a "descriptions" subdirectory, like the "thumbnails", but the purpose here is the ability to reconstruct in a disaster, and during back ups, it's likely that sub directories will not get properly traversed, so keeping the description with the image is safer. These files are written out when descriptions or other changes to the file record's 'static' data is made (ie: not for downloads, ratings, or other dynamic data). Full updates can be scheduled to update dynamic data, but the purpose here is to be able to recover the descriptions, keywords, photo information, etc that belongs to the image, but could be lost in a crash or dissociation event.
6) Flexible search/display features with an interface of sorts to the more obscure search features of Links. I'm stopping short of "skins" since links has such good template processing.


In this first version, an image upload will be equal to a "link". The links database/table structure and jump.cgi will be altered to treat "links" as local images. This is similar to how Postcards.com is run. In face, postcards.com and creepycards.com will be my test sites, with the most current release beta+ code running. (I'll have beta/demo sites for the bleeding edge code, but they won't be my 2 or 3 main production sites!)

This will make it easier to work out bugs, and get the flow working. The next version will use arbitrary tables, but that code is a whole project unto itself. Fortunately, because the data will be essentially the same, with only the table names changing, upgrading should be easy, and only a matter of copying/moving links from the Links table, to the proper arbitrary table.

As a note, what might happen is rather than doing that, I will put a shell around links, which will impose a "higher order" on the Links table, and allow for file groups, and associations _within_ links, without using arbitrary tables. The problem with that, is it will limit the program to managing image files, efficiently, rather than any sort of file (doc, text, zip, etc). You won't be restricted from using other files, but the fields in the Links table will grow with each non-image type added.

Which of the two ways I go depends on several things, but mostly time. I only need image storage, processing and recall, with minimal to non-existent other documents. By simplifying the code, and using a "shell" system, I think I can cut significant development time off of it, and get the product I need, and which would be suitable to other image-only sites.

I am open to comments, suggestions, funding, etc :)

I hope to bring http://creepycards.com back on-line by Oct 1st, using this program/suite of tools. If I'm successful, I will modify http://postcards.com to use the same system. I should have worked most of the bugs out by then, and will try to stuff it all back into a plugin (which it burst out of several weeks ago).

With luck, the first public beta release of the Image/Gallery/upload/thumbnail system should be available by the end of October. (about 6-7 weeks).

Pricing to be decided, but it will be consistent with my previously released pricing, of at least $250-$300. I can't afford to support or maintain it for less. Anyone who bought a pre-release package last year, will be upgraded. The postcards script will be included, and integrated into the package. As the package develops, it will also be linked to the user mangement features, and other statistics as previously reported (check back on old searches from last year, may-july/2001). You get 90 days of upgrades with purchase, which should fix any bugs or problems in your release. After that, upgrades are $75/year as long as the contract is continued. $125 for the first year after a lapse. All those who ordered previously get free perpetual upgrades.

Anyone who wants to buy into the "charter" perpetual upgrades offer, can purchase a charter license for $475 from now, until Sept 30th.

The image upload/thumbnail demo is still available at:

http://betterbeads.com/...QL/test_upload_2.cgi


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [pugdog] Image uploads, Gallery, Thumbnails, etc In reply to
Minor update and clarification:

1) These features are going to be in a sort of OEM version of links. These first releases will require a full version of Links, and there may or may not be a "plugin" version of these features. That depends on how much progress I can make on the arbitrary tables and table manager. For now, that is a separate beastie.

2) I've been asked by two people recently about a classifides program. I've followed, and commented on various aspects of classifieds over the years, and I'm looking at integrating classifieds and personals into the Image/Gallery system as built-in applications, in a "ready to run" sort of mode. When setting up, you'll need to pick one of the three "types" of sites you want to run -- Image/Gallery, Personals or Classifieds, and your set up will be configured based on that. For now, it will be only one of the type of systems, but hopefully, depending on the arbitrary tables, it might be able to run 2 or more at the same time.

2a) if there are features you'd like to see in a classifieds system, let me know.

I'm still hoping to have a pre-release version on http://creepycards.com by month's end, and a limited public beta by the end of October.

Alex has indicated that they are making progress on Gossamer Community and Gossamer e-Commerce so that once those are released or made available, that will be integrated in to these systems, so that you can use a standardized logon, and bill/charge for uploads, displays, downloads, etc.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.