Will Stocks
Forum Replies Created
-
Forum: Plugins
In reply to: [Optimum Gravatar Cache] W3TC supportWP-Cron but via https://cron-job.org/ (at the moment, on a every 2 minute schedule
Linux cron wouldn’t work for me for some reason a the command just wouldn’t execute, or if it did it would only partially complete and then things would just queue
Forum: Plugins
In reply to: [Optimum Gravatar Cache] W3TC supportI will check – in theory they should have as W3TC does it regularly via cron.
https://willstocks.co.uk/wp-content/uploads/optimum-gravatar-cache/avatar/7.jpg?d=timxem
vs
https://cdn.willstocks.com/wp-content/uploads/optimum-gravatar-cache/avatar/7.jpg?d=timxem
Server appears to have new, CDN has old 🙁
I think it’s best I remove the CDN for the time being?
Forum: Plugins
In reply to: [Optimum Gravatar Cache] W3TC supportHey @jomisica – how weird, when I checked on my desktop earlier, it was all good! Then again, I cleared browser cache to check.
When I check on mobile _none_ of them have changed!
When I check on another laptop, only my homepage has changed (in post is still old).
I think, what I’m going to do, is take Cloudfront out of the equation and serve the Gravatars from my server. That way I’m not adding Cloudfront caching to the mix.
Yes, I have that option enabled in W3TC, however I wonder whether that only fires on new content being published? Maybe it’s not part of the “page cache clear” process?
Let me remove my CDN from the mix and get back to you?
Forum: Plugins
In reply to: [Optimum Gravatar Cache] W3TC supportLooks like it has worked! I updated my Gravatar last night, have just checked my site now and can see that my latest Gravatar is showing on my site (I haven’t logged in or manually cleared my cache at all!)
That’s great, thank you @jomisica 😀
Forum: Plugins
In reply to: [Optimum Gravatar Cache] W3TC supporthi @jomisica – I have just updated my Gravatar now, so I’m going to see how things are tomorrow in terms of “auto cache clearing” 🙂
Forum: Plugins
In reply to: [Amazon Associates Link Builder] v1.9.0 issues@amazonlinkbuilder – are you able to advise any ETA at all? There are quite a few users that appear to be at a loss/have throttled accounts/are getting locked out.
What do we do? Do we roll back to a previous version? Is there a new version close to release that fixes all of the issues people are seeing?
Forum: Plugins
In reply to: [Optimum Gravatar Cache] 2x?I wouldn’t mind this as well @jomisica – I noticed that sometimes on iPad’s (mainly) Gravatars can look a bit blurry.
I was going to try and add a srcset manually and just look for the
imagesize * 2but couldn’t find a “reliable” way to do this! In my case, when I manually check all Gravatars, they all have the equivalent higher resolution (2x) version – maybe it could be a “user option” for “Enable 2x” with a “NOTE: This is not guaranteed to work for all Gravatars”?Sorry forgot [x] resolved!
Ahhhhh – I think I’m with you now!
Converting sounds like my best bet, but compatibility mode should pick up everything else that I miss! 🙂
Brilliant – thanks for the info @andi-dittrich! And loving Enlighter so far!
Ahhhh – ok I will have a play to see what’s what. Fortunately I don’t have too many posts with code content – but I’m 99% sure that they’re all tag-in-tag (I think that’s Gutenblock standard? See link below – unless I’m mistaken?) so manual conversion isn’t a MASSIVE task for my use case.
See: https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/code/index.js
return <pre><code>{ attributes.content }</code></pre>;Is this something you might cater for in a future release? Tag-in-tag/nested elements?
Ahhhh, ok – so am I right in saying that Enlighter is *forwards* compatible as long as I use Enlighter blocks, but is not backwards compatible with existing code blocks?
E.g. If I didn’t use Crayon, and only used
<pre><code></code></pre>HTML (or in recent months – Gutenberg code blocks) – how would Enlighter treat those? Would it just “generic style” them because there’s no language attribute if I have set to pre and code as the selectors?The PHP article I linked to was created using standard Gutenberg code blocks (because Crayon isn’t Gutenberg compatible) and things seem to nightlight if I change the Enlighter config to pre and code blocks to apply CSS – I don’t know what the knock on effects of that would be though?
I think I worked out the second bit – it’s looking for pre and code where enlighten creates them, not just all pre and code. I can sort that bit in a little while 🙂 the first bit still stands though –
<code>still shows as the start and end of the contentNote – that link might not work, I enabled the beta “only load assets when needed” and it looks like it may have just not loaded the assets at all as code blocks are unstyled 🙁
Forum: Fixing WordPress
In reply to: WordPress Front Controller – Redirecting partial URLsCorrrrr, that was quick @sterndata!!! Haha
That’s amazing, thank you so much! I was clearly Googling the wrong thing (I was searching for rewrite/redirect rather than “guessing”).
I might investigate to see if there’s a way to instead forward those requests over to search instead of just flat-out 404’ing them… then again, 404 is actually probably the correct response to issue!
Thanks @sterndata! 😀
Forum: Plugins
In reply to: [W3 Total Cache] Brotli@damianvincent and @damianvincent – I found that it only enabled for me when *both* the PHP extension *and* the Apache module were enabled.
Having just the Apache module enabled didn’t enable the box for me. I’m not sure how I’d feel about Apache doing on-the-fly Brotli compression either to be honest… Brotli is fairly intense in terms of CPU usage and compression times when compared to GZIP.
You also have no control over the level of Brotli compression within W3TC (something @vmarko might be able to confirm if is coming in the future)?
I’d also like to see an option within W3TC where I can actually _store_ the Brotli version of files (such as
page_cache.html, minified files etc.) so that I can use nginx’s brotli_static to serve the pre-compressed files, without having to do on-the-fly compression (I’m sure similar can be acheived in Apache as well) – it would save a _massive_ amount of overhead!!!
