upload.module advanced features (eg. move image.module features to core)

According to this http://drupal.org/node/25704, it is one of the most downloaded modules on Drupal.org.

Also, part of it is already in core (image.inc).

So, for me, it makes sense to move it to core as well.

But: keep it minimalistic, with fancy addons as contribs.

+1

But - I wouldn't want to lose site of the fact that the image.module is WAY TOO BASIC and needs some more features to make it actually useful. The initial discussion regarding img_assist.module in the top20 page is a great example of the problems with the workflow of adding images.

+1. The image module really belongs in core.

Uwe.

robert - i'm flattered that you think so highly of the code... Dries and I talked about putting image in core when I was doing the rewrite ... and decided against it. I can't totally remember why now...

I'm essentially +1 to this idea, and am fully willing to continue maintaining a core image.module (and adding enhancements, etc).

One thing I think we need to figure out though is ... what do folks want most out of a core image.module? (i.e. do we want galleries? just easy inclusion in blog posts? bulk uploading? etc...)

+1 HOWEVER.... it wasn't ready and yet released for 4.6. I'd say it's a good consideration, but I advise caution. The upgrade to 4.6 just about destroyed my working images. Derivatives were broken and though fixed now, had some major issues that took a while to get sorted out. Yes I backed it up.. so no big deal. But, still it was far from ready to be released. I had actually considered solutions other than drupal for my sites during that time, but I stuck with it. Others might not have been as persistant. Images are a very important part of most web sites so it should go in eventually. I'd have given the initial 4.6 release an alpha rating at best. I would suggest that if it goes in, it go in as a very basic module and then additional modules that add features be created.

I think mass upload would be good to include. Galleries and various other features could be external modules.

I'd volunteer a +1, if it meant that the breakage would be less likely to occur in the future. I'm still running 4.5.2 because image.module is too critical to my website, and I can't deal with it breaking. If making it a core component meant tighter integration and upgrade handling all around, I'd be much happier.

Bulk upload is a key feature for me, by the way, one of the other reasons I haven't forged ahead. I make heavy use of the old image.module galleries, but if additional modules will give me any gallery ability, I'm not very particular about the features or the exact form. The pictures just need to be accessible.

i'm gonna see what I can do on this front... assigning so i don't forget :)

+1 for me.
So far most/any issue's that people have experianced seem to have come down to permissions issues specific to the server configuration that they were on and whether the files/images directory existed or not..

+1 core it. please.
With the galleries.
More work needs to be done, and could be at a later date. They way it is now is functional as far as i'm concerned. The img_assist module still needs work but again something like it IMHO should be in core too.
There needs to be more modules like these essential to content creation in core.
Quick! Get it in before the code freeze. :)
If it has Images, Galleries and the Free Tagging, 4.7 should be good.

so here's the thing... robrecthj has been working on some image.module enhancements in his sandbox (one of them being splitting image.module & imagegallery) ... it's still being worked on... but that might be the best place to look for moving stuff into core.

as in - he's already working on it and i'm watching that :)

What's the current status?

Let's see if we can get image module in core for 6.x!?

I have a proposal (that I would like to work on): how about to upgrade upload.module to do image control?

If you go to ?q=admin/settings/uploads you can see that it already has some fields to control image uploading (in this case the maximum image size). What is missing here? Not much, but a few features would be nice:
* maintain options per role and add options per file extension
* for images add options to allow automatic thumbnail generation, of various types with different generated names and to be placed in selected folders
* implement an hook, that when uploading an image detects it is an image and can be called (eg. by image module) to open a "html image editor" in the page, doing some post-processing to the image
* add a field to the "files" table to allow files grouping (this will allow to separate several files upload within the same node)

What do you think?

Some ideas for image capability within upload.module: http://drupal.org/node/78093

Not sure. I think people want to upload images and embed them in their posts. This is not what the image.module does -- or at least, it is not what the image module is optimized for. I'd prefer a solution that is slightly more integrated in the 'natural workflow' of most users.

@Dries: The question here, is to centralize a way of uploading images to *any* node giving that way advanced capabilities. Then, it's *so* easy to create an "image" node type (with CCK) that follows the 'natural workflow' using this "advanced uploading system", to anyone that only wants an "image" node type.

Think a bit, if with the upload.module we can upload and control *any file type*, with special attention to image file types -- making much more easy to embed them in posts, and much more important, allowing them to use automatic thumbnails to be embedded and styled (by themes) in different forms -- we don't need specialized modules that always implement the same code to do special uploading; and with give "full image capabilities to *any* node" including the "old" image node type.

Don't you would like that:
* in any node type, when uploading an image, a window could be shown in a away that you could manage the image (scale, crop, reduce)
* you could group images, and then they would be grouped (and differentiated) easily when viewing the node
* any module could intercept the uploading and create methods to pre-process files (eg. when a PDF file would be upload, a module could intercept and parse it in a way, that could extract information to insert in the node itself); for this we would need http://drupal.org/node/18934

All this from the same general and secure place...

+1 to this. A few things that would also be good:

* configurable different folders for different file types (image, pdf, office document types - whatever)

* ideally a simple interface like imagefield/upload - which allows for extension to something closer to img_assist/image.module if required.

* dynamic thumbnail/preview generation - imagecache style - to allow mass updating of derivates.

* upgrade path from image.module to the extended upload module

What most end-users and non-geeky / non-programmer want
fall into two categories

1) Just as Dries said : embed the image in blog post / forum / story without much hassle ......
just simply click browse/upload / attach and the image is attached at the beginning or end of the post [ this is what inline module does ] without having to go through any folder of uploaded images so far and etc etc

From the web-master / admin end s/he wants to define :
max permissible image size in pixels
max permissible image size in kbs ( this is probably missing per image )
image file types eg jpg, gif , png etc

2) The usual gallery, admin defined categories /albums , thumbnails, prev and next thumnails below the main image/s, ability to send the image as ecard ( missing in drupal ) AND per user album i.e if user wants s/he can have own one apart from the ones defined by admin.

Finally, keeping everything as simple as possible if its going to be 'core'.

Currently 'Image' , 'Inline' along with 'Upload' does exactly all as above EXCEPT :
1) Does not allow to define max permissible kbs per image
2) Does not allow each user to have own album
[[ 3) Link image to send ecard or hook up some stuff like digibug ]]

@misty3:

we should not forget many developers that create alternative modules, constantly duplicating "upload" code because upload.module does not provide all the required features to correctly manage any file: post-processing, intercepting, organizing; controlling and securing have minor implementations.

Did you know that if upload.module implemented just one interception and organization API there were several modules that would be reduced to simple CCK fields?!

Did you know that if uploads were done trough upload.module, all files would be inserted into the "files" table, allowing a *complete* analysis of them, including features like:
* detecting duplicate files in a way that when a user uploads the same image into two different nodes, the system detects and keeps just one file (maintaining disk used space low as possible)
* it would be easy to have a module that would work like a "directory" over the "files" table
* full site controlling of "maximum" sizes permissions per user, role, etc

Image handling in core is likely to be a part of cck migration. There's also patches for making image.inc into modules etc. so won't fix on this.

Hi anyone with a direct link to upload module that goes along with the inline module -drupal 7? Thank you
http://www.narodsafariskenya.com The space left on my site is a lot and need to cover up.