Jon Scaife

Hi

I had this exact issue – I was unable to carry out any updates using wp-cli when APCu was enabled with the “Object Cache” enabled. Disabling the object cache (or deactivating the plugin) immediately fixed the issue, but enabling it again reintroduced the issue.

I found that APCu was not enabled on the command line in php.ini

I’m on AlmaLinux 9, so I had to edit the file /etc/php.d/40-apcu.ini and uncomment and change the setting apc.enable_cli = 1

Now wp-cli works again even with APCu Manager activated and “Object Cache” enabled.

I’m not sure of any other implications of this change as the setting is marked as being mostly for debugging and testing so perhaps this “fix” is more of a workaround and perhaps wp-cli should theoretically still work even with this setting off, but for now this seems a good fix if anyone else runs into this issue.

Maybe this information will help identify an issue somewhere else. Or perhaps it just is the best way to fix it. Either way it will do for now for me.

Amazing support as always, that did the trick straight away. Thanks!

Thanks Hector, that’s done the trick.

to clarify – for anyone else finding this thread… (1) I used the code from the thread you linked and pasted it into my functions.php. (2) I changed post-thumbnail to the name of my custom-thumbnail size created by my theme. (3) And then I edited my shortcode to include the post_html=” section and in there I used {stock_thumb} instead of {thumb}

Perfect. Thank you for the really swift response.

Hi Hector

The version from GitHub works fantastically. With it my site is faster AND I can use a strict CSP. It still seems to function fully as before. Thank you very much. I hope these changes make it into the next full release. ??

Hi Hector, that’s great, yes, I will give them a test, thanks!

Hi Hector

that’s brilliant news. Thanks for the update. I completely understand the work + life thing, I’ve been too busy to look at it myself so just grateful you’ve got as far as you have. I look forward to another update when time permits.
Cheers

Hi Hector
That’s fantastic. I really appreciate you looking at this. Perhaps a way around the concern about wordpress changes would be to have code for both ways of doing things in the plugin, and to have an option – which defaults to the current method, but allows a site operator to use the JSON method if they want. Could even be a filter rather than a GUI option to discourage casual users from potentially breaking things. The default would then always work, but users would have the option to tinker if they wanted.
Anyway, whatever you decide I appreciate your efforts and thoughts on this.

Hi Hector

Thanks for providing more information on this. I think I should split my reply into 2 parts…

1. The JS in the header – this seems to be just variables, which are presumably read and used by the JS loaded elsewhere (be that in a file or inline in the footer). Couldn’t those variables be specific as JSON variables – still inline but just not in a javascript tag – as described here -> https://itnext.io/inline-data-with-a-content-security-policy-ab30dde2feb3

2. The JS in the footer – presumably this could just be moved into a JS file and loaded from that instead of being inlined? Doing so would be much better for SEO and page loading speed – an extra external file is always preferable to inline script because the file can be cached and so is only loaded once, whereas inline script has to be transfered with every different page loaded. The file wouldn’t have to be loaded on every page load – once it is cached by the browser it would be there and available. Unless I’m mistaken it looks like the bit of code that varies is the part in the header, not the part in the footer? If that is the case then users obsessed with good pagespeed insight / GTMetrix scores would much prefer it be in an external file than it be inlined, especially if the external file is properly queued using the wordpress script enqueue system. Enqueued external JS files can easily be concatenated and served as a single JS file for the site which is only loaded once and can even be pushed with HTTP2. None of these sorts of optimisations are easily available with inline JS.

I assume the JS somehow pings the server to tell it there has been a visit, and what page the visit was to? Surely it can still do that without being loaded from the server each time?

Whilst I absolutely agree finding the balance between performance, reliability and security isn’t easy, I think in this instance both of my suggestions would improve security and performance with no downsides. I appreciate that they are not a priority though so I will investigate implementing them myself. If I am able to do so successfully would you be interested in implementing them in an official release?

Hi Andy
Thank you for the superb and speedy update. The tweak you provided works spot on with the latest version. I’ve added my own css to my child theme stylesheet and so no longer have any inline CSS which is fantastic (both for SEO and for Content Security Policy). Thanks again!

Hi Hector

Thanks for replying so swiftly. The less the better, so this is a great start. Would it be possible to update the plugin to make this change? – I imagine if I adjust my local copy myself it myself it will just get over-written at the next update?

With regard to the short piece of javascript in the header – it looks like this just sets some variables. Would it not be possible to do this as JSON data that is then parsed by the javascript in the .js file? That would then avoid any inline javascripts – which is useful with the growing prevalence of “content security policy”.

Cheers

Hiya Héctor.

Any news on a new release with this fix implemented?

Cheers ??

I’ve updated the plugin. Please let me know if this has resolved the issue for you.

I’ve updated the plugin. It is now getting rates from Yahoo, and seems to be working.

Note: Part 3 may not be necessary. Having cleared the cache manually from the database the plugin works as it should with both ! marks present. I suspect that the cache was populated with 0’s due to the error listed in part 2

Part 3
——

The final piece of the puzzle appears to be caused by a caching system I haven’t fully figured out yet. For now, the easiest fix is the following

Change line 388 in worldcurrency.php which looks like this
if (!!$dt_wc_options['cache_rates'] && $dt_wc_options['cache_time'] >= (time() - 86400)) {
Get rid of one of the ! marks at the start of the line.

Done ??