LiteSpeed Technologies

Hi @tda325,

If you are willing to give it another try, I revamped the entire onboarding document today. Feel free to give it a try; I took your suggestions and made more screenshots and updated the text some.

Here’s the doc

Thanks,
Kevin

Understood. Apologies for the troubles. I will work to improve the onboarding document, so that it clarifies some steps.

Kevin

Hi @tda325,

I am sorry to hear that you had a less-than-ideal introduction to QUIC.cloud. We are constantly improving the product, and as it is in beta, documentation are quickly hashed together and become out of date rather quickly.

We will look to improve the documentation, as we do strive to make the process as easy as possible.

In the meantime, is there anything that we can help with as far as setting up QUIC.cloud for your site?

Best,
Kevin

Hello Nevma,

Apologies on our end as this feature was implemented a little clumsily and should work differently in our next version. I’ll try and address your concerns in order.

1. The idea behind removing this line is that it was likely left behind by another cache plugin when switching to LiteSpeed Cache. If this is not the case or it is intentional, then it should not be removed (more info in point 2).

2. Adding this line does not disable caching, it disables browser caching for HTML files (the finished page). The reason for this is that LiteSpeed Cache is a full page cache, so once the page is generated it is then cached and served directly for others without the need to re-generate. The problem with not having ExpiresByType text/html "access plus 0 seconds" is that if ExpiresDefault is set or ExpiresByType text/html is set to a value other than 0, the page will be cached again by the browser. So later on when you modify the post (for example) and LiteSpeed Cache intelligently purges that now outdated cache entry, all of your visitors whose browsers have cached the previous copy will continue to see the outdated copy until their browser cache expires or is cleared.

3 & 4. Sorry about that, for now please add a space before ExpiresDefault to avoid the message until our next version is out. This should no longer be necessary at that time.

Glad to hear you like the plugin! Once we fix this little annoyance your experiencing we would appreciate it if you could leave us a review if you have not already ??

Regards,
-Michael

Hi Dave,

If you’d like to keep ExpiresDefault for other unlisted file types that you may want to be cached by the browser, you can also try adding the following instead:

ExpiresByType text/html "access plus 0 seconds"

This should override the ExpiresDefault setting and allow LiteSpeed Cache to handle caching the page, instead of the browser. For the time being, also include the “space” as mentioned earlier to remove the error message.

Regards,
-Michael

• This reply was modified 7 years, 3 months ago by LiteSpeed Technologies. Reason: Missing Info

Resolved through our ticketing system.

Turned out to be unrelated to the cache plugin itself.

-Michael

Hello gnfb,

It is likely that your hosting provider has installed and enabled our cache plugin across their hosted WordPress sites using the ‘Mass Enable’ feature of our WHM plugin/cli script. You should see a message displayed in your WordPress dashboard explaining this if it is the case.

‘Mass Enable’ will also only install our plugin on WordPress sites that are not currently using another caching plugin. Your site should be loading much faster (for non-logged in users) now that it is being served from cache.

If you have any questions or concerns please do let us know, we are always happy to help.

Regards,
-Michael

• This reply was modified 7 years, 4 months ago by LiteSpeed Technologies.

The timer will not reset upon each visit to the site, only when the request hits WordPress. So once it is cached, it will be there for exactly 23 days and that’s that.

Yes, when you update the site, the cache will automatically get cleared.

There are no downsides to that ?? But some people may have certain requirements or things that may change on a daily basis for example, so they cannot cache for as long.

Cheers,
Kevin

Everyone will be served from cache after the initial visit, as long as they are logged out.

Make sure to set the TTL to a comfortably high level. If the TTL is 8 hours for example, once it is expired, the next visit will be slower.

@hampmir

To add to Hai’s response, our cache works like so:
If there are no cache entries, go to WordPress.
Process WordPress and create cache entry.
return to client.

So the fast response times are when the page is served from cache. If the page is not in the cache, it will take some time to create the page.

If you do not update your site often, you can set an extremely long TTL time (e.g. a week or a month), and that way it’s almost guaranteed to be a cache hit until you update your site again. Our plugin will know whenever you update your site, so the cache should be cleared automatically.

As Hai mentioned, the crawler is available as well to make sure that your pages are cached.

Hope this helps,
Kevin

So the caching logic itself is in the LiteSpeed server itself. This WordPress cache plugin is strictly used to communicate what to do with the cache entries.

Using the WP cron as an example, the request should hit the server first then go to WordPress. You do your thing and it adds a X-LiteSpeed-Purge header using our API. The response header is then processed by the server, and the server will purge the related post and the response is sent out to the client.

add_purge_tag will add the tag to the current request and the X-LiteSpeed-Purge header should contain the built purge tag.

I hope this clarifies things, let us know if you have more questions, we’ll be glad to help!

Cheers,
Kevin

Hi Hampmir,

You can send us an email (It’s listed in the plugin’s main page under incompatible plugins, we’d rather not repeat it here.)

Just attach a link to this thread so we know the context.

Cheers,
Kevin

Quick question – did you try to use the purge_single_post as global function? It’s actually a function inside one of our classes.

It should instead be something like:

if (class_exists('LiteSpeed_Cache')) {
    LiteSpeed_Cache::get_instance()->purge_single_post($post_id);
}

The error_log file may be wherever your wordpress is installed, each host does things their own way, so if you look for close to where your wp-admin directory is, that may be where the file is.

Hi @speechkit

I am assuming that you are trying to purge the post during the cron job.

Does your cron follow the typical WordPress loop? We depend on the shutdown action to send the header to the server to properly purge the cache.

If so, you could also try one of our other hooks/functions to see if it works:

if (class_exists('LiteSpeed_Cache_Tags')) {
    LiteSpeed_Cache_Tags::add_purge_tag(LiteSpeed_Cache_Tags::TYPE_POST . $post_id);
}

In our plugin settings, you can also enable debug log to check your modifications. This will output the response headers sent out during the request. You are looking for an ‘X-LiteSpeed-Purge: ‘ header.

Cheers,
Kevin