Posted by stella on September 4, 2008 at 2:03pm
11 followers
| Project: | Image Assist |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hi,
The class name for custom sized images in the 5.x-2.x version of img_assist has changed from just "image-img_assist_custom" to image-img_assist_custom-WWxHH where WW is the custom width and HH is the custom height. This makes it very difficult for lightbox2, other modules and themes to (a) theme the image assist images and (b) find them using javascript.
Would it be possible to re-instate the old class name convention or at least add another class name to the list, e.g. image-img_assist_custom image-img_assist_custom-WWxHH ?
Cheers,
Stella
Comments
#1
We probably overlooked the fact that the filename is used as class name when this (trivial) feature was implemented. Of course, Image Assist should always use a default class name. I am even not able to imagine a use-case for a separate "custom" class, so we might drop that completely? Is there a use-case for those different image size preset classes at all?
#2
As long as there's a image assist specific class name, then lightbox2 is happy (or will be after a few adjustments). Lightbox2 also looks at the filename and removes the classname from it to get the original sized image, but i can figure that bit out.
Cheers,
Stella
#3
Hm - while we're at it, we could improve that, too. Do you have an idea how we could include information about the target size filename?
Unfortunately, I cannot find a related issue currently, which was a feature request to allow configuring the image size for images in the popup window. However, accounting for that idea, we'd have to pass on the file that should be used in the popup window, resp. Lightbox.
How about a (XHTML-Strict breaking) custom attribute? Abusing another attribute? Injecting the filepath as additional class name? Or just replacing/adjusting the href attribute of the link?
#4
What's the status of this? Lightbox2 doesn't need the filename to be modified, just as long as there's an image assist specific class name.
#5
bump
#6
I'd have to vote no to an XHTML-Strict-breaking attribute. Many developers try very hard to keep things Strict, and some browsers are very fond of breaking things if they aren't given what's promised by the DOCTYPE.
Maybe a class like "img-filename-My-Quirky-Fil3_name.JpG" would not be optimal, but I'd say it's the best shot.
#7
This patch simply removes height and width information from class.
#8
This patch simply removes height and width information from class.#9
Sorry :)
#10
The patch-link in #7 leads to http://drupal.org/files/issues/. :(
#11
Very strange... Reuploading.
#12
I have applied this patch to the latest (3.x) dev version of image assist. Since this small line of code is identical I hoped there is no big deal.
I actually does trigger lightbox now. Was so happy that it "worked" finally. Sadly just to find out that lightbox cannot find any image now and displays the dummy only as soon as I use a custom size :(
Is there a solution to this?
Many thanks in advance!
#13
Uhm, that patch was horribly wrong - it limits you to create only 1 custom size.
Please test attached patch.
#14
Thanks a lot for the quick response.
I have applied the patch. But lightbox is still not being triggered. Checking the image with Firebug it seems to still have the dimensions in the class name.
#15
Patch in #13 not working for me.
#16
Please make sure you flushed your *filter* cache. Image Assist provides a link at the top of its configuration settings page to do so.
#17
@sun, your patch modify $attributes array, but it is not returned outside of the function...
#18
subscribing
#19
This remains an issue in the latest Image Assist 5.x beta, with an added twist: where as Image Assist previously used pre-defined classes for "thumbnail", "preview", etc., it's now using custom sizes for everything. This wouldn't be a huge deal except for the fact that there is no consistent custom class name for the images that I can style (as previously noted, it's including the height/width information in the class name).
As a solution, couldn't there simply be an additional "img_assist_custom" class (above and beyond the standard "image-img_assist_custom-125x176" class) ? Would this confuse Lightbox? (I'm not using it, so I'm not sure what's needed for its integration to work properly).
As was mentioned elsewhere in the thread, is there a reason why the height/width information is being included in the class? Are people dynamically generating CSS to apply to these classes, or is there some other use I'm not seeing?
#20
You forgot to pass $attributes to image_display. Thus the last line of your patch should be return image_display($node, $label, $attributes);
#21
Here's an update to sun's patch from #13. Only change as per #17 and #20 is that $attributes is now added to the image_display() call.
#22
Tired of update patches that doesnt work and confusion because of all different versions of the same module?
I just did this to my img_assist.module, line 1497 (6.x-2.0-alpha4):
Changed:
$size['key'] = 'img_assist_custom-' . $width . 'x' . $height;Into:
$size['key'] = 'img_assist_custom';...and then I flushed all caches. Voila!
Problem solved.
#23
This patch works great for me with latest 3.x dev branch. Any chance of getting this committed?
#24
Confirmed, the patch in #21 still fixes this issue.
For those using lightbox2 there was a work around recently committed in #303780: Image Hander fails on custom image presets
#25
Thanks for reporting, reviewing, and testing! Committed to 3.x.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
#26
Automatically closed -- issue fixed for 2 weeks with no activity.