Image Scaling

[DivaVocals]

Re-reading.

My solution to duplicate names is just not to allow it. Previously I have versioned images by putting an extra string on the end. So image.png becomes image_v01.png and doesn't overwrite.

This is what I meant by stating "inform the user on-screen of a duplicate name situation". I think just simply not allowing it without at LEAST an on-screen message for the store admin as to why the image was not processed is necessary.. This gives the shop admin an opportunity to correct the product name to fall inline with the requirements.

With Zen there is just the added complication of making sure that that image does not appear as an additional image. Putting the string at the front is an obvious solution but not all that elegant!

which is why naming based solely on product name is a bit tricky and will require some thought.. Because even if the product names were not duplicated (and eg the image names will not be duplicates either) the way that Zen "recognizes" additional product images will still present a challenge that needs to be resolved.

Using one of my clients for example she has product names like this:

1. Indian Remy Machine Weft Soft Fro Texture, 4 oz.
2. Indian Remy Machine Weft Bodywave Texture, 4 oz.
3. Indian Remy Machine Weft Kinky Straight Texture, 4 oz.
4. Indian Remy Machine Weft Silky Straight Texture, 4 oz.

Images named based on these product names will probably be interpreted by Zen Cart as additional images for these products. So all four of these products could end up with 1 main product image and additional images from the other products. Not good..

It seems that the way to resolve this is to assign some kind of unique value to each product which is then appended to the beginning of image names. Elegant?? IMHO, I think this is a very elegant option as it solves several different issues at once.. IMHO something like this is necessary unless you want to get into re-writing the way Zen Cart recognizes additional product images.. Appending a unique value to the beginning of each image name ends up satisfying the requirement needed to prevent "accidental" additional images, minimize errors due to duplicate image names, and incorporates the product name into the image name (for those who insist that this makes a difference for SEO). I think this is a doable solution.

So using my client's product names as an example, in my thinking the final image name could end up being something like this for example:

1. 96727a88f8f9687b0978f2326a0958eb.indian-remy-machine-weft-soft-fro-texture-4-oz
2. 46111986d71173c1fd18077f12e71d9e.indian-remy-machine-weft-bodywave-texture-4-oz
3. 2504371a156068516c1eb499877c3cce.indian-remy-machine-weft-kinky-straight-texture-4-oz
4. 184771a9f3ea3bda364748cda80d54a5.indian-remy-machine-weft-silky-straight-texture-4-oz

[DivaVocals]

I like watermarking too. But my point is that it could happen once on upload. And never again. ( Hmmm, existing stores may be a problem?)

Agreed, but to your second point, there must be a way to generate them for existing stores..

[gjh42]

If the user, on having a duplicate filename detected at upload, has the option to customize the new saved filename, that would be ideal.

[gjh42]

Images named based on these product names will probably be interpreted by Zen Cart as additional images for these products. So all four of these products could end up with 1 main product image and additional images from the other products.
...
indian-remy-machine-weft-soft-fro-texture-4-oz
indian-remy-machine-weft-bodywave-texture-4-oz
indian-remy-machine-weft-kinky-straight-texture-4-oz
indian-remy-machine-weft-silky-straight-texture-4-oz

These image names would never be used as additional images for each other, only for indian-remy-machine-weft- (or shorter) as a base name.

The standard base naming watchfulness would still be required, unless you just want to make it foolproof and avoid the possibility of there ever being conflicts...
But I don't like the mega-multi-digit prefix; surely a smaller number of random characters could make conflicts vanishingly unlikely?

[DivaVocals]

If the user, on having a duplicate filename detected at upload, has the option to customize the new saved filename, that would be ideal.

Nods in agreement.. Indeed this would be ideal functionality..

Question/Comment for niccol:
Would renaming a product be one of the triggers that would re-generate the images?? Using Conor's URI Mapping mod, if a product is renamed, the URI can be re-generated if the shop owner desires.. I would think a similar kind of functionality would also be useful in an image management mod which generates optimized images based on the product name..

[gjh42]

Here's a thought (really an enhancement over any current functionality): Test new uploaded filenames against existing filenames for either new or old being a subset of the other, to avoid any possibility of unintended basename co-opting. Not sure how much load that would add to the processing, but if feasible it would foolproof the filenames for real without adding meaningless prefixes.

[niccol]

The standard base naming watchfulness would still be required, unless you just want to make it foolproof and avoid the possibility of there ever being conflicts...

Well it would be nice to obviously! But...

The thing is that it isn't to hard to hook into the upload process to make alterations. there is just a little edit to make in a couple of core files.

I guess if there was an over-write issue you'd drop out of the process and present a page that allowed the image name to be edited and then restart the process. It would obviously be nice to do that in a more interactive way ( like with an alert window ) but that is pretty impossible without re-writing the entire upload structure to be a bit more ajaxy. So, if there was conflict you'd serve a 'there was a problem' page with a rename option, I guess. I can't see a really elegant way of doing this practically so if anyone has any ideas then let me know.

@diva
Yes, I guess you'd want to trigger rename on product name change, ideally. For the main image but not the scaled versions. The scaled versions would sort themselves out.
Having said that it causes issues elsewhere so not sure.

Ha ha! I kind of am on the verge of posting the second version of the scaler. I haven't even started to think about the upload modifier! Although in many ways that is simpler. Apart from all these subtleties we are talking about

[niccol]

Here's a thought (really an enhancement over any current functionality): Test new uploaded filenames against existing filenames for either new or old being a subset of the other, to avoid any possibility of unintended basename co-opting. Not sure how much load that would add to the processing, but if feasible it would foolproof the filenames for real without adding meaningless prefixes.

It is a good thought. It is completely possible an the load really isn't an issue. Well, I don't think so because it happens in admin and it isn't going to be that slow.

It is more a question of how to present the information to the user that there is a naming problem. Going to sleep on that.

I kind of don't like adding a great big identifier at the start of the image name. I wonder if a simple solution is to put the product id in front of the image name? That should be unique. Off the top off my head I think the database work on the products table may not have been done by the time the upload is processed so there would be issues there. Need to look at the code. But perhaps you could give it a temporary name and then rename once a product id has been created.

I have been staring at a screen for too long today so will sleep on it.

Thanks again guys for all the advice.

[DivaVocals]

These image names would never be used as additional images for each other, only for indian-remy-machine-weft- (or shorter) as a base name.

Are you sure?? Because though I haven't tried naming files exactly like the example I provided, this has been my experience with additional images in Zen Cart.. This FAQ seems to say that similarity in image names would be the reason why:
https://www.zen-cart.com/tutorials/i...hp?article=315

The standard base naming watchfulness would still be required, unless you just want to make it foolproof and avoid the possibility of there ever being conflicts...

Agreed.. I don't think complete error proofing is possible, but I do believe that there should be enough functionality to warn about certain errors and give the end user an opportunity to make the proper corrections..

But I don't like the mega-multi-digit prefix; surely a smaller number of random characters could make conflicts vanishingly unlikely?

I kind of don't like adding a great big identifier at the start of the image name. I wonder if a simple solution is to put the product id in front of the image name? That should be unique.

Of course.. I wasn't actually suggesting that exact make up for the file name.. Just to create some example of possible file names, I grabbed the random stings that IH3 now prepends to the beginning of the file names. It was the quickest down and dirty example of randomly generated file names I could get my hands on.. My point was that some kind of formula/algorithm could be used to "calculate" a random sting to prepend to an image name based on the product name. Doing both could give some reasonable assurance that the file names would be unique without inadvertently triggering Zen Cart's additional image detection.

what about using both the category and product ID?? this would ensure that the prepended ID is TRULY unique..

[niccol]

Additional Images
It is ok if they share part of the name. The problem is if all of one name appears in the other name. At the start obviously.

Naming
Well I don't think it needs category because if they are in different categories surely they are linked and therefore have the same product image? Or is the whiskey starting to addle my brain?