image_width and image_height are empty

[sbzx]

Hi Gang,

For some reason after upgrading to 1.7RC1 Jay Soto's Delicious v1.1 template stopped working correctly because index.php would not return a valid value for <IMAGE_WIDTH> and <IMAGE_HEIGHT>. After some investigation I found that the problem is located in these lines:

$thumbnail_extra = getimagesize(ltrim($cfgrow['thumbnailpath'], "./")."thumb_".$image_name);
$image_extra = getimagesize(ltrim($cfgrow['imagepath'], "./").$image_name);
$image_width = $image_extra['0'];
$image_height = $image_extra['1'];

$tpl = str_replace("<IMAGE_WIDTH>",$image_width,$tpl);
$tpl = str_replace("<IMAGE_HEIGHT>",$image_height,$tpl);

$local_width = $thumbnail_extra['0'];
$local_height = $thumbnail_extra['1'];

Furthermore, "ltrim($cfgrow['imagepath'], "./").$image_name" would return a path without a leading slash as a result of which getimagesize() returns nothing. So I made a slight modification like this:

$thumbnail_extra = getimagesize("/".ltrim($cfgrow['thumbnailpath'], "./")."thumb_".$image_name);
$image_extra = getimagesize("/".ltrim($cfgrow['imagepath'], "./").$image_name);

It works now. However, I am not sure what I corrected was a flaw in PP1.7RC1 or something else in my installation.

[austriaka+]

really funny.
Since $cfgrow['imagepath'] usually is "../images/" (the path seen from admin) ltrim($cfgrow['imagepath'], "./") will result as "images/" what is the correct path seen from index.php.
Anyway "/images/" should be the same as "images/"

In my blog (which uses the almost most actual developer version of 1.7) the width and height is shown correct without any hack...

[sbzx]

What is really funny is that I have a second installation on my local Linux which does not show this symptom. The one that experiences the problem is on eleven2, pretty much a standard environment. Plus it is an upgrade from 1.4.2 that worked perfectly before... Well, I don't know, I think I'll give it some more thought.

[austriaka+]

yes, do so and tell us please! 'cause I have no idea :-/

[sbzx]

I guess it's what it is...

Site A, the one that works without the hack:

Guessed imagepath: /var/www/html_un/images/
Configured Imagepath: ../images/
Guessed thumbnailpath /var/www/html_un/thumbnails/
Configured Thumbnailpath ../thumbnails/

Site B, the one that needs the hack:

Guessed imagepath: /home/sbzx/public_html/images/
Configured Imagepath: /home/sbzx/public_html/images/
Guessed thumbnailpath /home/sbzx/public_html/thumbnails/
Configured Thumbnailpath ../thumbnails/

Corrected.

[dakwegmo+]

Does the one that needs the hack work if you change the configured image path to ../images?

[sbzx]

No. Leaving the hack in the code and changing the image path to ../images results in an empty $image_extra. However, restoring the original code works perfectly with the new and correct image path.

[austriaka+]

funny that the configured image path is changing on upgrade procedure.
I guess we have to have a look into that

[JETC]

Ok, so I *just* updated my blog to pixelpost v1.7.1 and I was scratching my head when <IMAGE_WIDTH> and <IMAGE_HEIGHT> wasn't returning any values. I re-configured the image path and everything works again.

Just letting you guys know that it's still a problem. Maybe change the upgrade/install to configure the paths to ../images/ and ../thumbnails/?