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

[niccol]

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';
		}			

	}

[DivaVocals]

Cool will try this out this weekend..

[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 :-)

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.

[DivaVocals]

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

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

[mc12345678]

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.

[niccol]

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';
			}			
		}
	

	}

[DigitalShadow]

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?

[DigitalShadow]

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?

[DigitalShadow]

oh and the & symbol causes this error in google_base

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

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