Hello,
It’s an known bug. Actually it was working well in the previous version but now I need to handle users using customized uploads folder (which are a big mess). I am on it soon 🙂
Hi Jordy,
Any progress on this?
Would much prefer having it fixed than creating a work-around for long term maintainability of websites.
Best,
Viktor (using pro version)
PS. Server setup is working way better than the other methods in our setup (for performance and client compatibility).
Hello Meffe,
That is not working yet? I made changes that should have fixed this issue. Or so I thought… really, did you try?
What is your work around? I think we should close this thread and maybe open a new one with more details. What is the src you have originally and what src you expect to get for the visitor.
Hello, thanks for your prompt response!
Ok, I did not try the last two updates but they did not mention this in the changelog?
I tried version 3.4.2. I can try the last version tonight if you have fixed it in 3.4.4 or 3.4.6.
My workaround is to add a RewriteCond before the RewriteRule that routes to the php file,
which checks that REQUEST_PATH starts with my upload-dir. This however, won’t let me have retina versions of theme graphics. Without this, no images outside my UL dir can be found.
A problem with this workaround is that it is overwritten if I keep it in .htaccess and not in the apache config.
Yeah the fix is quite recent but it’s not specifically about themes, it’s about everything which is outside the uploads folder which is why.
Let me know if it works better with those latests versions. Otherwise I will look into it again.
Hi, tried with 3.4.8 now, no change.
Images outside won’t load at all (also non-retina images on non-retina devices).
OT: By the way, I have a suggestion for the changelog: put release dates there together with version numbers.
OT: By the way, I have a suggestion for the changelog: put release dates there together with version numbers.
That’s a good idea! Any plugin is doing that already?
Images outside won’t load at all (also non-retina images on non-retina devices).
Non retina-images as well? So it means that the retina image is physically found, otherwise the plugin wouldn’t update the HTML. But the resolved URL for this new image is wrong, somehow. I try to replicate on my side but it works.
Can you help me and provide me some debug? In the setting of the plugin, there is “Debug Mode”. Turn this on. Clear you cache (if you use any caching plugins) and reload the page where the issues happen. What do you see in the logs? You will see exactly what the plugin tries do to and the HTML before/after. That will be super helpful we would know exactly what it does.
Yes, for instance jetpack has dates in changelog. Somehow there ought to be a field for that in the “system” and not up to you, but anyway 🙂
I thought server-side mode won’t ever change HTML? Just serve @2x under the regular (without @2x) name if the devicePixelRatio is high.
The problem is in wr2x_image.php. Images in my upload dir works both with and without available 2x versions of images, and on both retina and non-retina devices. Images outside never loads at all (404): the php script does not return image data.
What I expect is that it just checks if there is a @2x file and dpr is high, and then send that file instead. If there is no @2x it should send the normal file. I could easily do the check for @2x with a rewritecond. But I like how the cookies and resolution detection is handled in the PHP script.
I wanted to just do the rewrite using mod_rewrite at first, and only use wp-retina-2x for generation, but I had issues with caching because the name is identical. Maybe I could use the original retina-images.php. The only close-to-plug-and-play method for me was server-side (for reasons of performance and browser compatibility).
I never manged to get anything logged in the logfile (even gave it permissions 777).
Apart from that, I don’t think that “no retina for mobile” works with server side?
Yes, for instance jetpack has dates in changelog. Somehow there ought to be a field for that in the “system” and not up to you, but anyway 🙂
There is a way to find when those commits were done but it’s not shown in the changelog directly. But it could be a good information to give when there is a new version.
I thought server-side mode won’t ever change HTML? Just serve @2x under the regular (without @2x) name if the devicePixelRatio is high.
Oh, you are using the Server-Side mode!? Then yes, the HTML never changes. And I don’t do any log on this part. This is actually an external solution provided by Retina-Images. It is this project on GitHub:
https://github.com/Retina-Images/Retina-Images.
Would you mind contacting Jeremy there? He might have a solution for you already. I have to tell you the truth, I didn’t use this method for a long while but I know some people use it with my plugin. You can just add a post in the Issues on that GitHub and point to that thread too.
Apart from that, I don’t think that “no retina for mobile” works with server side?
I should hide this option 🙂 It almost doesn’t work for anything. Since everybody is using caching, it’s impossible to make this option to work in most cases.
