Some PNGs give me a White Screen of Death

  • Resolved Alexis Wilke

    (@alexiswilke)


    6 years, 12 months ago

    Your plugin does a curl_init() with that URL:

    https://stargazerrock.com/wp-content/uploads/2017/11/telescope-lassel-picture-published-in-la-nature-1873-262×300.png

    and loads the first 32Kb of the file (partial load, I can see the 206 return code in my logs).

    Then your plugin fails silently in some way and breaks the whole processing. Needless to say, not what you’d expect.

    For now, I have a “temporary” fix which is to skip on the partial download. that works just fine. Slower, but much better than a WSOD. Now what I don’t understand is why you wouldn’t just check the local file, but anyway… that’s probably a different problem.

    $headers = null;
//array(
//      "Range: bytes=0-32768"
//);

    This goes in:

    wp-content/plugins/wonderm00ns-simple-facebook-open-graph-tags/public/class-webdados-fb-open-graph-public.php

    at line 885 in version 2.1.5 of Wonderm00ns simple Facebook Open Graph.

    I am thinking that the load of the PNG works but then you try to get the width and height and that fails because that info was not loaded (i.e. found at the end of the file, probably.) So your loading process is not currently correct. That being said, the width/height gathering should be failsafe too.

    I’m on Ubuntu 16.04 with the latest of everything. No special version of PHP/Apache/MySQL.

    The page I need help with: [log in to see the link]

Viewing 14 replies - 1 through 14 (of 14 total)

  • Probably also related to https://www.ads-software.com/support/topic/html-truncated/page/2/#post-9779287

    Does
    wp plugin install https://downloads.www.ads-software.com/plugin/wonderm00ns-simple-facebook-open-graph-tags.2.1.4.4.zip –force
    solve it for you as well?

    You’re however absolutely correct in stating that errors should be handled correctly. I just want to find evidence of others also having problems with the “fix” regarding this issue in 2.1.4.5 !

    Thread Starter Alexis Wilke

    (@alexiswilke)

    Indeed, that other bug report sounds 100% like a duplicate although you mentioned having to use a CURLOPT_FOLLOWLOCATION. I suppose that guy had a 301 or 302. That’s not my problem. In my case the image is “faulty” as far as your code is concerned.

    I tested with 2.1.4.4 and I get the exact same problem.

    Have you been able to reproduce the issue with my image? Because most of the time things work for me, it’s only some images that fail.

    My “fix” is really just a temporary patch so my site functions until you get us a proper fix. If you can detect that the width/height info cannot be gathered, then you could do another GET loading the rest of the file starting at 32Kb, for example… Concatenate with the first 32Kb and then attempt the imageinfo() call again.

    First off, I’m just a user, not a dev ??

    We also see it with only some specific pngs, but we did have a switch from HTTP to HTTPS a year ago, so there may be lingering redirection problems from that time.

    If 2.1.4.4 does not solve it for you it seems these are two issues and some of the cases (like mine) seem to be a combination of both (redirection and “special” images).

    I think this could be related to minimized pngs. We often use tinypng.com for minimizing pngs. Maybe that process somehow manipulates the header in a way not expected by this plugin. Or pngs get created with inkscape.

    Thanks for your feedback. I’m trying to help gather evidence so the dev can fix it. Hope this helps!

    Thread Starter Alexis Wilke

    (@alexiswilke)

    Maybe you could try the latest with my fix above. It should be easy enough for you to edit the file and apply my fix. Then report whether that fixes your problems. At least the one with your PNGs.

    On my end, my website was on HTTPS immediately so I’m sure it’s not a redirection. Also, once my fix is in place, it works and I know my fix has nothing to do with a redirection.

    @alexiswilke Enabling the “Do not get image size” option doesn’t fix it?

    Thread Starter Alexis Wilke

    (@alexiswilke)

    @webdados Ha. Yeah. That works. ??

    Now before I realized that it was (1) your plugin and (2) in link with the size retrieval, I had to test many other things. (Because of the lack of errors anywhere, on screen, in the logs… zilch!) and you know how it goes once you’re in the code, you look for some form of a solution in the code!

    Anyway, that works and also the “Include Image Dimensions: [ ]” is checked by default, by removing that it also resolves the issue.

    Now, you also cache the info so it would make it double trouble to find the bug, I think. But since the cache is going to make things super fast anyway, not having the range would probably be just fine. (i.e. you’ll read the image ONCE probably just after I saved my page the first time, so ZERO impact on my users anyway.)

    What do you think?

    You could also add another flag, but I really don’t see a reason for it now that you have the transient caching in place.

    Hi there @alexiswilke and thanks for your comments.

    Please try this version: https://cld.pt/dl/download/dab038ce-feec-4917-969d-78d146d9a758/wonderm00ns-simple-facebook-open-graph-tags.zip

    For testing, you can disable the transient cache with this:
    add_filter( 'fb_og_image_size_cache', '__return_false' );

    You can disable the partial range when getting the image size with this:
    add_filter( 'fb_og_image_size_use_partial', '__return_false' );

    Disabling the partial range solves the issue for you?

    There’s also a new panel on the settings page called “Tools” where you can Clear all our transients.

    Thread Starter Alexis Wilke

    (@alexiswilke)

    Yes. Commenting out the range loads the entire file and that works.

    Have you tried to download my image and test with it to see whether you could reproduce the problem on your website(s)? It should fail on your websites just like it fails on mine.

    I just commented out the corresponding parts of the code (as shown above for the range) which would be pretty much the same as what you are proposing to do with these add_filter() calls.

    Have you tried to download my image and test with it to see whether you could reproduce the problem on your website(s)? It should fail on your websites just like it fails on mine.

    I did and it doesn’t fail. I’ve done that in the past with several images from people having the same problem, and in several server environments and still haven’t been able to reproduce the problem. I’ve tried by copying your image to my server and also by reading it directly from yours.

    Thread Starter Alexis Wilke

    (@alexiswilke)

    Darn, it looks like the image link I put in my first post is the reduced thumbnail, which is small enough to fit and thus does not fail. There is the correct, full image.

    https://stargazerrock.com/wp-content/uploads/2017/11/telescope-lassel-picture-published-in-la-nature-1873.png

    For now people can turn on the flag as you mentioned (Do not get image size).

    However, that means they lose the size instead of turning off the 32Kb optimization. It would be better to turn off the 32Kb optimization since that way we don’t lose the sizes.

    Just tested it with your full image, getting the partial size (32Kb) with no problem whatsoever.

    I’m a bit reluctant to turn off this optimization for everybody, so that’s why I implemented the filter on the beta version I sent you so that people with the WSOD problem could solve it with the filter.

    I must think about this further.

    Thread Starter Alexis Wilke

    (@alexiswilke)

    Okay, the latest version does not attempt to load just 32Kb of the image which means that the width and height will be included every time and no WSOD.

    So 2.2 fixes this problem once and for all.

    You still have the option to read just 32Kb of your images if that works on your site so you benefit from that optimization. Along with the cache, it works smoothly, really.

    You still have the option to read just 32Kb of your images if that works on your site so you benefit from that optimization.

    This can be achieved by returning false to the fb_og_image_size_use_partial filter.

    I can confirm I don’t have to check “Do not get image size” anymore with 2.2. It just works?. Thanks!

Viewing 14 replies - 1 through 14 (of 14 total)
  • The topic ‘Some PNGs give me a White Screen of Death’ is closed to new replies.