Database approach for additional images

Perhaps this get more exposure here than it did on github...

I've been trying to come up with an explanation as to why Zen Cart still uses the ancient directory scanning method for additional images, instead of holding that data in the database. Since most (if not all) other modern platforms use the database driven approach, I can't help but wonder if they're all wrong and only Zen Cart knows what's good... :shocking:

The approach I'm suggesting would make things sooooo much simpler for the end user because additional images could easily be added while creating a product or updating it, without the need to navigate away to use Image Handler. Of course, IH could still be used for optimizing images (although this also needs a new modern approach, but that's a different story).
It also eliminates the need to follow exact naming conventions, meaning you could easily have "product.jpg" as main image and "different_view.jpg" and "another_view.png" as additional images (notice the different extension!)...
It would also allow template creators to have a rollover image with a simple lookup instead of scanning the entire images directory let's say 12 times on a product listing page with 12 products...
And, as I had already mentioned on Github, incoming supplier feeds would no longer be a nightmare to handle.

A few screenshots are below...

**Anyone interested to test it out, or perhaps any interest of getting it into core code? **
If anyone wants to give it a try, please PM me for a zip file. I've also included a converter file so any existing products with additional images can automatically populate the database and start using this approach.
Create product:

Preview product:

Edit product:

Probably easier to just take a look: DEMO SITE

All comments welcome. And yes, it CAN be turned into a drag-and-drop which would probably be my next step if this gets adopted.

Even though I have one site that would work better under the old method, I like the idea.

I currently get close to ten thousand images for the one site (generally four to five images for over 2,000 products). They come in a zip and are named XXXxxx.jpg, XXXxxx_1.jpg, XXXxxx_2.jpg, etc.

Using Space Tornado Renamer, I can bulk change the case and change the numbers after the underscore to lowercase letters.

Then, I upload all the files to the server. As I add a product, I enter the basic file (already on the server), and the additional images automatically get accessed.

There was originally a problem doing this all in the /images directory, but that was fixed.

While that site would not necessarily benefit from your proposal, I would hate to see the current method totally go away, and would have to key in all those filenames rather than just process and upload them.

Having that option remain and the uploaded files picked up by the products when editing would be great as well.

:bigups:

I saw the discussion on GitHub and immediately thought it was a great idea. But I am not the one to be convinced.
As dbltoe wrote, a way to pickup multiple images rather than looking for/importing each of them one at a time, would be a great bonus.

dbltoe:

Even though I have one site that would work better under the old method, I like the idea.

I currently get close to ten thousand images for the one site (generally four to five images for over 2,000 products). They come in a zip and are named XXXxxx.jpg, XXXxxx_1.jpg, XXXxxx_2.jpg, etc.
Lucky you. I've seen data feeds with additional images named like someone just used bin2hex(random_bytes(16)) to get the names... So, instead of just importing the feed and copying the images, I had to rename each additional image to follow the main image name. Which is OK, but then the supplier would come up with 2 new images added to the feed and now you no longer know what was previously renamed and what's new...

Using Space Tornado Renamer, I can bulk change the case and change the numbers after the underscore to lowercase letters.

Then, I upload all the files to the server. As I add a product, I enter the basic file (already on the server), and the additional images automatically get accessed.
This would still work because I also built a "converter" which you can manually run from the admin when needed and it would automatically populate the database.

While that site would not necessarily benefit from your proposal, I would hate to see the current method totally go away, and would have to key in all those filenames rather than just process and upload them.

Having that option remain and the uploaded files picked up by the products when editing would be great as well.

:bigups:
Having that option remaining in the frontend pretty much kills the idea of avoiding directory scanning.
As torvista mentioned, he's perfectly organized and keeps a well structured system in place with multiple subdirectories etc. I think he's one of the few who do that - I've seen soooooo many sites just upload everything into the images folder so you end up having thousands of files in the same directory.

I didn't do actual performance testing to present the values here, but imagine having 10k files and you do a dir scan and run a preg_match on it - I don't think anyone would say that's faster or less resource-greedy than a database lookup... And now imagine 5-10-20 people browsing the site at the same time and triggering this action from the product_info page. CPU spikes guaranteed.

But again, that option still remains for the admin to run WHEN NEEDED using the admin converter script... It's not available on the demo site, but if you want the zip file to see it in action, just let me know.

pilou2:

I saw the discussion on GitHub and immediately thought it was a great idea. But I am not the one to be convinced.
As dbltoe wrote, a way to pickup multiple images rather than looking for/importing each of them one at a time, would be a great bonus.

Yup, already done and runs on ADMIN request. Please see above.

I like it and I played in the DEMO site. Are the width and height settings for the display of the additional images on the product page controlled by the small image settings? I hate that, the images look off, squished a bit, they need to maintain aspect ratio. Once you have added the additional images you don't know what their filenames are anymore, when you hover them you see the product name which is not helpful, in this case "Matrox G200 MMS", and having to right-click open in new tab to see the filename for that image. I would rather when hovered it showed the filename.

What happens when, in the future, on another product, I were to attempt to upload an additional but it happens to have the same name as an additional image used on another product? As we all know naming things becomes problematic when there are lots of things to name, and avoid collisions...

Valid points, Mike, although pretty much just cosmetics. Updated.

And yes, it WAS using

<?php echo zen_info_image($img['additional_image'], (is_array($pInfo->products_name) ? $pInfo->products_name[$_SESSION['languages_id']] : $pInfo->products_name), SMALL_IMAGE_WIDTH, SMALL_IMAGE_HEIGHT); ?>

Not anymore. Simply full size and let Bootstrap handle the rest.

barco57:

What happens when, in the future, on another product, I were to attempt to upload an additional but it happens to have the same name as an additional image used on another product? As we all know naming things becomes problematic when there are lots of things to name, and avoid collisions...

Good question! Honestly, no idea. What happens when you try uploading the MAIN image with the same name that's already assigned to another product? I'm assuming the image simply gets overwritten (the file itself) and new entries are added to the DB... Correct me if I'm wrong, please.

barco57:

What happens when, in the future, on another product, I were to attempt to upload an additional but it happens to have the same name as an additional image used on another product? As we all know naming things becomes problematic when there are lots of things to name, and avoid collisions...

Apologies, I was not using my computer when I replied that question...

At the moment, it's using the same "Overwrite Existing Image on Server?" as the main image upload does. So, if that option is set to Yes, you'll overwrite the already existing image and update the product you're editing. If you choose No, the pic doesn't get uploaded and only the file name is returned so it can be set as additional image.

Since this is still not part of core code, I didn't want to re-arrange the admin product page, but this would make more sense if the "Overwrite..." radios were at the end of the images section (both main and additional). I've just changed it on the demo site in hope it would be more user-friendly.

balihr:

Probably easier to just take a look: DEMO SITE

All comments welcome. And yes, it CAN be turned into a drag-and-drop which would probably be my next step if this gets adopted.

Submit it to the repo... Then it can be tested =)

I was hoping for a discussion of the idea itself and hearing about the ups and downs, and why it's not a good idea to use it (if there are valid arguments). Even more welcome would be thoughts by users, not just the dev team and the few people active on the github repo. And a live demo is usually a much easier for everyone to test out...

But sure, submitted: Github