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

[RELEASED] Multiple Upload Graphic&File Attachment

Quote Reply
[RELEASED] Multiple Upload Graphic&File Attachment
LSQL: Multi Upload Graphic and File Attachment Mod.

I've pretty much locked down the features at this point and I've smoothed over the logic for "valid" files, and I've moved almost all the attachment processing to the templates. Virtually no part of the attachment display process is in the code. You have complete control over what you do, and can be very creative using the newer template tags, even passing in data to the template that it uses to process! Cool. Alex has promised more of that stuff too, since this was only the first release of this bugger. Check the docs in the Template area for more on Loops and parameters, and such.

Briefly: Allows attaching multiple files or graphics to a link.
Requires: Image::Size (CPAN), NetPBM (SourceForge)

03.xx.xx series:
Features:
1) Has a similar interface to the Logo/graphic program, but will allow multiple files of any sort attached to a link.
2) Attachments can be auto-validated based on the "user_modify" parameter. (This will be expanded in a later release)
3) Files can be uploaded one at a time, with all information provided (from the add_success screen, or modify screens) or they can be uploaded as a group, and presented to the user to edit in the missing descriptions.
4) Attachments can be validated separately from the link, and each other.
5) Graphic attachments in GIF/JPG and a few other formats are checked for size, dimensions (rquires Image::Size), and those values are entered into the database. Thumbnails can be automatically created (requires Image::Size and NetPBM). Values can be entered manaully (by the forms) if you prefer. It will be able (theoretically) to handle any sort of upload, but will "recognize" images in GIF/JPG/BMP/PNG format, and will automatically create a thumnail view, if you'd like it to.
6) Most display controls are in the templates, using <%loop%> and other tags, so that they can be customized without going into the code at all!! If you find something that can't be, I'll try my best to make it so!
7) It will use the <%loop%> system of tags, so you can create mini-thumbnail pages for each link, if you'd like, or customize the templates in all sorts of other display ways.
8) All attachments are in a table, and the table contains all the attributes of that attachment. Thse values can be searched, extracted, or used in many ways (search of attachments is not fully implemented yet).
9) I just added an add_plugin_defaults field so you can override user input the same easy way you can in the Links.cfg with add_system_fields
10) It's designed to work with logged-in users. I will try to make it work with non-logged in users, allowing an Admin to edit/upload files to any group, and a user to upload/attach files ONLY to the group they are currently submitting.
11) It should work with static pages, but the new files will not show up until the site is rebuilt, obviously.
12) Attachments can have a "slot" (or order) value. It's rudimentary in this release, but it will allow you to pick where you want to put certain files, if you need to do some sorts of layout. Example: a catalog, where you want to attach 3 files to each link, in a standard layout. You'll be able to assign which file goes into which spot.
13) Stores the attachments data in an Attachments table, not in the Links record.
14) Files are stored in a simple, BASE_DIR/ID/files format not the /path/to/storage/x/nn/n/ID format (as described in the previous thread). The attachment record stores the paths and URL's (if you want it to) so the files can actually reside on a different server, system, or almost anywhere.
15) [in flux] It will use the "links" permissions table, so that if you have "user-mod" enabled, if a link has been validated, and contains at least one valid attachment, a user can modify/add attachments without requiring admin approval. The 1-approved-attachment restriction has merit, if you think about it. I'm really not interested in removing that, and consider "hacking around it" sort of akin to disabling your seat belt buzzer and warning light :) You do so at your own risk, but I'm not going to do it for you :)
16) Admins can validate partial attachments, with the other attachments staying in the "pending" area until validated.
17) Admin/Edit functions allow the ability to edit/approve by link, but also by attachment and user. So, you can get a list of all a users attachments as well as a list of all that users links with attachments. (being added in now)
18) It requires Image::Size & Net::PBM to be installed to use the image management routines. I believe Net::PBM is now at SourceForge.com. It does NOT require Image::Magick, and it actually only requires a subset of Net::PBM, not the whole package.

Bug fixes, and the missing features noted above are being added now.

Commercial: $75
Free upgrades in the 03.xx.xx series
This is included in the 06.xx.xx series pre-release.



PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Plugins:http://LinkSQL.com/plugin
Quote Reply
Re: [RELEASED] Multiple Upload Graphic&File Attach In reply to
I want to make sure I understand this correctly -- I can have a user upload a text file (or several) and then in one of my templates I can pull in the contents of the text file? That's exactly what I need.

Do you have any provision for processing the file before pulling it in? For example, I will need to HTML encode the text file before displaying it in the template (they will have < symbols, need paragraph breaks, etc). I know I could do that using a custom plug in but I was wondering if you had already had a mechanism for that.

Going to send my client over to purchase the plug in shortly...

Thanks
Ashley

Quote Reply
Re: [RELEASED] Multiple Upload Graphic&File Attach In reply to
I want to make sure I understand this correctly --

In Reply To:
I can have a user upload a text file (or several) and then in one of my templates I can pull in the contents of the text file?
I would have to say yes. The files are stored on disk, the "link" knows what attachments it has, and where they are stored, so when you would process the link, I would assume the detailed.html template, you would make a call to <%Plugins::MultiUp::get_attachements%> and from that point on, there would be a tag <%elements%> that is an array of hash_references to the attachments for that link.

It only contains the Attach_Elements data, _NOT_ the content of the files. But, it contains both the URL and the PATH to the file, so you can do a :

<%loop%>
<%include $Storage_Path/$file_name%>
<%endloop%>

To pick the file up off the disk, parse it, and include it. I'm _PRETTY_SURE_ this will work. Alex/GT may have to give a little input on the technicalities of this, but it should work. If not, you can modify the code in the plugin just a bit, to store the $file_name in the $Storage_Path variable, and then just <%include Storage_Path%> which should work, as indicated in an announcement.

Storage_Path contains the on-disk storage path of the file, without the "file_name".

In Reply To:
Do you have any provision for processing the file before pulling it in? For example, I will need to HTML encode the text file before displaying it in the template (they will have < symbols, need paragraph breaks, etc). I know I could do that using a custom plug in but I was wondering if you had already had a mechanism for that.
No, not really, but Links has that built in, I'm pretty sure. I'd need to ask Alex/GT how to do it exactly, but you'd just encode the file as a string/scalar before writing to disk. Adding this to the module wouldn't be hard, and it's something I've got planned for later -- but in a general way. Based on the "filetype" of the file, cause checking of the input, as set in the "Options" area. Right now, only graphics are checked, but you could make another call:

if ($PLUGIN_CFG->{'text_encode'} and $filetype eq 'TEXT') { do encode_text() }

encode_text would just be another subroutine, with the code for doing what you want here.

I've really made it expandable, as I find the ways to check for various types. It would be nice to also validate ZIP and TAR, PDF, etc. files. Right now, it only does this for images, but only because that is the only "test" module I've written or hacked so far :)

In case I've misread this, if you want to store the text file on disk, but import it as html->escaped code, then I would have to say, you'd want to add a function like <%Plugins::MultiUp::URLEscape%> which when included in the loop, would have access to the $Storage_Path variable. That function would read that file from disk, as a string, process it, and return it as a standard tag in a variable of your choice. Should be pretty easy, actually.

Right now I'm cleaning up the file access/process routines, so adding in this sort of functionality will be even easier.

(My ultimate goal would be to have a module function like site_html_display, where you send it a file, and a type, and it validates it, and cleans it up, checks it, etc. without having to hard-code each "known type" into the program itself.)

html->escaping the included text files is a good idea, and I'll try to use that as the "protype" for testing these changes. Figure it will be at least a day or two. Sun/Mon are days I have very little programming time.



PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Plugins:http://LinkSQL.com/plugin
Quote Reply
Re: [RELEASED] Multiple Upload Graphic&File Attach In reply to
Thanks for the reply! Yes, pulling into the detailed template is exactly what I want to do and this plugin sounds perfect.

As far as the HTML encoding, I don't really care if it's stored as a text file or an HTML file, but integrating the escaping as part of the template tag processing sounds like a good approach.

That's essentially what I've done at this point, only with displaying text from a field instead of from an external file. I wrote a quick little plug in to escape the text of certain fields before displaying the detailed page. The text is too big for the field, though, so that's why I need the external file.

thanks for the plug in! We'll definitely buy it!

Ashley