Image Scaling

niccol:

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.

niccol:

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.. :no:

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..:no: 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

niccol:

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..

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

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?

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.Nods in agreement..:yes: 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..

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.

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 :smile:

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.

gjh42:

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/index.php?article=315

gjh42:

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..
gjh42:

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

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.
:laugh:Of course.. I wasn't actually suggesting that exact make up for the file name..:laugh: 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..

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?

It would be possible to have two unrelated products in different categories with the same name, but one product linked into two categories still has only one product id. So the product id prefix would work, though I still think it's better to alert to conflicts and allow user discretion.

gjh42:

It would be possible to have two unrelated products in different categories with the same name, but one product linked into two categories still has only one product id. So the product id prefix would work,** though I still think it's better to alert to conflicts and allow user discretion**.I agree... :yes:

So, we are talking about the upload modifier section.

And we are talking about the renaming part of that.

So, how about:

• There is an admin switch to turn renaming on and off.
• There is an admin selection of the renaming filter.
• There is a simple ( for a developer ) way of adding new renaming filters
• As standard there is at the minimum a 'hard rename' renaming filter

The hard rename would

• rename to a sanitised version of the product name
• put everything in lowercase
• add the product id at the start of the name

Other renaming filters could do whatever developers wanted to do. Up to them. Their risks.

If renaming was being used the user would be advised if there was still a naming conflict and be given the chance of supplying an alternative name.

Of course, renaming is another one where it needs to be considered if we hope to create a retro-active renaming. So, does it need the ability to rename existing images?

Hmmm, that is possible but slightly scary the potential for disaster is pretty big. Someone adds a dubious filter and then goes for bulk rename and all their images disappear. Not good.

Perhaps with this and any other bulk changes you need to copy the files and then have an 'accept these changes or rollback' page. That would be a bit tedious because you also need to store all the previous image names for writing back into the database.

OK. Version 0.2 of the image scaler.

It does :
-- image scaling
-- additional image uploading
-- variant uploading
-- admin setting for all kinds of stuff
-- client side clean-up with an admin switch
-- admin side clean-up with an admin switch
-- clean-up just deletes files that haven't been touched for a while
-- you can set the maximum number of files to be deleted in one go to spread the load around a bit

It doesn't
-- categorise the files into directories as Nigel suggested yet. But I have a bit of a plan for the next version
-- do any of the things that I regard as 'upload modification'. Renaming, size limiting, watermarking and sharpness.

Install is just a rename of admin and an upload. Just make sure that you are logged in and not about to be logged out. The installer won't play nice if the first page it sees is the login page.

Uninstall. There is a file to upload in a separate directory in the zip. It is just the same old auto_loader file with an uninstall flag set. It will roll back the database changes and delete the files that were uploaded.

Only one core file is over-written which is application_bottom.ph which I don't think will cause you any problems. It is not deleted on uninstall but the new version won't cause problems anyway.

Let me know

Nick

Awesome.. something to play with this weekend.. :D

niccol:

OK. Version 0.2 of the image scaler.

It does :
-- image scaling
-- additional image uploading
-- variant uploading
-- admin setting for all kinds of stuff
-- client side clean-up with an admin switch
-- admin side clean-up with an admin switch
-- clean-up just deletes files that haven't been touched for a while
-- you can set the maximum number of files to be deleted in one go to spread the load around a bit

It doesn't
-- categorise the files into directories as Nigel suggested yet. But I have a bit of a plan for the next version
-- do any of the things that I regard as 'upload modification'. Renaming, size limiting, watermarking and sharpness.

Install is just a rename of admin and an upload. Just make sure that you are logged in and not about to be logged out. The installer won't play nice if the first page it sees is the login page.

Uninstall. There is a file to upload in a separate directory in the zip. It is just the same old auto_loader file with an uninstall flag set. It will roll back the database changes and delete the files that were uploaded.

Only one core file is over-written which is application_bottom.ph which I don't think will cause you any problems. It is not deleted on uninstall but the new version won't cause problems anyway.

Let me know

Nick

version 0.3

just a few display changes. I haven't tested this one so much but it shouldn't need it. If it causes issues then try version 0.2.

This one just has a nice method of selecting products and lets you hide some of the information if you aren't interested in it.

niccol:

version 0.3

just a few display changes. I haven't tested this one so much but it shouldn't need it. If it causes issues then try version 0.2.

This one just has a nice method of selecting products and lets you hide some of the information if you aren't interested in it.

is this right no admin folder :unsure: found it's in the uninstall folder is that right can you check it for me

Darn. It is the 'control' folder in that version.

I'll upload another with the correct naming :-)

Thanks for pointing it out.

niccol:

Darn. It is the 'control' folder in that version.

I'll upload another with the correct naming :-)

Thanks for pointing it out.

no prob just didn't want to try it and have a thunderbolt wizz out of my pc:lamo: