Memcache not working because of ‘cache-control: max-age=0, public’

Assuming all other plugins were problem free, I ‘reactivated’ them again and deactivated the AMP for WP plugin. The problem remains – which would appear that WordPress itself is generating the faulty command. I’m informed that such a thing cannot happen.

The Cache-Control header on the front end is likely sent by your hosting webserver, and not WordPress.

To test this, I create an InstaWP.com sandbox site — WordPress 6.3, Twenty Twenty-Three theme, no plugin. And I don’t see any Cache-Control header at all on the front end. Take a look for yourself here: https://redbot.org/?uri=https://ive-coyote-gazu.instawp.xyz/

If you’re not able to configure your webserver to send the desired Cache-Control header, you may use this WordPress plugin: https://www.ads-software.com/plugins/http-headers/

Good luck!

Hello George – thanks for your response. Much appreciated.

Firstly, I am not familiar with Sandbox techniques. I am non-technical, however I looked at a few YouTubes to familiarise myself and assumed from this you created a sandbox site to somehow simulate my website header. When I clicked on the link, it produced this data:

General

• The server’s clock is correct.
• The Content-Length header is correct.

Content Negotiation(Content Negotiation response )

• The resource doesn’t send Vary consistently.
• Content negotiation for gzip compression is supported, saving 55%.

Caching

• The resource last changed 62 days 15 hr ago.
• This response allows all caches to store it.
• This response allows a cache to assign its own freshness lifetime.

Validation(ETag Validation response ) (Last-Modified Validation response )

• If-None-Match conditional requests are supported.
• The 304 response is missing required headers.
• If-Modified-Since conditional requests are supported.
• The 304 response is missing required headers.

Partial Content(Partial Content response )

• A ranged request returned the correct partial content.

Comment: Sorry George, but this doesn’t tell me anything I can understand.

I tried installing the HTTP plugin, but it would not work on my version 6.3 website. It returned this error message, which I am unable tor resolve technically.

Warning!
The following file was not found. Please make sure the file exists and has write permissions:?/home/customer/www/mygospel.info/public_html/.user.ini

WordPress error message

You said that you didn’t see any?Cache-Control?header at all on the front end, yet when I look at GTmetrix, the response it showed below reveals the same error that I reported originally is still present (<span style=”text-decoration: underline;”>cache-control max-age=0, public</span>) as shown in the <span style=”text-decoration: underline;”>underscored</span> entry below:

Response Version – HTTP/2
access-control-allow-origin*
<span style=”text-decoration: underline;”>cache-control max-age=0, public</span>
content-encoding gzip
content-type text/html; charset=UTF-8
date Sun, 13 Aug 2023 23:15:34 GMT
expires Sun, 13 Aug 2023 23:15:33 GMT
host-header 8441280b0c35cbc1147f8ba998a563a7
server nginx
vary Accept-Encoding
x-cdn-c static
x-httpd 1
x-powered-by WP Rocket/3.14.3
x-proxy-cache MISS
x-proxy-cache-info 0 NC:000000 UP:SKIP_CACHE_ALREADY_EXPIRED
x-sg-cdn 1

I very much appreciate your assistance George, but it seems my non-technical skills have hit a brick wall with this. Can you offer any other solutions?

Many thanks!

Comment: Sorry George, but this doesn’t tell me anything I can understand.

First, I’m very very very very sorry for not being clear on what to look for in the Redbot link I provided. All I wanted you to see was the HTTP response headers (the black box)… the fact that there’s no Cach-Control in it at all for my WordPress site (whereas yours has it).

You said that you didn’t see any Cache-Control header at all on the front end, yet when I look at GTmetrix, the response it showed below reveals the same error that I reported originally is still present

Again, I’m very sorry for my sloppy language. Here, I was referring to my own test site… and not your site. And here’s all I was saying:

1. You had come to the conclusion that WordPress must be setting the Cache-Control header
2. But I claimed that it wasn’t likely to be WordPress doing this, that it must be your server doing this
3. To prove my claim, I provided an example of a plain WordPress site (no plugin at all) where there was no Cache-Control header at all.

I very much appreciate your assistance George, but it seems my non-technical skills have hit a brick wall with this. Can you offer any other solutions?

I just tested YOUR site again, but I don’t see the Cache-Control header any longer. So it seems you’ve fixed this already.

Hi George – thanks for your time and your patience on this – much appreciated.

Today I have been debugging what plugins were causing the Memcache to fail. The WP Rocket and the Clean Talk Antispam triggered the URL being tested not to be found in Memcache.

When you visited my website, you probably timed it when I had most of the plugins disconnected and was reactivating them one by one.

As it seems I am going around in circles and getting nowhere fast, it looks like I need a developer.

Thanks again for your time George – and regards,

Alan