Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not work on lightboxed images (e.g. Featherlight) #189

Open
mateoserendipia opened this issue Sep 28, 2015 · 13 comments
Open

Does not work on lightboxed images (e.g. Featherlight) #189

mateoserendipia opened this issue Sep 28, 2015 · 13 comments

Comments

@mateoserendipia
Copy link

Hi,

I installed RICG Responsive Images yesterday in an attempt to reduce image load to smaller screens. It works fine, and I think it's a great and very necessary plugin! I also installed WP-featherlight, a good and light lightbox. I noticed (by inspecting in Chrome) that RICG Responsive Images works fine on the thumbnails with a lightbox selector, but the image that opens in the actual lightbox when clicking on the thumbnail is back to the original large size file. It means that far too large images are still being served to smaller screens, thereby loosing the advantage that brings RICG Responsive Images.

I'm not a developer (but not afraid of some coding either), and I haven't been able to find a way to get RICG Responsive Images to work on the HREF that the lightbox-thumbnails points to (I tried various lightboxes).

I submitted an issue to the maker of WP-Featherlight (cipherdevgroup/wp-featherlight#26 (comment)). He responded that it has to do with the way Wordpress handles images, that it was (probably) out of scope for WP-featherlight and that it might be worthing opening an issue here. So here it is ;-).

Thanks!

@tevko
Copy link
Member

tevko commented Sep 28, 2015

Hey @mateoserendipia thanks for the heads up. Can you provide a link with an example of the issue?

@brentlogan
Copy link

@tevko, I believe @mateoserendipia is referring to this situation:

<a href="http://really.big.pic" class="lightbox">
    <img src="http://thumbnail.of.really.big.pic">
</a>

No matter what you do to the <img> tag to match the image size to the layout and display size, the linked image gets pulled in at full size.

Any WordPress gallery that links to the image instead of the attachment page matches this pattern. Here's one of my posts following the pattern:

http://brentlogan.com/2015/09/cannon-beach-sunset-2/

@orionrush
Copy link

I was just doing some research on this behaviour last week and I discovered, as @brentlogan noted, that this is the default for WP when you select "link to file" when creating your gallery.

If you tend to have users who put up huge files, then indeed this would be an issue.

The Imsanity plugin helps deal with super large images by allowing you to set the max size an image can be (discarding the original after upload).

Imsanity is all well and good, but it wont make your light boxes images responsive, it just puts a cap on how nasty the light box full size image can be. In the light box I'm using, (fancybox) it's the same issue. Basically these js tools don't leverage any of the built in functions from the RICG plugin, and so are unaware of any of the other sizes. But more importantly they do their work on the fly,ie none of the light box markup is on the page when the RICG plugin does its magic. Vendors would have to write either platform specific versions of their plugin, or a common standard is established so that plugins could receive a standard array of avaliable image sizes and generate the srcset and related attributes themselves.

Interestingly there used to be a hack to add custom image sizes instead of the original image as the linked image in the gallery builder, but this doesn't work as of WP 3.5. While there isnt a filter avaliable to add our own image sizes (like 'large' instead of original file) to the target drop down list, there is a filter to add custom sizes to the thumbnail size drop down via: "image_size_names_choose".

This perhaps warrants some research and even a feature request to the core team on trac. It would seem trivial to add a filter to this option as well.

@joemcgill
Copy link
Member

I think this is worth looking into in order to find out if it's something in WP core that can be enhanced.

@mateoserendipia
Copy link
Author

Hi Tim,

Thanks for reacting. Brent and others in the meantime have also reacted and confirmed the issue. I can't show it to you on my own portfolio page (graphic designer) as i'm still building that - I don't want Google to see me in this state ;-). But I've set up a temporary example on another site (being built) for you that i'll leave up for a week or so.

It's here: http://decamerone.info/?page_id=509

The test is with RICS Responsive Images together with WP-Featherlight lightbox

On the page you'll see just one image which native size is 2000 x 2000px, placed using the WP media library (as the full image). I've inspected it in Chrome with and without both plugins activated, and made a screenshot of what Chrome showed. The inspection was for a screensize 1440 x 900px (much smaller than the native image)

1
This is with both plugins still INACTIVE.
As expected, that natural image here is 2000 x 2000px:

1 - plugins not active

2
Then with both plugins activated, but the lightbox still closed (so showing the same 'thumbnail').
The natural image is now the max width of the screen (1440px):

2 - plugins active

3
And this is when the lightbox is actually opened. The pulled image is back to 2000 x 2000px:

3 - lightbox opened

Hope this makes things clear, if they weren't already from Brents examples.

Cheer!
Thies

@jaspermdegroot
Copy link
Member

@mateoserendipia - Did you close this ticket by accident or intentionally?

@mateoserendipia
Copy link
Author

Hi,

I closed it intentionally, because there were no more reactions. I took off-line the mentioned example page, so wasn't sure if I should leave to topic open.
Should I leave it open?

On 20 Oct 2015, at 16:27, Jasper de Groot notifications@github.com wrote:

@mateoserendipia https://github.com/mateoserendipia - Did you close this ticket by accident or intentionally?


Reply to this email directly or view it on GitHub #189 (comment).

@jaspermdegroot
Copy link
Member

@marcoscaceres

Thanks for your reply. I'll reopen the ticket. I think we should still look into this to see if we can make improvements.

@jaspermdegroot
Copy link
Member

@marcoscaceres - Is this still an issue with WordPress 4.4 and/or current version of the Responsive Images plugin?

@marcoscaceres
Copy link

@jaspermdegroot, did you accidentally include me in this issue? Did you mean @mateoserendipia instead?

@mateoserendipia
Copy link
Author

Hi, I uninstalled the Responsive Images plugin and the Featherlight lightbox plugin at the time of this discussion, and have not gotten around to reinstall them and test the situation again now that Reponsive Images is incorporated in the Wordpress core (good thing btw). I'll try to do that somewhere this week, and report back.

Marcos, I think you were mistakenly included in this discussion - my nom-de-plume sounds a little Spanish as well, even though i'm plain Dutch ;-)

@jaspermdegroot
Copy link
Member

@marcoscaceres - Yeah, I included you by accident. Sorry about that!

@mateoserendipia - Thanks in advance for testing again!

@mateoserendipia
Copy link
Author

Hi Jasper,

Sorry, took me a bit longer to find the time to test this well.

I have tested the same situation as above (for an image of 2000x2000px, see my post of 29th of september). I recreated that page, and reloaded the image so that everything was up to date.

I'm afraid the issue hasn't been solved now that RICG Responsive Images has been integrated in the WordPress (which in itself is great!. The image that opens in the lightbox (I tested with WP-featherlight) still loads the original image (2000x2000px), even when the site is viewed on a mobile screen. So unfortunately there is no difference with the earlier situation.

Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants