OK, so;
* what happens if you try to request the cached image directly? a 50x error?
* what HTTP response headers do you see if you request the image with &reportErr=1 (thise forces lyteThumbs to output debug-logging in the HTTP headers)?
* do you see any errors in the PHP errorlog?
cloudflare is denying me access to the lyteThumbs url;
also had a look at the page URL provided but thumbnails still point to youtube directly?
I removed the Cloudflare block.
but thumbnails still point to youtube directly?
Not sure what you mean. I see the video like this: http://i.imgur.com/VXY9CMk.png
Is thumbnail showing for you correctly?
can you clear your cloudflare cache? the image don’t work on the page, but when adding a random key/value to the querystring it does work?
I’ve cleared it alongside with Varnish and Hummingbird cache, but it doesn’t work for me. I don’t see the link to the original image in the HTML markup also: https://drive.google.com/open?id=1ZVlef4KwEQP0u2ZVCs-9jiNarczKRj0d
re. link to orig. image; that is in the origThumb parameter in the querystring.
but the fact that the normal URL results in the grey fallback image but that adding a random key/value to the QS fixes that is very weird. I even tried with a video you probably don’t have on your site and got the same result, so it indeed is not a caching issue;
https://www.mein-adventskalender.de/wp-content/plugins/wp-youtube-lyte/lyteThumbs.php?origThumbUrl=https%3A%2F%2Fi.ytimg.com%2Fvi%2F7AQSLozK7aA%2Fhqdefault.jpg -> does not work
https://www.mein-adventskalender.de/wp-content/plugins/wp-youtube-lyte/lyteThumbs.php?origThumbUrl=https%3A%2F%2Fi.ytimg.com%2Fvi%2F7AQSLozK7aA%2Fhqdefault.jpg&randomness=galore -> works
The problem is that due to that “fix” I can’t see the debugging info which I put the HTTP response header so we’re still flying blind.
For next steps I see 2 options;
* A workaround where we use LYTE’s API to add a random-ish string to the thumbnail URL
* OR we add extra debugging logic to have lyteThumbs log to your php-errorlog and try to find out what is happening that way?
frank
The strange thing is that if I add the random URL param at the beginning of the URL (as a first param), the link doesn’t work again. But can confirm it works with the param appended to the URL at the end. This leads me to think that maybe it’s connected to the string parsing logic?
that’s bizarre, even just adding & works … but on a code level I’m simply doing
if ( array_key_exists("origThumbUrl", $_GET) && $_GET["origThumbUrl"] !== "" ) {
$origThumbURL = urldecode($_GET["origThumbUrl"]);
} else {
// faulty request, force a grey background
$origThumbURL = "https://i.ytimg.com/vi/thisisnotavalidvid/hqdefault.jpg";
}
that _should_ just work (and does on a lot of other sites) … maybe add
error_log( 'origThumbUrl not found in ' . json_encode( $_GET ) );
in the else block and check your PHP errorlog what is logged? I’m somehow suspecting something is tinkering with the URL in transit ..
I wasn’t successful in loggin any errors. I can’t find anything in the apache errors log or PHP error log. The thumbnails worked correctly on Sireground on the staging website, but the live website is hosted by Cloudways. They use Ngnix to serve static files and Apache to serve dynamic content with Varnish in between. Can we log anything to the Query Monitor plugin? Maybe the error logs on the server don’t work correctly.
well, query monitor _should_ display PHP-errors as well, so if you error_log() that should show up in QM. if you find nothing in the php-error-log or in QM then that implies that for reasons unknown the request simply isn’t reaching your server, instead -incorrectly- being served from cache (nginx/varnish)?
maybe give this code snippet a try as a workaround?
add_filter('lyte_match_thumburl','lyte_thumbnail_fixer');
function lyte_thumbnail_fixer( $thumb ) {
return $thumb . '&fix=it';
}
@optimizingmatters , you’re right. No errors are logged or tracked with QM. The filter fixed the issue for me. I do suspect that that’s most probably connected to the Cloudways files serving. Thanks!
well, happy we got it working, even if only with a workaround 🙂
