As always you make 1/2 sense .... I blame your lack of (recreational) drugs and booze :(

I've thought this through ( 3 cheers for the blonde and all that ) and I can only see one problem ... maybe 2 .... ish ...

"Billions of folders" .... correct but, from a coding pov it's the easiest path ( "rm media/blogs/myblogs/foo.jpg -fr" removes any/all cached versions )

Also, I upload a fair few pictures, I'd hate a "640/480" folder that had millions of pictures in it ( ok, ok, .... maybe 2 dozen :| ) that I'd carefully separated into subfolders already ..... I have my OCD "must tidy the server up" moments :|

A possible compromise would be to have a media/blogs/blog/sub/folder/.evocache/fit-both-requirements/your_cool_picture.jpg ... would require a tad of a recode though .... good news is, it's not me that would have to recode it .. so you have my support :D

¥

I think there is a point of confusion here. You wouldn't have ALL photos in one "size identified" folder: rather the images in any given b2evolution path would go there. For example you always start with either media/blogs/ or media/users/ and follow it with either BLOG_NAME or USER_NAME. Somehow it knows how to keep track of stuff when you change a blog name and I don't user user names but I'll assume it keeps track of that detail too. So clearly it is going back to BLOG_ID and USER_ID but displaying a NAME in the back office. So anyway that means you always get

media
    blogs
        blog_1
        blog_2
    users
        user_1
        user_2

Currently if you upload 100 images to media/blogs/blog_1/ you will get 100 folders named after each image. Same with blog_2, even if the image name duplicates. In each folder is (at least) one image named "fit-80x80" for the thumbnail the file manager will display. So the way it is now, assuming 100 images in each of the 4 folders above, there will be 400 folders named for the images, and 400 images named "fit-80x80". Ultimately there must be 400 images, but do we really need 400 folders for them?

What I propose is that, in the example above, there would be 4 new folders called "80x80" under each of the blog and user specific folders. Each of these folders would then hold 100 images that happen to match the name of the original uploaded file.

Another minor detail: currently the resized image name is ... the image size. Which is information about the image, but clearly not directly informative about the image. What *is* the image showing? When this gets fixed the PATH will be informative about the image, and the image name will remain the image's name. So we would go from

media/blogs/blog_1/my_uncle_bob.jpg/fit-80x80.png

to

media/blogs/blog_1/80x80/my_uncle_bob.png

Don't worry: I'll fix it for ya ;)

hmmm... actually "WWWxHHH" isn't good enough. One would want to have the third param (resolution?) in there as well to ensure isolation. So "WWWxHHHxRR" would be the better method.

Okay this keeps getting deeper the more I look, so I am totally outclassed by it. Here are some points worth considering:

• The .evocache folder is useless because all it does it hold more folders.

• Upon creation of a blog or user folder, b2evolution should also create .WWWxHHH folders for all image sizes supported by function thumbnail() in inc/files/model/_file.class.php. By this I mean NOT /.evocache/WWWxHHH/ because the .evocache level is useless.

• A plugin or skin needs to easily add to the list of cases in the switch statement in function thumbnail() in inc/files/model/_file.class.php, and of course create the required folders for resized image files.

• Modifying a file to fit a skin (or more specifically: fitting a case defined in function thumbnail() in inc/files/model/_file.class.php) should not depend on a logged in person viewing the page before others get to view the file.

• THE IMAGE FILE NAME SHOULD NEVER CHANGE NO MATTER WHAT THE IMAGE DIMENSIONS ARE!!! This is why naming folders after images and images after dimensions is completely wrong. The folder should identify the dimensions and the name should identify the file ... even if the user is uploading meaningless file names directly from their camera.[/list:u]

B2evolution rocks hard, but sucks wind on this detail. I will continue to work on hacking it to be better, but I really do hope the serious developers understand what I'm saying here and make it happen in a way that isn't just a script kiddie playing with stuff above his station.

Ok, lets compare the two methods :

Your method removes 1 folder from the url and the last part of the name is the images real name : /media/blogs/myblog/WWWxHHH/image.jpg

The cores way has an extra folder depth and the image name is the 2nd last part of the name : /media/blogs/myblog/.evcocache/image.jpg/fit-www-hhh.jpg

Your method means that when deleting an image, or moving it between blogs, the core has to go through multiple (known) folders and remove each instance of the image. It also means that if you want to delete/move an image via FTP or SSH then you have to do the same thing, I can't remember how many "standard" sizes there are off hand, but it's a few files to move

The core way means you just delete/move the actual image & the .evocache/image.jpg/ sub-folder no matter if it's via the core/FTP/SSH. The other bonus is that if a plugin produces a "non-standard" size in the .evocache then it will also be automatically removed by deleting the .evocache/image.jpg/ sub-folder.

A possible compromise ( to end up with the filename being the filename and still have copy/delete be easy even if done manually ) is to have another folder layer which would allow all the easy delete/move stuff and would leave the image name intact : /media/blogs/myblog/.evocache/image.jpg/WWWxHHH/image.jpg, or, if you have a "source" sub-folder where the original image lives, then you can remove the /.evocache/ level and also save yourself a delete/copy step : /blogs/myblog/image.jpg/source/image.jpg

¥

Good point re moving and/or deleting. Hadn't thought through that layer at all. I'd say worrying about the person who handles images through FTP isn't really valid because that is outside the scope of how b2evo handles itself. Fair?

Ultimately it's going to be the same number of image files right? Like, each real image might have up to 5 resized images (without considering sam2kb's "custom-WWW-HHH-RE" hack or possible plugin-generated sizes). So that would be a maximum total of 6 copies of any given image.

(Hey I wonder what happens if I give it an image that is 400 wide then link it to a post with a skin that selects 'fit-720-HHH'?)

The thing I'm looking at lately is how much extra stuff shows up in the actual page sent to the visitor, and the path to a linked image is part of that. For example, and WAY OT: by getting rid of the evo tool bar I was also able to get rid of all the styles that apply to the evo tool bar. Why send what a visitor doesn't need right? Also all styles for ImgZone. So when I look at the path to an image, and getting back on track here,

domain.com/media/blogs/.evocache/image.jpg/WWW-HHH.jpg
domain.com/media/blogs/.WWW-HHH/image.jpg

So from a "how much do you send the visitor" angle the second is obviously better. Plus retaining the name only makes sense. Heck I miss the days when everything went into the media folder!

hmmm... I just published a post with a resized image in my wordpress installation. That app uses a totally different method of storing uploads: they go by /year/month/ and use a file name that includes the width and height. For example

wp-content/uploads/2008/08/dscf0020-300x225.jpg

is the path to a resized image where 300x225 is the resized values. When browsing via FTP all these images are next to each other when sorted by file name. It doesn't lend itself to multiblogs multiauthors very well, but it does offer a way to retain the image name in the end result file. So that should be an easy hack to get done. Oh and WP doesn't seem to allow me to upload images through anything but the post writing utility. Kinda lame, eh?

Plus there is also the evo_files table in the database. Seems to me that somehow the database could be used to track a file's alternative versions? Like, it has file_root_type and file_root_ID. I THINK that says if you uploaded to a blog or a user (root type?) and what the blog ID is. I have no uploads to a user folder so this is a guess. Anyway couldn't a table exist for something like evo_filecopies that uses file_ID to collect path information for resizes? Wouldn't that facilitate movement and deletion internal to b2evolution? I figured out the hard way I have zero skills at making efficient database tables though, so for me to even think of this is total fail waiting to happen :(

This is all way beyond me though. I could probably get something that seemed functional but would most likely fall apart if let out there into the wilds. I mean, I didn't even consider how it deletes or moves files - duh. I think I'll be happy with getting the resized names to also retain the original image name :)