3.06 - wpg2-tags not able to use all available resizes

moogie

Joined: 2007-01-16
Posts: 13
Posted: Sat, 2008-05-03 20:28

I've been trying to figure out a bit of a strange problem, and hopefully someone can shed some light as to why G2/WPG2 is behaving like this.

I'm trying to use <wpg2>ID|SIZE</wpg2> tags to choose the best resize fitting into our blog layout. The albums/images have a bunch of resizes available, each them working if accessed directly. However, WPG2 doesn't seem to be able to use all of them.

Example:

<wpg2>1172|400</wpg2>

BTEV events from this:

- Source ID:1172 Mine Type:image/jpeg
- FIND 0x450 Sizes ID:1174(209x140) ID:1173(900x600) ID:1175(128x86) ID:1176(180x120) ID:1177(600x400) ID:20999(400x267) ID:1172(1280x853)
- WPG2 ADD LIGHBOX TAG TO G2 ID:1173
- WPG2 TAG G2 IMAGEBLOCK CALL ID (1172|400)

The result is correct in that the correct lightbox target image is chosen (1173), but the img src also points to the same image - instead of either 1177 (if the size specifies height), or 20999 (if the size specifies width) - which is it btw?

I've tried a variety of different size's, just to see which size get's used and when. The only size's I've seen output have been images 1174 (the thumbnail of the image), 1173 (the first re-size) and 1172 (the original image). All other resizes don't appear to ever be chosen.

Any ideas what could be causing this?

 
ozgreg
ozgreg's picture

Joined: 2003-10-18
Posts: 1378
Posted: Sun, 2008-05-04 03:09

Firstly love the BTEV debug Posting, top marks :-) it makes my job soo much easier.. No quick answer jumps out however I suspect and have to prove the issue might be around the fact the different sizes are not in any order.. Need to prove this however..

____________________________________
Wordpress / Gallery2 (WPG2) Plugin, , WPG2 Documentation, WPG2 Demo

 
moogie

Joined: 2007-01-16
Posts: 13
Posted: Sun, 2008-05-04 06:34

Thanks ozgreg. I did some quick testing, and it looks like what you suspected is true. I played around a bit with recreating the sizes, and as soon as I got them in order, everything works fine - all the sizes are then usable.

Any thoughts on how difficult this would be to fix to work properly even if the sizes are not in order?

 
ozgreg
ozgreg's picture

Joined: 2003-10-18
Posts: 1378
Posted: Sun, 2008-05-04 09:06

Yep I can confirm this is an issue.. I whipped up a fix, you can try it out here

____________________________________
Wordpress / Gallery2 (WPG2) Plugin, , WPG2 Documentation, WPG2 Demo

 
moogie

Joined: 2007-01-16
Posts: 13
Posted: Sun, 2008-05-04 13:21

Thanks ozgreg! Unfortunately it looks like this didn't quite fix the issue yet..

Looking at the changes you made, I am wondering if you were trying to fix the correct problem. The fix you applied would probably work if the problem was that the image chosen for lightbox was incorrect, however, my original problem is that the actual displayed image (the <img>, not the <a href> target) is chosen incorrectly. Similar problem, but the resolution is likely different.

Looking at how WPG2 handles this, it looks like the choice of the image is left up to the G2 template engine. In wpg2imageblock.tpl, the {g->image} function is used to get the actual imageblock html, and this is where the wrong image size is also present. I wonder if this is a problem with G2 itself, or in how the {g->image} is called?

 
ozgreg
ozgreg's picture

Joined: 2003-10-18
Posts: 1378
Posted: Sun, 2008-05-04 22:36

Hiya moogie,

Sorry I should have posted I can only fix the lightbox image selection, I cannot until WPG2 3.1 remove the dependency we have on the Gallery2 Module (imageblock) so my hands are tied when it comes to correcting any issues with the selection of the resized images |xxx ones..

After WPG2 3.1 we will have our own image function which will free us up from many constraints

____________________________________
Wordpress / Gallery2 (WPG2) Plugin, , WPG2 Documentation, WPG2 Demo

 
moogie

Joined: 2007-01-16
Posts: 13
Posted: Mon, 2008-05-05 14:20

Ok, I actually suspected something like this. Thanks anyway, looking forward to 3.1 :)