TOPIC:

Just to note, i do agree that the current image uploading can/should be done better. When for example the blueimp script is going to be used there are some things that can be done better. I think also the client resize option is there.

Am having the blueimp script myself for uploading attachments so it works. It can be modified to take on the images part too. So yep something for JEM 4.0.x


Hmm, about the cleanup orphaned files: are you sure there is no option for it? Am currently running my own custom version so am not sure at this time of how it's done in JEM 2.3.x but can say that in my custom version i do have have some cleanup functions.

Ah well, but thing is that you"re making some good points and maybe it can be addressed in the next version.


Greetings,
Blue

For the image uploading etc ...

Do you have more requests/ideas about it? Frontend, backend.

This as we can take a peak at it

This is how I see it:
A user uploads an image, no mater what filesize (that is, limited by max file size set in php or systems settings)
The file is resized to at least two sizes, large and small.
The large image has the original aspect ratio, with a fixed width one can set in the JEM settings.
The small image has a fixed width and height, so one can create a square thumbnail.
Preferably there’s also a medium size, which can be used for mobile.

The file is uploaded when the item is saved, not when editing the item like now. So if one changes it’s mind while editing the current selected image is uploaded.

On save the resizing is done.

And even beter: images are resized and saved in a user directory, so you don’t end up with thousands of images in one directory over the years.
So if it’s a new user: create a directory within images/jem/events/ with the id of the user. Else find the directory of the user and store the image in that dir.
Have the user search / browse his own directory in the frontend to reuse an image.

Thx Stevent.

Just brainstorming:
Backend at the moment

With using userdirs you most likely want to store the whole path of the image in table. Would say in all accounts that eould be better. This way for example the userid can be in the path and makes things easier. But using ids will also give some insight to others about what usersids are on the site.

When user is logged in he/she will upload image. Onsave the id of user is recognized and attached to image-path. If imagefolder of user does not exist it will be created.

Images are for example stored in
As talk is about 3 images i do wonder if it makes sense to use "small" as folder. Maybe thumbnail would be better. In events folder the normal one goes and within thumb we do output the thumbs. What can be done is to prepend the small ones with an eventid number and width/height numbers.

A problem can be when later on there is decided not to use userdirs..or when using imagedir from the beginning as there will be a userid check so previous images won't be there. With exporting/importing you've also to make sure that the user does exist.

Ah well just thinking...

Hmm, it seems possible to use something like userdirs.. Ofcourse it will lead to more questions etc... but for the basics i did add a custom folder "ud" to my test version of JEM 2.3.0. In that folder resides the user folders (userid). When on backend the user can only select images from their image folder. Question will be "if editing" should the image if an image from another userid is there should the reference be deleted? etc... etc... For now i'll keep it very basic..

// currently (still)waiting for Ernst to reply on things so will look at it more