Re: 4 days and 8 hrs a day later - hover effect still not working
Good point about there not being a small suffix.
maybe we can agree on something like:
Code:
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';
}
}
Re: 4 days and 8 hrs a day later - hover effect still not working
Cool will try this out this weekend..
Re: 4 days and 8 hrs a day later - hover effect still not working
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.
Re: 4 days and 8 hrs a day later - hover effect still not working
Quote:
Originally Posted by
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!!
Quote:
Originally Posted by
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:
Re: 4 days and 8 hrs a day later - hover effect still not working
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.
Re: 4 days and 8 hrs a day later - hover effect still not working
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.
Code:
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';
}
}
}
Re: Image Handler 4 (for v1.5.x) Support Thread
Image Handler Readme
Quote:
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?
Re: Image Handler 4 (for v1.5.x) Support Thread
from google_feeder
Quote:
PHP Warning: preg_match(): Compilation failed: missing ) at offset 69
or
Quote:
PHP Warning: preg_match(): Compilation failed: unmatched parentheses at offset 88
image_handler
Quote:
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?
Re: Image Handler 4 (for v1.5.x) Support Thread
oh and the & symbol causes this error in google_base
Quote:
PHP Warning: DOMDocument::createElement(): unterminated entity reference
Re: Image Handler 4 (for v1.5.x) Support Thread
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.
