Easyhdr wrong image dimensions full#
Easyhdr wrong image dimensions pro#
Easyhdr wrong image dimensions free#

All URLs on the front end are delivered to the browser over https but the website must run under http as no certificate exists on the local web server. This is due to how Cloudflare's Flex SSL works. My initial thoughts would be to somehow place a check to see if Cloudflare Flex SSL is being used (since it requires the Cloudflare plugin to also be installed and active to work properly), we can mitigate this problem.įor now a hard hack would be to add that str_replace above line 443 but this is a core hack atm. $url = str_replace('https', 'http', $url) īoth the front end and back end result in the expected resized image. If I add to line 442 for example, a simple snippet that rewrites https to http: When the back end is executed, the $url var does not contain https because Cloudflare does not rewrite ajax requests (even though the editor is indeed served over https) and thus returns truthy and passes one of the 'if' conditions resulting in a properly resized image url, but of course without being rewritten by Cloudflare having https, which is seen in my screen shots above, notice the resized back end image url is http. When the front end is executed, and the site is using Cloudflare's Flex SSL, the image $url var contains https and does not match the site url which is http (somewhere further down the rabbit's hole) and thus does not meet either of the 'if' conditions that follow, which when truthy returns the 'resized' image url path. The issue comes down to whether the url returns 'truthy' or not starting on line 443: and ultimately would up at an added library found in /elementor/includes/libraries/bfi-thumb/bfi-thumb.php

So I followed the rabbit down the hole a bit and found.the render function and then.

Easyhdr wrong image dimensions free#

I responded to the ticket about 17hrs ago, hopefully they find a way to work around this.may even dig into it a bit myself if I get some free time.

Easyhdr wrong image dimensions full#

I have tons of my clients that use Cloudflare free SSL and asking them all to go purchase Full SSL certs is not something I want to head up at the moment. Hopefully it's a quick fix to check for https or Cloudflare plugin to render the correct url. However I did test this on an http only site without Cloudflare active and I did get it to work on the front end so we may have found the bug.

The problem is not http vs https directly, even though that likely plays a role in how a filter is configured maybe (regex for ex), one can clearly see the file paths and image names are completely different. All urls on the front end are delivered to the browser over https but the website must run under http as no certificate exists on the local web server.

Again no other plugins except Elementor so no caching via WP, no caching at the host and always cleared cache with hard reload in the browser.beside even with cache it will eventually update, this never changes.

Verified no cache using new browser at a new machine.

Re-enabled plugins - disabled both Elementor plugins and reenabled.Switched my theme back to OceanWP - switched between Hello and 2017 and back.Switched my theme to the 2017 Wordpress default - using Elementor's Hello theme unmodified (tried 2017 as well).

Easyhdr wrong image dimensions pro#

Disabled all plugins except Elementor - only Elementor and Elementor Pro active (ever).

If this feature were fixed it would save me countless hours of time. I have since chosen not to rely on this feature and duplicate my images and upload the sizes I need. This results in the same kb/mb file size as the original directly affecting page load. I've tested this in many hosting environments and always the same result and never has worked for me.ever. The images on the front end when checked in the inspector are indeed the full images and NOT the resized images (see image url and dimension info): You can see I am choosing a custom size and in the preview, it is indeed a completely different file and url of that file being used. Did you actually inspect the image loaded on the front end and verify it was NOT the original file and not just resized with css rules or the container itself?įor example, here is a fresh installed WordPress site. Thanks for the suggestions but in the case with ALL of my sites historically this has never worked and I'm not entirely convinced it's fixed for you either.