Quantity of resized images in bmz subfolder

[torvista]

I note that bmz folders are created based on the first letter of a filename.

I name images with a prefix to reflect the manufacturer...hence all from the same manufacturer start with the same letter. In the case in point I have the original images split into folders per product group (15,000 over 90 folders) for ease of management and to avoid a filesystem choking on the quantity of the listing.

But, in the bmz subfolder, it places them all, at two resolutions, so in theory 30k images in one folder, and this will continue to grow with this single maufacturer. While the "issue" that brought this to my attention was that Beyond Compare can "only" do a 10k listing via FTP, is this likely to be a real issue for *nix filesystems?

Or, I suppose I need to rename all those images so they get split up.

[lat9]

Are you using the hashed or unhashed versions of the image names?

[torvista]

My admin says Hashed or Readable: Readable.

[lat9]

This might be a duplicate of #72; please confirm.

[torvista]

This issue (concern really, as it is not a problem, yet), is indeed similar to this post: https://www.zen-cart.com/showthread.php?222983-Image-Handler-5-(for-v1-5-5)-Support-Thread&p=1339941#post1339941

which suggested the cached files should reside in subdirectories named the same as the source image subdirectory (under /images). Sounds like a good idea.

The suggested, further modification in https://github.com/DivaVocals/zen_Image-Handler/issues/72 I don't understand.

[lat9]

I didn't understand what that code's doing either, as I've not had the chance to circle-back on these IH issues.

[torvista]

Subsequent to the explanation being added to #72 I still prefer the idea of putting the cached images in a folder with the same name as the original base image. One would assume the logic used by the shop owner when structuring the original subfolders would be just as applicable to the cached subfolders...

[lat9]

I agree, for those 'Readable' images (with the suffix added to denote the image's sizing). I'm thinking that an additional 'formatting type' will be added for stores currently using 'Readable', since they might have hard-coded /bmz_cache/{whatever} in a product/category/ez-page's text.

[torvista]

they might have hard-coded /bmz_cache/{whatever} in a product/category/ez-page's text.

If I want to hard code an image link I would not dream of doing it to an auto-generated image that could be cleared from a cache at any point....it must be to a permanent image.

I can't consider doing that as anything except just plain wrong, so it should not be considered as a use-case to be allowed for, in my opinion.

[brittainmark]

See pull request #207 and issue #72 I have created Mirrored that uses the readable format and duplicated the images directory structure under bmz_cache.

[brittainmark]

Think this is fixed by fix to issue #72

[lat9]

Think this is fixed by fix to issue #72

@torvista, do you agree?

[torvista]

I agree! In production already. Thanks for the effort. I'd make it the default install option.