Gossamer Forum
Home : Products : Gossamer Links : Version 1.x :

[Q] Implementation of File Uploads

Quote Reply
[Q] Implementation of File Uploads
Hi,

I'm working on implementing file uploads and am wondering how you would like to see it work. Here's how I am thinking of doing it:

There will be a file upload box in the admin add screen and admin add error screen only. The admin can then when adding a new record, upload an attached file. The database stores only the filename, and the admin script puts all the files in a preset directory. The files are renamed to ID.extension where extension is whatever it was when the file was uploaded.

When modifying, the admin can not re upload the file. This might cause problems when you need to modify a record and don't want to upload a new file. So if the admin needs to change the file, they need to use FTP.

Users can attach a file when adding a link, and that file is saved in a non viewable upload directory. It is subsequently moved over to the viewable directory when it is validated.

If a user modifies a record, they can upload a new file, but it will still be held in the validation bin waiting to be approved.

Any comments/ideas? =)

Cheers,

Alex
Quote Reply
Re: [Q] Implementation of File Uploads In reply to
Alex,

Amazing you should post this, since this is something I've been batting around for weeks, and have been working on.

The "problem" from an admin point of view, is housekeeping.

As links grows, so does the number of files (even logo files). A 20,000 link database could have 20,000 files... so how do you divide them up?

As I was thinking last night, I wondered if FTP would be the answer rather than HTML upload.

I was going to ask if there could be an admin upload feature, that uses NET:FTP to allow placement of the file in _any_ directory. FTP reqires a password, so the FTP session _should_ have the permissions of the user logged on, not the server, right? This would allow files to _not_ be listed as _nobody_ for FTP maint by the Admin, rather than super user. I don't konw NET:FTP well enough to know , but it would have to work that way, right?

There are problems with this, and permissions are the biggest problem.

Here's my needs, rather than my perspective, what's yours:

I run a gallery/postcards site from Links.

I need, for housekeeping reasons, to upload files to different directories, rather than one main upload.

My URL link is the link to the main image in the directory.

I'd like the height/width inserted into the database on upload. Possibly even size. (user selectable, but makes for faster html loading).

I'd like to automatically generate the thumbnail image in a directory /thumbnails under the directory where the main image is loaded.

Right now I also store the thumbnail image as a separate url, but it's ALWAYS /thumbnails in my case.

I have a good outside program that manipulates the file to create pretty awesome thumbnails.

There are all sorts of code snippits to return Ht/Wd/Sz

Now... moving files requires server permissions, or access via another means, but Links needs to have the ability to regenerate file/image links if the database gets moved around.

In your case, the ID.gif|jpg file is linked to the record by the ID number, and needs to be renamed on upload. This provides a good link.

Where to put the file?

Please.... when implementing this, allow the ability to modify your ID.ext format into the more robust gallery convention I need.

I'm looking at storing the filename (which will be unique, though not a number) with the Link Record, and in an images database storing the filename, it's characteristics (size, width, etc) _AND_ it's path location.

cron runs as root, so I can have a 'move' script to move the files to where they need to be, from the upload area, to the gallery tree. In my case I would need cron to check every 10-15 minutes, but if I automated my build, cron and my build, could run at night or x-times a day.

The logic:

The link record stores the image _name_ only. This image name is unique in the image database (either link ID or file name). If the link record has an image associated with it, on build, the program checks the image database for the characteristics of that image, and uses them to build the link.

That way, if the image data changes, it's reflected in the link the next build.

It also means I can rearrange the image tree, run a script on the image database to change the paths, and again, on the next build, links is updated.

You could even change all the sizes of the images with this plan, since Links doesn't store the image data, only the name, if you decide to change the format from 88x33 to 120x60 you can resize all existing images, change the image table size data, and rebuild links, and it's done.

Also, if the image data is kept in a different table, FTP and telnet could be used to manage the images and the image database, and then issue a rebuild command, and links is updated.

Are you following?

Alex, this is really important to me, as this is what I use links for, and I've put a lot of time into thinking about it.

Please keep me informed of your progress, and I'd ben happy to look at or test code in progress for problems.

I've been working on the design of the image manipulation routines, leaving the interface to links alone since that changes (as evidenced here) so maybe together we can create something that works "simply" and leaves all the hooks in for a heavy weight gallery management program.

thanks!!!!

==> by storing only the image name with the link, and everything else in the image table, it allows people to select their image indexing scheme -- they can use the link ID, the Link Name, an incremental name, their existing image-collection ID, etc. It's very flexible, yet simple.


------------------
Robert S. Pataki, MD
President, PUGDOG Enterprises, Inc.
www.postcards.com


[This message has been edited by pugdog (edited September 02, 1999).]
Quote Reply
Re: [Q] Implementation of File Uploads In reply to
The file extention on the image file is necessary because a lot of programs -- and browsers, determine what to do with the file by it's extension, not its header information. Especially true for 'in-line' images.
Quote Reply
Re: [Q] Implementation of File Uploads In reply to
Hello Mr. Pataki!

Exactly, this is what I meant. What Alex said by extension was that he wanted to have the extension with the date and we proposed to have the extension by file type. So when you refer, what we mean is Extension=File type. This is extremely important for all purposes, not only for images as the browser of any other format of php3, html, etc needs to be declared to the browser for it to understand.

------------------
rajani











Quote Reply
Re: [Q] Implementation of File Uploads In reply to
Hello Alex!

This is really a very mordern way of software development environment. Very sophisticated. Such a way I have never ever seen before on any other website who sell programs that the designer of the software in interacting with the users a LOT and also develops the software. Its a very sophisticated and impressive way. I love it.

Yes, I was trying to also find out which are the program scripts that can help with less nightmare. I landed into phpAds on www.phpwizard.net as one of the best related to handling the images, as this is only one I know which works with MySQL very good. Now this suggestion comes from you about development of this similar area and thats wonderful. Atleats I can be sure that its going to be robust and bugs free with a lot of interesting features.

I would very much like to present my ideas, which I beleive could be helpful. Although, not all or some of it is something that I need, however they are just thoughts.

Quote:
The files are renamed to ID.extension where extension is whatever it was when the file was uploaded.
Well, extension is already there in the row where it either says Add_date or Modify_date. I wonder why it is needed here at all. The suggestion of having LinkID.type seems to be the best. It is this which will be built in the links pages and also it is this which will remain for the further display with the help of the browser. The file type could be *.jpg, *.gif OR any html, txt. it is this file type mentioning that can help a webmaster/browser to handle it at a later date in a better way.

Instead of focusing only on image uploading it would be of extreme importance to cover as broad as possible all the file types uploads. For e.g. a news site wants to buy SQL version of links. They may want images uploads as much as txt + html uploads.

I would even go far beyond and say, may be this uploading feature is there. But what if a webpage is produced on the fly, which I am sure you will touch this deadly and attractive feature one day for further development of the program, and this webpage is in one of the incoming read-only directory. This webpage will be a real coustomized one to that user. Then this pages can also be handled in the way you said upload feature.

It is therefore we then are talking to its fundamental basic in say:

An in-built feature of Links SQL that is able to handle an external file that has a handle of a link within the database. This external file could be an image, ASCII/Formatted or a html document. The Link within the database is the reference to that file.

Then with this broad and general approach, I beleive many more users will be covered than the websites who primarily uses images or images + texts. This will then trigger to a larger group.

Further is the sub_routines are there that can handle all the specific file types in an intellegent way, that would be great. This means for e.g a subroutine that handles images in a way what Mr. Pataki said and one that can handle a html document, etc


Quote:
Users can attach a file when adding a link, and that file is saved in a non viewable upload directory.
I propose.....
Users can attach a file when adding a link, or even generate a file on-the-fly that resides on the serverand that file is saved in a non viewable upload directory.

Lets say an example Homepage making script for the users. I have not thought on all this in-depth but I see this feature as a terrific potential that can cover a very large group of future links SQL users.

Alex, if this is the way you plan to develop your favorite script of Links SQL then I am sure there cannot be any other script program as deadly and killing one as Links SQL. If that would be the case then you should change the name of this script to Website SQL as Links SQL I do not like it anyway. Further, if you accept this name, it would not be bad idea to apply for an international trademark of the name, where I would like to offer the best possible support of obtaining a trademark within Europe.



------------------
rajani











Quote Reply
Re: [Q] Implementation of File Uploads In reply to
Thanks for the great feedback! I'm still digesting it, but will offer some comments shortly.

Cheers,

Alex
Quote Reply
Re: [Q] Implementation of File Uploads In reply to
Alex,

Since file uploading is probably primarily for logo-links and generating a bit of extra income from the display of a logo, links needs to be primed for that.

One _major_ feature is the ability to turn the graphic on/off at least manually -- but preferably with an expirator mod. The easiest way is to keep the day of upload, and date of expiration, along with a Display Yes/No field.

When a graphic is uploaded, and a link validated, the graphic should _NOT_ automatically be displayed. Only after payment is received should it be turned on.

Are you following?

You don't want to delete and unlink the image from the record, but you might not want to allow it to be displayed just yet, or after a certain amount of time.

Of course this leads to a whole list of other mods for maintaining it, but the _main_ feature is the ability to turn the display of the graphic on/off on a record-by-record, category-by-category and database level.

Quote Reply
Re: [Q] Implementation of File Uploads In reply to
You could easily add a field "Paid Yes/No" to the database and then in the template:

<%if Paid eq 'Yes'%>
display logo..
<%endif%>

(See the new Template.pm mod for adding conditionals to your templates. This will be standard in the next release, but is an easy cut and paste add in).

Cheers,

Alex
Quote Reply
Re: [Q] Implementation of File Uploads In reply to
That would be great if LinksSQL versoin have the upload function.

I think it's good to allow visitor to upload their image when whey try to add link and let them to modify later.

Or may be each user should register before they can upload, and there is a webbased admin area for them to see what they have uploaded and modify their uploaded info.

On the webmaster of view, it's good to let the webmaster to set which field is upload field in the admin area, and also the max size too.

Alex, will you include this function into the coming version?

Nice to see if you can.

------------------
Bear EveryWhere