Support

It's INACCURATE saying that Admin Tools is not compatible with Litespeed servers. This site is running on Litespeed and you can bet we're using Admin Tools.

What you probably misunderstood is that Litespeed Cache is defying the HTTP standard headers, therefore it is incompatible with everything, including Joomla itself.

If you use LiteSpeed Cache all your pages become cached. This has many important repercussions. Any kind of form that you are using on your site, including a login form, will stop working since LiteSpeed Cache will be serving a stale version of the page with the wrong security token. Any extension which needs to display different content on the same URL based on the currently logged in user including but not limited to Joomla's core content (see custom fields, for example) and most third party extensions will show the wrong things to the wrong people which may potentially be a GDPR violation. E-commerce extensions cannot work, period — they are dynamic by their very nature. The list goes on and on.

LiteSpeed Cache ONLY MAKES SENSE ON STATIC SITES. Think about company presentation sites which do not have a frontend login, do not have any user interaction, they could just as well be static HTML. Same for most news sites, comment sections notwithstanding.

Since most sites we see created with Joomla are far from being static we very strongly recommend AGAINST using LiteSpeed Cache.

CloudFlare, on the other hand, respects the standard HTTP headers Joomla sends to notify the clients — both CloudFlare and the browser — that the page should not be cached. There are no problem whatsoever. Us having this conversation here on a site served through CloudFlare is the living proof. And yes of course you can use Admin Tools with CloudFlare. If anything, you will see less attacks reaching your site which means that you will see the number of blocked requests by Admin Tools going down. That's a good thing. We're all for a multilayered approach to security and we've been recommending it for the past 11 years.

Yes I know this point, si why this solution is offered and used?

Because many sites are essentially static sites. They are company presentations, news sites (with third party comments, e.g. Facebook or Disqus, which do not change the HTML created server–side), association sites etc. They have a CMS to make administration of the content easier in the backend of the site.

Other sites are mostly static except for a members area or shop area with a common URL prefix. For these sites it's easy to tell the LiteSpeed Cache plugin to exclude pages with these common URL prefixes from caching.

I would of course argue that Joomla's Progressive caching is better but not all sites are made with Joomla. WordPress is extremely slow and third party caching solutions are incredibly finicky. For those sites Litespeed Cache makes perfect sense. Of course if you offer one server–side caching solution for one CMS you need to do it for the others too, even if it doesn't make sense.

I hope that clarified things.

No, you do not need to combine multiple CDNs. It's an overkill and a safe–sure way to create a hard to troubleshoot mess out of your site.

It also wouldn't make your site faster. It would make it slower. A new visitor would have to resolve yet another domain name. The endpoints of the pull CDN might not be in the same data centre or geographic area as CloudFlare, having different latencies. The browser can only open up to 8 concurrent connections in total. Having them all open to the same server / CDN endpoint makes it easier to retrieve resources as they are needed. If you add multiple domains which host static files your browser needs to open and close connections to each domain with everything that entails about performance (there's a minimum of handshake that needs to be performed with each server for each connection before data flows).

There are two kinds of CDNs.

1. Those which act like reverse proxies, e.g. CloudFlare. The request hits the CDN. The CDN decides whether to serve a cached file or ask your server for a new file. These do not require any server–side code. You just need to set Joomla's global configuration option that you are behind a CDN or proxy server.

2. Those which act like file repositories, e.g. Amazon CloudFront. The request hits your server. The URLs of static files are rewritten by server–side code to reference a CDN URL. Whenever a file changes on your site, server–side code needs to update the copy on the CDN and issue an invalidation, i.e. tell the CDN the file has changed so please update all your endpoints. Those CDNs require a Joomla plugin to work.

Either way, this is outside the scope of using and receiving support for Admin Tools. In both cases Admin Tools will run when Joomla runs, i.e. when your server is handling a request. There is nothing special about it. Both solutions are perfectly valid, it's up to you to decide which one works best with your use case. We cannot offer advice on that.