Image Handler 4 (for v1.5.x) Support Thread

What the original code actually does is take one single filename.

It then checks to see if it contains "_LRG"
It then checks to see if it contains "_MED"
It then checks to see it it contains "_SML"

( or whatever the prefixes in use actually are )

That is what one might aim to reproduce. Any comment that all filenames will result in small being chosen is nonsense. Small can only be chosen if the filename contains "_SML" . And if the filename contains "_SML" then in zen style it is definitely a small image.

Let's not loose track of what the function actually does.

Further, the above suggested change of all ifs being evaluated and not one stopping subsequent evaluation when an earlier is identified as being "the one" depends on none of the other variables being set when entering this function. Thus, if all large, medium and small are set, then the result of the series of ifs is that the image will always be identified as small....

That would be true if it was working against an image. But it isn't. It is checking an individual path ( actually an image source ) to determine whether that path is 'large', 'medium', 'small' or 'generic'.

Diva, use whatever you choose. I typed some code off the top of my head. I have no emotional involvement in it. As often happens on this forum people seem intent on making some kind of stand that seems completely unnecessary. Not enough time in the world for my code is better than your code nonsense.

Agree, no time for "pumping chests" not worth it. I never did such, concerned about the accuracy of intention of the code and consideration of final result.

As said initially, it appeared that all results would end up as small. The fact is/was that there is a separate check once it is identified as not being empty, so yes the code provided (typos corrected which wasn't even a consideration in review) would at least check against the actual filename (src).

If however, and I don't recall the naming requirements identified in the instructions, the large and medium both are identified to have the same suffix (don't know why someone would do that, but same thing for having no suffix) then under the current code, the large image would be the default to display, whereas in the first suggested code, the medium would be the result with the sequence provided. So if going with the first suggested code, to maintain the current "result" the medium check should be ahead of the large check.

That stated, there is no defined small suffix. So that check would not work and result in the image being identified as the default 'generic' and not as a 'small' (disabling functions available to small images such as the zoom on hover).

I too don't care which code is "chosen" as long as it maintains functionality and prevents at least the identified error from occurring. With whatever change(s) are made, downstream effects need to be reviewed.

niccol:

What the original code actually does is take one single filename.

It then checks to see if it contains "_LRG"
It then checks to see if it contains "_MED"
It then checks to see it it contains "_SML"

( or whatever the prefixes in use actually are )

That is what one might aim to reproduce. Any comment that all filenames will result in small being chosen is nonsense. Small can only be chosen if the filename contains "_SML" . And if the filename contains "_SML" then in zen style it is definitely a small image.

Let's not loose track of what the function actually does.

That would be true if it was working against an image. But it isn't. It is checking an individual path ( actually an image source ) to determine whether that path is 'large', 'medium', 'small' or 'generic'.

Diva, use whatever you choose. I typed some code off the top of my head. I have no emotional involvement in it. ** As often happens on this forum people seem intent on making some kind of stand that seems completely unnecessary. Not enough time in the world for my code is better than your code nonsense.**
I agree.. I was simply waiting for the dust to clear here a bit..

I'll implement and test the code you suggested (with the correction you later posted), and try the very scenario for which this is supposed to address along with all the other functionality to make sure there are no negative unforeseen impacts and let you know the result..

Niccol.. Thanks again.. I know this isn't your fav module:smile:, but honestly it was YOUR work that kept this thing standing when the v1.5.x Zen Cart release came along. I appreciate that you check in on us mere mortals here every now and then to make sure things are still okay..:smile: As you KNOW I am truly only a POWERUSER of this module..:hug:The sum total of my CODE contributions to the "under the hood" inner workings of Image Handler is pretty small. My BIGGEST contribution has been to produce (what I think have been) better user docs for this thing.. The rest of this machine is not my doing.. I'm just the keeper of the Castle here..:smile:

Good point about there not being a small suffix.

maybe we can agree on something like:

	function determine_image_sizetype() {
		global $ihConf;
		
		$this->sizetype = 'generic';

		if($ihConf['large']['suffix'] != '')
		{
			if (strstr($this->src, $ihConf['large']['suffix'])) {
				$this->sizetype = 'large';
			}			
		}

		if($ihConf['medium']['suffix'] != '')
		{
			if (strstr($this->src, $ihConf['medium']['suffix'])) {
				$this->sizetype = 'medium';
			}			
		}		
		

		if ((intval($this->width) == intval($ihConf['small']['width'])) && (intval($this->height) == intval($ihConf['small']['height']))) 
		{
			$this->sizetype = 'small';
		}			

	}

Cool will try this out this weekend..

Yup, Diva, you know my thoughts about this module. And the slightly bizarre naming conventions in Zen that are a hangover from osCommerce. And you know that I choose not to use it on sites these days :-)

If someone chooses to have the same suffix for medium and large that will mess up Zen. That really isn't an IH issue. It's a zen issue because even without IH zen would not function correctly if someone does that.

To keep Zen useful and at least slightly competitive you also know that my thoughts are that IH, or something similar, needs to rolled into the core. And that the bizarre naming conventions need to be done away with because in the modern world they are just completely limiting.

And I am more than aware that that would be lovely for you to because looking after IH takes a huge amount of work which is appreciated by some but not all. So, I would not underestimate your contribution.

niccol:

Yup, Diva, you know my thoughts about this module. And the slightly bizarre naming conventions in Zen that are a hangover from osCommerce. And you know that I choose not to use it on sites these days :-)

--------

To keep Zen useful and at least slightly competitive you also know that my thoughts are that IH, or something similar, needs to rolled into the core. And that the bizarre naming conventions need to be done away with because in the modern world they are just completely limiting.
Bizarre naming was done away with in the version that's in my Github repo.. Another outstanding Zenner provided the code that finally gave the image filenames some "normalcy".. Once I get your code snippet incorporated and tested, I'll finally submit it to the free downloads.. I know you don't like Image Handler, but you might want to check it out if for no other reason just to see that FINALLY the MD5 naming of images is gone gone gone!!

niccol:

And I am more than aware that that would be lovely for you to because looking after IH takes a huge amount of work which is appreciated by some but not all. So, I would not underestimate your contribution.Awww sweet of you to say.. :blush:

If the naming convention is considered of having the same medium and large suffix is itself considered a no-no, then would leave the first two ifs in their current sequence, though to maintain current system response (and still solve the original issue of recent) would suggest swapping them.

What about if a large image and the small images have the same dimensions? Would there be a negative effect of the "small" image sizetype being provided when the file has the suffix for a large image? If that would be a problem, I would suggest that the last if group be placed before the first.

Basically because this section is being revised from an if it matches one of these things it is assigned a size in first match sequence of large, medium, small or generic, to it's generic until proven otherwise by the last match, I would suggest that to maintain the existing behavior to invert the sequence of the three if statements.

Yup, quite right again. If a user has taken the time to create and upload small and large images that are exactly the same size and taken the time to rename them accordingly then it may well confuse the issue. But this hypothetical user is quite a confused individual anyway. And actually the way that $this-sizetype is used in the rest of the class, on first glance, it really doesn't matter. But for consistency let's change it.

	function determine_image_sizetype() {
		global $ihConf;
		
		$this->sizetype = 'generic';

		if ((intval($this->width) == intval($ihConf['small']['width'])) && (intval($this->height) == intval($ihConf['small']['height']))) 
		{
			$this->sizetype = 'small';
		}		


		if($ihConf['medium']['suffix'] != '')
		{
			if (strstr($this->src, $ihConf['medium']['suffix'])) {
				$this->sizetype = 'medium';
			}			
		}		
		
		if($ihConf['large']['suffix'] != '')
		{
			if (strstr($this->src, $ihConf['large']['suffix'])) {
				$this->sizetype = 'large';
			}			
		}
	

	}

Image Handler Readme

Make sure that your main product image files names DO NOT contain any special characters (non-alphanumeric characters such as / \ : ! @ # $ % ^ < > , [ ] { } & * ( ) + = ). Always use proper filenaming practices when naming your images

What if there are about 2000 images containing these forbidden characters? That were in place before image handler was used...

could str_replace be used to stop & symbols breaking IH?

from google_feeder

PHP Warning: preg_match(): Compilation failed: missing ) at offset 69
or
PHP Warning: preg_match(): Compilation failed: unmatched parentheses at offset 88

image_handler

PHP Warning: preg_match(): Compilation failed: missing ) at offset 36

Files with Parentheses are also a problem (as stated in the readme). Is it not possible to look at the filename and str_replace it to something that won't break it?

oh and the & symbol causes this error in google_base

PHP Warning: DOMDocument::createElement(): unterminated entity reference

Yes there is a way. I have a filter written for another Zen Cart module we could apply. But may be worth adding an alert / warning / block adding image from admin as well with characters not typically allowed in URLs being in the image filename.

Just had a look in my database.... of the 27148 images....

2882 images have ( or ) in the file name
938 images have & in the file name
71 have [ or ] in the file name
4 have @ in the file name
5 have # in the file name
158 have + in the file name
4 have = in the file name
1 has $ in the file name

I can't solve this manually...

lhungil:

Yes there is a way. I have a filter written for another Zen Cart module we could apply. But may be worth adding an alert / warning / block adding image from admin as well with characters not typically allowed in URLs being in the image filename.

:) please elaborate

Hi all, please help me. I need use chached images miniatur from image handler in my php script. Please is possible use some function, who return chached image name? How this function name?

Many thanks.

puhycz:

Hi all, please help me. I need use chached images miniatur from image handler in my php script. Please is possible use some function, who return chached image name? How this function name?

Many thanks.

Sorry.. I am not clear on what it is you are asking here.. What is it you are trying to do EXACTLY???

I have product id and I need return url of image for this product. Not image name from database, but image name/url miniatur generated by IH.

I just had a weird thing come up. When clicking on anything in admin like upload new photo, it just refreshes the page and goes back to the admin tools bit. I believe it was okay before. I checked and all the files were in place and dated the same as when I uploaded the mod. I uploaded the files again to be sure. I have added a mod or two since this was installed in Sept but I can't think what could cause this behavior. Looks like the server php build is from last Aug so no changes there. Anybody heard of this happening before?

delia:

I just had a weird thing come up. When clicking on anything in admin like upload new photo, it just refreshes the page and goes back to the admin tools bit. I believe it was okay before. I checked and all the files were in place and dated the same as when I uploaded the mod. I uploaded the files again to be sure. I have added a mod or two since this was installed in Sept but I can't think what could cause this behavior. Looks like the server php build is from last Aug so no changes there. Anybody heard of this happening before?

Nope not heard of this.. Would try rolling back your other mods and see if that rights things..