cybmeta

Sorry, I can not reproduce the issue consistently. I will try to do it and will come back.

I will contact via the support form, thanks Jeremy.

Was did resolved? How? Same problem here in shared hosting with OVH. I’m being blocked with several IPs in the error message, but none is my IP. If I whitelist a IP, another one appears in the message. I’ve whitelisted 11 for now.

Dessign.net themes doesn’t use WordPress dependencies manager at all, at least not in all the themes I’ve seen from them. You should complaint to them, WordPress has nothing to do, as WordPress can not force to the developer to code in the right way, excepts for themes included in the www.remarpro.com themes directory (they are reviewed by Theme Review Team). Should they review also the products of companies listed in the commercial themes directory, whre Dessign.net is listed? I think so, but actually they don’t.

Things go and come. And that is always good, @diegocanal

• This reply was modified 8 years, 4 months ago by cybmeta.
• This reply was modified 8 years, 4 months ago by cybmeta.

Hi @diegocanal!! I know about that update, and about the fork that fixed this and lot more issues earlier, including security issues. Anyway, I don’t use W3TC anymore, the poor communication that its developers had for so long time, even for people who bought premium support, made me switched to other cache solution some time ago, and I’m happy with the change.

Tested and working. Thank you!!

You don’t need to apologize, everyone of us need help some times and everyone of us is wrong sometimes.

Glad to help.

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.

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.

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 ??

It is not easy to understand the desrcription of your problem.

As far I understand, you have enable privacy (Basic Auth, I supporse) for wp-admin directory and the problem is that any user in the front end of your site is requested to authenticate (Basic Auth credentials, I suppose, not WordPress user credentials, correct me if I wrong).

If what I understood is correct, I think you are loading resources from wp-admin in the frontend and that is the problem. For example, if “post views” (please explain what you mean with “post views”, I suppose they are post hits counting from some plugin) are loaded using WP Ajax API, then it requieres a call to wp-admin/admin-ajax.php. As you can see, it is a resoruce under wp-admin, which is protected by your implementation of Directory Privacy.

In that case, It has nothing to do with LS Cache plugin.

Try to exclude requests to admin-ajax.php from the privacy protection. Put these lines in the .htaccess file under wp-admin directory:

<FilesMatch "admin-ajax\.php">
	Order allow,deny
	Allow from all
	Satisfy any
</FilesMatch>

`Yes, it does. Everything is perfectly clear.

Thank you!!

Ok, thank you.

Anyway, adding support for ETags in .htaccess would be great also. Don’t forget that.

I tried to add it in the regular WordPress .htaccess using the code above, which is what I was using previously within W3TC cache storage directory, but with LiteSpeed only Cache-Control is added.

Anyway, there is a problem by adding ETags in the regular WordPress .htaccess. I think it would be better if ETags are handle by LiteSpeed Cache module and not in the regular WordPress .htaccess.

Why?

Although I couuld accept adding ETags to all responses, I’m sure many people would want to add ETags only to certain documents types, and that is not always posible in the WordPress root directory. At least I’ve not found a way to do it.

For example, if you use this permalink structure for a post: example.com/some-post, it returns a HTML document but without a html file extension, so you can not use FileMatch. You can not check mime types neither at this moment, as it requires the response and we are earlier.

There can be also a URL that returns a XML document, for example example.com/comments/feed.

In this context, using the root .htaccess you could not add ETags only to HTML documents if you want. At least, again, I’ve not found how to do it.

In other cache plugins using disk for cache storage, this can be solved by using the .htaccess in the storage directory.

That is why I think if you shold be handle by LiteSpeed Cache module. I hope it makes sense.