Image Scaling

[DivaVocals]

I hear what you are saying, but let me throw this out there then..

If multiple products were sharing the same images, I would assume that that this would be intentional on the shopowners part. In this second situation the shopowner would need options if they made changes to thier product images to update the re-sized images. So I would think that deleting and re-generating the images is not an issue.. If there are products which will no longer be sharing images, the shopowner will simply upload the new image to the appropriate product and re-size on the fly would take care of re-sizing and displaying the new image.

The exception would be in the rare instance where the shopowner did not pay attention to how their images were named and thus had products accidentally sharing images. In this second situation the shopowner would want to fix this so that their products display the correct images. Therefore deleting and re-generating the stored re-sized images is not an issue..

If you think about this, in the current flavor of IH3, the clear cache function does just this (not efficiently I admit). It removes all the cached images so that they can be re-genrated... It is suggested that shopowners do this only when they've made significant changes to their existing product images, or when they have deleted products from their shop. (No need to store resized cached images when the product no longer exists) This only affects the stored chached images, the originals are left intact. JMHO, but I think this is important functionality in any new image app..

Clean Up.
Hmm, not really sure. The issue here is that there is a danger in any file deletion. (Ha ha - that is an understatement). In this case though I guess we are only talking about deleting scaled images. If a mistake is made there then they just get rescaled.
At the moment I have an admin page that handles additional images and what I am calling 'variants'. A variant is just an alternative version of a scaled image. So if there is a 300 by 200 version of an image stored, you can upload a different version of that file. So, that means that any one of the scaled images can be replaced with an image of your choice. So, kind of like having different small medium and large images but even more flexible.
So, to get to the point - on that admin page I am scanning the directories and putting a warning up if there are scaled images that have not been accessed for more than 24 hours (just an example time) . If 'redundant' files are found then there is an option to delete them.
Obviously this could be run from cron. But I am kind of loathe to go down the cron route as it is a can of worms. Easy but configuring cron is challenging to describe for every server!

The problem with automating if a product image is changed is that another product might be using that image too. I know not likely but possible. Maybe most likely with duplicated products. So, I kind of think it is better to let the system above pick up the old file once it has sat around doing nothing for a while.

[niccol]

Point taken.

Having the equivalent of the IH clear cache is straight-forward anyway. You just delete everything

I think that my way which is detailed above is a bit nicer than that for two reasons. It only deletes the images that have not been accessed recently which seems sensible. And it alerts is it thinks it needs to be done.

So, both the above options should be iincluded.

Other image tidying up:
Yes I can see this. It would be nice if scaled versions were deleted on:
-- product image change
-- product deletion
What other situations?

Actually, I think this is great but I don't think it is critical. My scanning process is going to pick these files up the next time round anyway. Which will mean that there are only ever scaled versions on the server that are actually being used.

Which leads me to think that cron is the way to go despite the technical issues with getting users to set up a cron job successfullly. Because if you have cron running a scan and clear-up of files that are not being used then you don't actually need to do anything else.

[DivaVocals]

Point taken.

Having the equivalent of the IH clear cache is straight-forward anyway. You just delete everything

I think that my way which is detailed above is a bit nicer than that for two reasons. It only deletes the images that have not been accessed recently which seems sensible. And it alerts is it thinks it needs to be done.

So, both the above options should be iincluded.

Other image tidying up:
Yes I can see this. It would be nice if scaled versions were deleted on:
-- product image change
-- product deletion
What other situations?

Actually, I think this is great but I don't think it is critical. My scanning process is going to pick these files up the next time round anyway. Which will mean that there are only ever scaled versions on the server that are actually being used.

Cool.. I'll give this some more thought..

Which leads me to think that cron is the way to go despite the technical issues with getting users to set up a cron job successfullly. Because if you have cron running a scan and clear-up of files that are not being used then you don't actually need to do anything else.

Cron functionality built into the add-on?? -- Yes..

Having to have shopowners who BARELY know how to use their cPanel let alone the intricacies of setting up a cron job, setup a cron job?? and then having to explain it OVER AND OVER AND OVER again to these same kinds of users???? -- **draws in a deep breath**

[niccol]

Well you made me think about this as I drove a friend to the airport.

What about putting a function in application_bottom so it fires at the end of page load?

-- it checks if a clean-up has already happened this session. If so there is no processing overhead because it does nothing. Using a session variable as a flag
-- it checks when the last clean up happened and if that was less that a day ( a week, a month, a whatever ) ago sets the session variable to 'don't bother'. Which is a very minimal overhead.
- if is more than a day ( a week, a month, a whatever ) it does a clean up and then sets the session variable to 'don't bother'. Which is a bit of a larger overhead.

That way one customer a day ( a week, a month, a whatever ) will suffer a slight performance lag at the end of their first page load. And the 'scaled images will never be bloated.

What do you think?

[DivaVocals]

Well you made me think about this as I drove a friend to the airport.

I have that effect on people..

What about putting a function in application_bottom so it fires at the end of page load?

-- it checks if a clean-up has already happened this session. If so there is no processing overhead because it does nothing. Using a session variable as a flag
-- it checks when the last clean up happened and if that was less that a day ( a week, a month, a whatever ) ago sets the session variable to 'don't bother'. Which is a very minimal overhead.
- if is more than a day ( a week, a month, a whatever ) it does a clean up and then sets the session variable to 'don't bother'. Which is a bit of a larger overhead.

If I understand this correctly you are talking about re-size/optimization on demand, and then cleanup on demand as well?? If so I like it!! It's simple, and "idiot proof" as we like to say at my office.. K.I.S.S. software (Keep it simple stupid )

That way one customer a day ( a week, a month, a whatever ) will suffer a slight performance lag at the end of their first page load. And the 'scaled images will never be bloated.

What do you think?

Clarify a few things for me though..

• I assume the frequency of when the cleanup check is performed is an admin configurable option?? (If not it probably should be..)
• When you talk about the one customer a day suffering a slight performance lag while this check takes place, are you saying that this one customer viewing one product will trigger the re-generation of ALL product images or just the product they are currently viewing??

[niccol]

Well, yes, I was kind of thinking of letting the user choose either or both methods. The requirements are quite different on a store that has three visitors a month and a store with lots of vistors and frequent catalog changes.

Well, what I am saying is that the scaled images will be scanned to see if one has not been accessed for more than 'the period of time'. Which would suggest that they are not actually needed. Only those redundant images would be deleted. Any images that have been used in the last 'period of time' would not be touched.

If the function was fired in application_bottom it would fire on the first page load of each user. Most of the time it would do nothing. Once a 'period of time' it would delete the redundant images but not create any images. So, it is fast.

I did think of limitting the number of images that an individual page load deleted. So, a individual page load would delete only ten images for instance and leave the rest for the time being. Not sure about that. As I am only talking about deleting images that are not actually being used, I can't see that there would be that many. ( famous last words ) I mean we are basically talking about orphaned images. I guess if you had uploaded new images for a whole chunk of the catalog then there might be a few...

I am not sure that the user would even notice if it fired at the bottom of the page once the page has loaded. Possibly, one could do it in an ajaxy way anyway so it really didn't effect the page at all.

So there are a couple of admin settings:
-- frequency of clean up
-- period of time after which a file is considered redundant
-- type of clean up manual, automatic or both.

[DivaVocals]

Sounds awesome.. Can't wait to see the next version of this..

Well, yes, I was kind of thinking of letting the user choose either or both methods. The requirements are quite different on a store that has three visitors a month and a store with lots of vistors and frequent catalog changes.

Well, what I am saying is that the scaled images will be scanned to see if one has not been accessed for more than 'the period of time'. Which would suggest that they are not actually needed. Only those redundant images would be deleted. Any images that have been used in the last 'period of time' would not be touched.

If the function was fired in application_bottom it would fire on the first page load of each user. Most of the time it would do nothing. Once a 'period of time' it would delete the redundant images but not create any images. So, it is fast.

I did think of limitting the number of images that an individual page load deleted. So, a individual page load would delete only ten images for instance and leave the rest for the time being. Not sure about that. As I am only talking about deleting images that are not actually being used, I can't see that there would be that many. ( famous last words ) I mean we are basically talking about orphaned images. I guess if you had uploaded new images for a whole chunk of the catalog then there might be a few...

I am not sure that the user would even notice if it fired at the bottom of the page once the page has loaded. Possibly, one could do it in an ajaxy way anyway so it really didn't effect the page at all.

So there are a couple of admin settings:
-- frequency of clean up
-- period of time after which a file is considered redundant
-- type of clean up manual, automatic or both.