Feeds are not cached

Hello cybmeta,

The reason you are seeing version 1.0.8.1 after re-enabling through the WHM plugin is mostly intentional. WHM uses a version list to determine what versions are available for use when performing the enable operation. We purposely delay adding the newest version of our cache plugin to the list for a few days to avoid any scenarios where an uncaught bug might be deployed to hundreds of servers using mass enable.

Once 1.0.9.1 has been added to the versions list you should be able to select it from the WHM plugins “Version Manager” section. For the time being please upgrade through your WordPress Admin Dashboard.

Our dev responsible for adding in feed caching is not in this week but if you can describe your issue I might be able to look into it myself.

Regards,
-Michael

Ok, I understand the issue with the WHM plugin.

After upgrade to 1.0.9.1, I set the “Default Feed TTL” to 86400. Then I load a feed and I get these headers:

accept-ranges:bytes
cache-control:no-cache, must-revalidate, max-age=0
content-type:application/rss+xml; charset=UTF-8
date:Tue, 30 Aug 2016 21:35:47 GMT
etag:"1315e5f473a33da96789ece15efd57e6"
expires:Wed, 11 Jan 1984 05:00:00 GMT
last-modified:Fri, 26 Aug 2016 12:44:27 GMT
link:<https://example.com/wp-json/>; rel="https://api.w.org/"
server:LiteSpeed
status:200
x-litespeed-cache-control:no-cache

If I reload the feed, I get a 304 response and the same no-cache headers, including x-litespeed-cache-control:no-cache.

I can wait to the dev be back to work. Don’t worry ??

EDIT: Sorry, it seems to work, I was logged in. Silly me. Some times I forget that I’m logged in WordPress even if I don’t see the some-times-hated admin bar.

By the way, related to this other thread, I see cached feeds contains ETag and Last-Modified headers (they are set by WordPress) but the server doesn’t return a 304 response if served from cache. I supppose it will be fixed in next version of LSWS as you said in the other thread, isn’t it?

If feed is not served from cache, I get 304 responses correctly, as I described in my previous comment.

No worries on the being logged-in part. I know it’s happened to me more times than I’d care to admit ??

As for the 304 response, this should be handled correctly once we add ETAG support for pages being served from cache. (Still planned for 1.5.8 release)

Regards,
-Michael