Image Handler 3 Support Thread (for ZC v1.3.9)

Huh? I thought the point of Image Handler was that it cached the files. If you delete them then what is the point of having Image handler? If the store has any level of traffic whatsoever the cached images are just going to be re-created pretty much straight away and you just slow down the page load for some customers.

A much better solution would be to have a server that has enough disk space to store all the images that are needed for your store.

niccol:

Huh? I thought the point of Image Handler was that it cached the files. If you delete them then what is the point of having Image handler? If the store has any level of traffic whatsoever the cached images are just going to be re-created pretty much straight away and you just slow down the page load for some customers.

A much better solution would be to have a server that has enough disk space to store all the images that are needed for your store.Nods in agreement..:yes:

Querk:

*Use it wisely.
*It is not, that my solution is the best. Is only solution which works well for me. If you have a better solution -- share it please with community.
*I am not a Jenius - i only edit some PHP code from internet.
(original page is here -http://www.devshed.com/c/a/Administration/Cron-Job-Tutorial-Crontab-Scheduling-Syntax-and-Script-Example/)
*cron setup is different on "different" server.
*And the last -- sorry my english - i am not native U.S. I am only a student :smartalec:

I agree with niccol.. Your solution is NOT recommended for ANYONE.. The point of the cache folders is to help improve site performance. (A HUGE reason to use Image Handler) Your solution trashes this feature and in fact will probably slow performance down..

My "better solution" (since you asked)?? As niccol points out, host your site on a server that will not put restrictions on your site that will prevent you from using Image Handler. Chances are these restrictions will eventually limit your ability to run any kind of decent website anyway..

Hold on Querk, I think there's a confusion between bmz_cache and cache here. This charset problem produces thousands of log files in the cache folder. On the other hand, the bmz_cache folder holds cached images which are required and will be generated again when you delete them.

I had the same problem with thousands (not just too many) files created in the cache folder every day. If you go back a few pages to post #676, you will see how I solved it based on a previous suggestion by niccol. No cron jobs or anything else: just a one-line change in a file. Read the post, see if this is really the issue and leave the bmz_cache alone.

I don't think there is confusion at my end. I agree with George.

The 'solution' posted does two things triggered by cron.

1. Deletes the log files
2. Clears some of the older files from the actual image cache.

1 is a bad idea because the log files are there for a good reason. If your site is creating errors you really want to sort that out not just delete the messages. A process that you went through I believe successfully, George. If the character encoding is causing a problem with html_entities then there are ways of getting around that. This is not really a Zen issue but is a php issue.

2. Is a bad idea because it makes image handler a bit pointless and increases server load during customer page load.

If your hosting is not large enough to store all the cached images then you need to get larger hosting. Or alternatively not use image handler and let the images be re-sized client-side.

Nick, I hope that you didn't misunderstand me: what I meant is that Querk (not you) is confusing the cache log files with the bmz_cache image files.

I fully agree with you that the cache log files should not be deleted with a cron job without being examined first. My "solution", thanks to your suggestion, just does not create log files from character encoding any more. Other log files are of course created by Zen Cart for different reasons. And, obviously, there's no point in deleting the bmz_cache as this defeats the purpose of having IH installed.

^^ First of all, I know the purpose for "cache" and "bmz_cache".

*Cache is an error log.

*bmz_cahe is "like a RAM for PC" (or internet temp, or Browser cache --> it stores image files, to speed things up)

I know that is "sort of" B*******t delete log files. But there was so many. It prevent me from connecting to server. Cron was only solution. I am a novice in "this PHP-zencart-servers-world" and you must understand that it is frustrating not have a quick solution for impatient customer.
I read every log file, that appear. I was solid in debugging. Only error i had to debug was that "charset thing".
Everything was working on page, therefore i decided to delete logfiles. (I have another errorlogfile in webadmin in our webhost, i see every error on server, therefore i decided that too)

:lamo:
To debug that error (from what i read)

You mean like this?

**error log

charset `windows-1250' not supported, assuming iso-8859-1 in .../bmz_image_handler.class.php on line 690

Change code FROM this

$alt = addslashes(htmlentities($alt, ENT_COMPAT, CHARSET));

TO this

$alt = addslashes(htmlentities($alt, ENT_COMPAT, cp1251));

?

(if yes, good ^^ --> log file stoped to appear (not caused by cron, it was turned off))

bmz_cahe is important, but complete clear bmz_cache one per week is not that bad idea. (for customer which do not know "how point and click on -- imagehandler/admin/clear cache" is cron better idea) ... me think...

Yes, that is the kind of thing that George was talking about. It is better to solve the error than just delete the log file. There are issues with html_entities and certain character sets so, in those cases, this line of code will create errors.

If people, including me, sounded abrupt in the last few posts, then I am sure we apologise. The thing is that advice that is posted on this thread is taken by the readers to be 'semi-official ' and if some of us think that there is bad advice being posted then it helps other users if we say so.

In my opinion, using cron to clear the bmz_cache folders is not good advice.

The files in that folder only need to be cleared in certain circumstances. For instance, if the size of images on your site is changed. Otherwise deleting the files just means that image handler needs to recreate them, which is not only pointless but actually uses processing resources

Again, just my opinion.

@George - no I didn't take it that way. :smile:

niccol:

Yes, that is the kind of thing that George was talking about. It is better to solve the error than just delete the log file. There are issues with html_entities and certain character sets so, in those cases, this line of code will create errors.and I need to point out that AT NO TIME was it ever clear that THIS was the real issue Querk was having..

niccol:

If people, including me, sounded abrupt in the last few posts, then I am sure we apologise. The thing is that advice that is posted on this thread is taken by the readers to be 'semi-official ' and if some of us think that there is bad advice being posted then it helps other users if we say so.Exactly.. which is why I made the statements I made.. I don't want ANYONE thinking that regularly clearing the bmz_cache folder "just because" is a good idea.. Because as niccol correctly points out, it's just NOT good advice..

I also do NOT want people who follow the advice posted here to get the impression that creating a cron job to delete the PHP error log files stored in the cache folders is a good idea... and again it was NOT clear in Querk's posts what the REAL issue he was having was nor was it clear that what was REALLY being advocated was resolving the issue before deleting the error logs. It just looks like advice and code to delete the error logs using a cron job -- no mention of the REAL problem or the solution used to resolve the REAL problem.. just code to delete the error logs.

niccol:

In my opinion, using cron to clear the bmz_cache folders is not good advice.

**The files in that folder only need to be cleared in certain circumstances. For instance, if the size of images on your site is changed. Otherwise deleting the files just means that image handler needs to recreate them, which is not only pointless but actually uses processing resources **

Again, just my opinion.

@George - no I didn't take it that way. :smile:Nods in agreement.. :yes:

On a different note

DivaVocals knows that I am developing a different version of imagehandler. However, I am doing this in two different ways. (this one is different to the one you have, Diva) The first way is re-size on upload. The second way is re-scale when the image is used.

The second way simply creates a scaled version of the image in a directory on the server. It does this the first time that size is requested. After that first time it uses the stored version.

It is at a very early stage but if anyone want to give it a go on a development site (NOT A LIVE STORE) then that would be great. It's advantage is that it is a single file :-)

It has limitations at the moment so you may have issues if your server is configured in certain ways and if your images are large.

It is VERY simple and really at this stage is proof of concept rather than a finished article. But if anyone can add some feedback then it might turn into something. There is a read me file in the zip.

Thanks

Nick you KNOW I love you..:hug: and you know I am all for what you are doing with your new image management mod (which BTW, I'll start testing tonight and FINALLY get you some feedback..:smile: Kinda excited to see what you've been cooking up..:smile:)

BUT
(you know what I'm getting ready to say right?????? :laugh:)

Perhaps we should move this discussion to a new thread?? I don't want to take this support thread too far off topic.. :smile:

niccol:

On a different note

DivaVocals knows that I am developing a different version of imagehandler. However, I am doing this in two different ways. (this one is different to the one you have, Diva) The first way is re-size on upload. The second way is re-scale when the image is used.

The second way simply creates a scaled version of the image in a directory on the server. It does this the first time that size is requested. After that first time it uses the stored version.

It is at a very early stage but if anyone want to give it a go on a development site (NOT A LIVE STORE) then that would be great. It's advantage is that it is a single file :-)

It has limitations at the moment so you may have issues if your server is configured in certain ways and if your images are large.

It is VERY simple and really at this stage is proof of concept rather than a finished article. But if anyone can add some feedback then it might turn into something. There is a read me file in the zip.

Thanks

Fair Point :smile:

It is at:

http://www.zen-cart.com/forum/showthread.php?p=1096872#post1096872

@Diva
Note that what is posted here is entirely different to what you have. Scale on demand rather than scale on upload. Still deciding :smile: As there is no real solution for IH on 1.5 at the moment this is just my quick fix for that problem.

Hello

Got a wee bizarre user end question - for some reason images with the extension JPG are not being resized, picked up - but images with file extension jpg are (i.e down to teh image extension being in capitals).

Where can I change/amend image settings so image handle recognizes the image file with the image extension being in capitals - there are 2 many images for me to go through and rename these manually to having a lower case extension.

I've had a look through the files but I can't see what I need to amend - any ideas?

peanut77:

Hello

Got a wee bizarre user end question - for some reason images with the extension JPG are not being resized, picked up - but images with file extension jpg are (i.e down to teh image extension being in capitals).

Where can I change/amend image settings so image handle recognizes the image file with the image extension being in capitals - there are 2 many images for me to go through and rename these manually to having a lower case extension.

I've had a look through the files but I can't see what I need to amend - any ideas?

It's not the Image Handler 3 that is case sensitive, it's the server's OS. Windows's system is not case sensitive, so .jpg and .JPG are the same. Operating system like Linux is case sensitive, so those two extensions are different. I guess that your server is running on a Linux host.
I suggest you should keep your image files with .jpg extensions so that everything will work fine :cool:

edit: Suggest you should run "ren .JPG .jpg" in dos command so that you earn time renaming all your files :)

Hello - thank you for your super fast repsonse! much appreciated and yes the hosting space is linux based.

I don't actually run the site - I am just putting some upgrades in place, a wee lady runs it and I know I wouldn't be able to explain how file extensions names should work.

Re your suggestion : edit: Suggest you should run "ren .JPG .jpg" in dos command so that you earn time renaming all your files :) could I pick your brain a bit further on how to do this to ensure I pick up the correct folder ? I've only ever used dos command for very basic stuff like pinging!

Thank you very very much.

Hello

Sorry was being totally thick forgot I need to hold down shift on the folder to select the command prompt so it is only run on the contents of that directory!

Thanks you so much for your solution.

peanut77:

Hello

Sorry was being totally thick forgot I need to hold down shift on the folder to select the command prompt so it is only run on the contents of that directory!

Thanks you so much for your solution.

You are welcome! Just try my suggestion with some of your file locally to see how fast and easy it works and then try for all your images so that when you are ready just start uploading :yes:

niccol:

Fair Point :smile:

It is at:

http://www.zen-cart.com/forum/showthread.php?p=1096872#post1096872

@Diva
Note that what is posted here is entirely different to what you have. Scale on demand rather than scale on upload. Still deciding :smile: As there is no real solution for IH on 1.5 at the moment this is just my quick fix for that problem.I have some thoughts/opinions of my own on this point.. will see you on the new thread.. :smile:

peanut77:

I don't actually run the site - I am just putting some upgrades in place, a wee lady runs it and I know I wouldn't be able to explain how file extensions names should work.Why NOT?? Why do you need to tell her how file extensions work at all?? Just SIMPLY tell her that JPG is NOT the same and jpg.. I've explained this to PLENTY of so-called "non-technical" folks and they get it.. Make it REALLY easy.. tell your client that she can't use capital letters ANYWHERE in her files names or the site will break.. Clients don't need to know WHY this is.. that answer is probably too technical for them.. They just need to know this is how things work.. THAT is a concept that clients understand very easily..

For the record, Zencart handles the jpg, JPG, jpeg, JPEG extension fine they should all work and resize fine. the only reason they wouldn't work would be a server issue.

The only other time any sort of issue would occur is if you ftp up a jpeg as an additional image and its extension doesn't match the primary image.

eg
if the primary image was bob.jpg, and you ftped the image bob_2.JPG, the second image wouldn't show as an additional image because the extensions don't match.

if you uploaded the additional image via imagehandlers additional image upload facility, its extension would be changed to match the primary image

Nods in agreement..:yes:

And there you have it straight from the book of nigel..:smile:

nigelt74:

For the record, Zencart handles the jpg, JPG, jpeg, JPEG extension fine they should all work and resize fine. the only reason they wouldn't work would be a server issue.

The only other time any sort of issue would occur is if you ftp up a jpeg as an additional image and its extension doesn't match the primary image.

eg
if the primary image was bob.jpg, and you ftped the image bob_2.JPG, the second image wouldn't show as an additional image because the extensions don't match.

if you uploaded the additional image via imagehandlers additional image upload facility, its extension would be changed to match the primary image