Doesn't work with CDN / W3 Total Cache

I’m glad you did some debugging as I heard of this issue before, but not using a CDN myself I couldn’t really test anything.

First, it’s an excellent news to hear that the @2x files are mirrored on the CDN. I was actually really worried about that.

The “file swapping process” is made by a script called retina.js. WP Retina 2x uses this plugin for the client method. And it seems I found the issue: https://github.com/imulus/retinajs/issues/40

Basically the script and the images are loaded from different domain… and for security reason, the browser wouldn’t allow the script to query anything from a different domain. I have no idea how we could resolve that issue right now, and maybe you could add a message to that forum there.

You can also try the very last version of the retina.js (replace the plugin’s one with the latest one) but I doubt the issue is resolved at the moment…

I’m testing this as well, demo page here: https://photokaz.com/2013/04/testing-wp-retina-2x-plugin/

W3 Total Cache allows you to specify your hostnames but it looks like the first one is limited to CSS only so I’m not sure if you remove them all it will still serve images from the CDN.

After contacting the nice support people at MaxCDN, I got an answer that fixed my problem. It seems that you need to turn on Cross Origin Scripting in order for retina.js to load images from a different url (e.g. cdn.yoursite.com).

Add the following code to your .htaccess file and you should be good to go:

# ———————————————————————-
# CORS-enabled images (@crossorigin)
# ———————————————————————-
# Send CORS headers if browsers request them; enabled by default for images.
# developer.mozilla.org/en/CORS_Enabled_Image
# blog.chromium.org/2011/07/using-cross-domain-images-in-webgl-and.html
# hacks.mozilla.org/2011/11/using-cors-to-load-webgl-textures-from-cross-domain-images/
# wiki.mozilla.org/Security/Reviews/crossoriginAttribute
<IfModule mod_setenvif.c>
<IfModule mod_headers.c>
# mod_headers, y u no match by Content-Type?!
<FilesMatch “\.(gif|png|jpe?g|svg|svgz|ico|webp)$”>
SetEnvIf Origin “:” IS_CORS
Header set Access-Control-Allow-Origin “*” env=IS_CORS
</FilesMatch>
</IfModule>
</IfModule>

Anyone any idea how to do this on Nginx?

Oh further to this -my W3 doesn’t appear to be uploading the @2x to S3 @jaapstronks is your CDN pull or push?

Yeah I can get W3 to upload the images to S3 if I include the upload folder where the @2x files exist, however it doesn’t’ happen automatically – only the wordpress thumbnails are uploaded automatically.

Jordy for uniform working across all instances wouldn’t it make sense for the plugin to create the @2x files as additional thumbnails so they go into the WordPress attachments media gallery properly and then are handled by all other plugins universally? Eg they can be deleted when the other attached images are deleted, in my case they would be uploaded the S3 by the W3 plugin (and any other S3 plugin) etc automatically. Currently nothing but your own plugin knows these extra files are there which means a nightmare for anything outside of basic use…

I thought about it many times at the beginning but realized that those images should be shadow/ghost images. They can be deleted, re-generated, temporary available, they are not mandatory and they are not really part of the system. If I register them in the WP system, then I will get a lot of new issues and problems, they will appear everywhere and the users will wonder what to do with them (when inserting an image in the post of example). Thing is they shouldn’t appear anywhere.

I agree though that it would be nice if the S3 plugins could see them. I talked to another guy before and implemented “actions” on my plugin so that they would be aware of the retina images. They can also check for the @2x files.

I am not sure what is the best way, but integrating the @2x files in the WP system would do damage for sure… Please feel free to modify the code and to add that, but I think it will end-up being a pain…

Hi Jordy,

I know what you mean – although its pretty similar to the way my theme creates the different thumbnails it specifies now, which isn’t too confusing. I was the one trying to put you and the S3 plugin maker together, unfortunately he never finished his end of it ??

I knew we were using W3 caching when we launching the site so I gave up asking him and turned that on to find it does the same thing – although for me, unlikely the OP it doesn’t send the @2x images as it doesn’t see them as attachments.

How hard would it be to change this behaviour Jordy, maybe it could be a good option to turn on and off? Or if you don’t want to supply that feature could you give me an example of how we could modify it to work for us as it’ll be all automatic on user uploaded photos for us, so makes sense for us to switch it on and leave it.

Im struggling with the CORS setup too, but no point in tackling that until I know that the @2x images will be uploaded as part of the attachments automatically.

Jordy, Ive found that W3 will upload custom files automatically – it doesn’t’ do it instantly like when you put an image in the image gallery but you can tell it to upload files in a custom folder every X amount of minutes, so soon after it’ll do the retina image.

Great!

Now I’m left with one minor problem which I think you could fix easily. I don’t want all the image residing on our individual server instances once they are uploaded to W3 as it wastes space. So a cron job will delete the files every couple of days. W3 leaves the files on the CDN however – it appears that your plugin is looking for the file in its original place and then W3 rewrites the URL on the fly afterwards to the URL – however it doesn’t see the file anymore and thus doesn’t load up the @2x.

A simple fix for this might be a check box (or a way for me to hack the plugin) so it doesn’t check to see if the file still exists? Or a way to change the location it looks for the @2x files, or a way to change the URL so I can upload it to our https://cdn.url.com instead of https://url.com

See what you suggest, I’m sure there could be a simple work around even if you just have me hack the plugin somewhere.

Here’s my suggestion Jordy – obviously you can’t ignore if @2x files exist because thats fundamentally how the plugin works to see if they are created or not and looking for them on the CDN via URLs might be technically impossible (and inefficient?)

How about this then, if the image has been created by the plugin ALWAYS assume the image is still there? That way its not assuming all @2x images exist just the ones it knows its created in the past – that must be reasonably easily to implement and would be a perfect work around for this situation.