Note – the sidebar gravatar is being generated via:
<?php echo esc_url( get_avatar_url('will@willstocks.co.uk', array('width'=>'160', 'height'=>'160'))); ?> – slightly different to everywhere else on my site I believe. I’m still unsure as to why OGC hasn’t pulled the right gravatar image for single posts though?
RE: the first part of the issue:
Homepage: https://cdn.willstocks.com/wp-content/uploads/optimum-gravatar-cache/avatar/2.jpg?d=thb95k – this shows the incorrect gravatar (old one)
But: https://cdn.willstocks.com/wp-content/uploads/optimum-gravatar-cache/avatar/2.jpg – this shows the CORRECT one (new one). It looks like the date param throwing it off for some reason?
Hello Will,
I see the same picture everywhere.
You can post the whole image tag <img />
-
This reply was modified 5 years, 2 months ago by
José Miguel.
I removed get_avatar_url from the plugin I no longer know in which version. Because, it made the gravatars evaluated by the plugin several times.
I also do not understand why not just use get_avatar when we want an image with HTML. And just use get_avatar_url when we want a url to use in javascript for example.
Either way the sidebar gravatar is not local is from gravatar.com.
I will add get_avatar_url again in the plugin!
Just out of curiosity, what’s the point of using 160×160 images and then resizing them in CSS? Is there an advantage?
Single posts are showing the old image, true.
Are the images 2.jpg, 3.jpg, 4jpg in the cache the same?
The only reason I pull the 200×200 is for retina reasons. In theory, if the image is a 100×100 square, pulling the 200×200 image should satisfy retina?
2.jpg, 3.jpg and 4.jpg are all the same image – just various sizes. It looks like 2.jpg has updated overnight now and I’m seeing the same image everywhere except single posts (which is 3.jpg). I’ve even cleared page caches 🙁
RE: Sidebar avatar – that makes sense. The only reason I use get_avatar_url is due to the way that the widget is built. I’d have to replace a load of stuff with get_avatar and then patch a load of other bits and pieces in afterwards – then when my theme updates (which usually brings plugin updates with it), I would have to rework all of that. get_avatar_url was just the easier option!
Hi @jomisica
I’m adding the following to my install:
case 'w3-total-cache':
foreach ($postsIDsToClear as $postIDToClear) {
w3tc_flush_post((int)$postIDToClear);
}
break;
and
if (defined('W3TC')) {
$this->cachePagePlugins='w3-total-cache';
return;
}
That way, I can ensure OGC clears the relevant page caches for the posts affected (as I have a feeling this is some sort of weird caching thing).
Happy to PR this into your repo if you’ve GitHub’ed OGC (assuming a private repo?)
Hello @willstockstech,
As for the sizes you use in the images I already realized, it is to simulate the srcset for retina.
The modifications you made to support the “w3-total-cache” if it works seems to me good.
However I think the problem is in the CDN.
Cache image:
https://willstocks.co.uk/wp-content/uploads/optimum-gravatar-cache/avatar/3.jpg?d=thb95k
Image on CDN:
https://cdn.willstocks.com/wp-content/uploads/optimum-gravatar-cache/avatar/3.jpg?d=thb95k
There seems to be some sync problem.
@jomisica – I will let you know how those little PHP bits work for me 🙂
My CDN is Cloudfront (AWS S3 with a Cloudfront distribution), so I think what I might need to do as part of the W3TC page cache purge is also invalidate the files in Cloudfront – I just have to work out how:
https://plugins.svn.wordpress.org/w3-total-cache/trunk/CdnEngine_S3_Cf.php (line 162 – function invalidate( $files, &$results )) – it looks like instead I might need to grab the “changed file path” and pass that instead of the postid (should be fairly simple as I think I’ve seen a function that you use already?
Hello @willstockstech,
You need to clear the posts and also invalidate the gravatar on the CDN. Both are necessary.
In the afternoon I put here the code to deal with get_avatar_url.
In the future I intend to support w3tc.
However I’m too busy rewriting the entire plugin to split it into multiple files, to give a simple way to add cache plugin / optimization etc. A lot of work and little time. I will not be able to support w3tc now.
Hello @willstockstech,
I have released version 1.4.3 that already supports “get_avatar_url”.
Your profile image in your sidebar will already be resolved from the cache.
As you know that the plugin does not support W3TC and the problem presented is due to something unsupported, this topic is resolved. Right?
Open a new Non-support topic and submit your request to add support for the W3TC.
I will stop the development of version 2 and support W3TC in version 1.4.4.
Describe your system environment!
Nice one – thanks @jomisica. Let me know if you need any translations as well and I can assist with those.
@jomisica – I can confirm that 1.4.3 + 1.4.4 is now capturing the sidebar gravatar and serving locally! 🙂
