Alternate images field project

[Joss]

I have talked about this before, but was just wondering would anyone be interested in working on an alternative to the current image field system?

Completely unpaid and no real reason for doing this, other than I think it might be something that would be attractive to those migrating their way from some other CMSs.

So, this is the idea:

The new image field would be very similar in look and settings to the current field, but the upload system is changed completely.

The new image field would upload images into a folder hierarchy under /assets/files/images/ and not create a folder for each page - this would be unlikely to hit folder number limits.

The upload size would be controlled by the image field setting as now.

You would be able to create folders from the image field upload panel, if permission exists to do so for a particular role. (This is so folders can be set by an admin if they want to force users to put them into particular folders)

Having uploaded the images, you can then select which images are to be part of this field on this particular page, to the limit that is set for for that version of the field

A new DB table is created that holds information on all uploaded images for all pages - it is associated to the new upload system rather than the page. Columns can be added for description, author, date uploaded, copyright, anything else you wanted. These columns are global, obviously. The relevant data, like "path," is referenced by the instance of the image field for a particular page ... somehow. This would mean that an image can be moved to a different folder (using a management system) without breaking the link on a particular page as the new path would be taken from the DB table.

NOTE: The system should be clever enough so that when an image is moved, the cached version of the image are also moved.

The selected images in the new image field can be used in template files and RTF exactly as now, though resized versions would need to cached to the new folder system - that might complicate things, or not. I am not sure how the current system works in that regard.

The upload/library part of the image field would probably ignore any resized versions and only display originals. 

There would need to be a stand-alone version of the upload interface that can double up as a management system - aspects of this system should have specific roles.

Folders should also be subject to permissions so that roles are only allowed access to certain folders, if that is useful.

An additional component could allow user specific folders.

It may also be worth incorporating other media file types for use in other fields.

Anyway, a bit vague at the moment!

To be honest, I like the current system, but it does not suit certain types of site very well:

News sites need a central repository as they frequently reuse images and need to restrict who can use what.

E-commerce sites frequently need access to product images for promotions, blogs and so on, outside of just the product entry.

My feeling is that since the current system is perfect for many uses, it should not be changed and therefore it make more sense to create a separate system so that you can use it as an either/or - maybe with a global command to stop the current image field from being available if it is not going to be used at all, simply to avoid confusion with multiple developers on a project.

Warning - my techy knowledge is useless, so my contribution will be mostly planning, interface design and general complaining. 

EDIT:

Not sure whether a fully expanded version of this with permissions and complicated management might be best as a premium module ... just a thought.

[winston]

I have avoided using the /assets/files/<pageid>/ directories because I don't like the resulting URLs.

I have been copying the images as I reference them to a more descriptive location. Crude but effective:

$im = $page->images->first();
$fn = $im->basename;
$image_url =  "/comix/{$artist->name}/$fn";
$image_fn = $_SERVER["DOCUMENT_ROOT"].$image_url;
if (!file_exists($image_fn)) {
    $of = $im->width(800)->filename;
    print "<br>Production file doesn't exist, making a copy";
    print "<br>Copy ";
    print copy($of, $image_fn) ? "successful" : "failed";
}

What I was looking for when I found this was a way to assign images other data fields, which Joss also talks about in the original post. I want to use the uploading and image storage features of PW, but each image needs more data than just Caption. It needs source, Figure number, blah blah.

I have been reading around on it, and noticed that there is something called $image->page(). Is there an internal template I could change? Or is there some capability already built in that I haven't tried?

I will be looking into it further but would appreciate any pointers. Thanks!

[Joss]

It is rather easy to create your own. If your image requires a lot of info, then there is no reason why you cannot either just dedicate a page to each image or create a repeater field which includes an image field plus whatever else you wish.

Just for interest, if you have been avoiding the usual directory structure, are you still able to take advantage of all the other powerful API bits that comes with the image field like resizing, cropping, caching and so on?

[winston]

Thanks, Joss, I will try the repeater field.

Yes, I wanted to use the API functions to resize etc. I definitely wanted to input the images via drag-and-drop.

So I kept the /assets/files/<pageno> structure, but copied the files to the more descriptive URLs when I generated the page. In the original post, I made an 800-pixel copy of the image, then copied it to the images directory.

I like to pre-generate pages, and I keep a separate static copy of the page, so why not a separate public-facing copy of the image?

PW's caching isn't needed once the image is outside PW's structure; Apache just serves it. (Same goes for the pre-generated pages. No cache needed, but you have to remember to generate.)

[diogo]

Just had a quick thinking about this and the first impression that I have is that it would be enough to have the same approach as Soma's image manager (1 page -> one folder) but add the ability to change the url to that folder in the .htaccess (probably this would have to be done manualy after knowing the ID of the page) and extend the files module so ->url uses the new url instead.