Support

The request is blocked due to Mixed Content — it is sent over HTTP even though the site is fully served over HTTPS.

Our software does not determine the URL; Joomla itself does, as we're using its frontend router API which is the ultimate point of truth for converting non-SEF URL paths (such as index.php?option=com_example) to relative or absolute URLs on your site (e.g. /foo/example and https://www.example.com/foo/example respectively).

Joomla automatically determines whether your site is using HTTP or HTTPS, and uses the same protocol when generating the routed URL. Therefore, the question is why does Joomla think that your site is being accessed over HTTP when you are using an HTTP URL. There are exactly two reasons this can happen.

You've already checked the first reason ($live_site being defined wrong in configuration.php), which leaves us with the second reason – and, in fact, the reason the $live_site configuration option exists in the first place.

The problem is that your server does not pass the HTTPS environment variable at all, or it contains the wrong information. There are two reasons for this:

1. A server misconfiguration results in no HTTPS environment variable, or it's erroneously hard-coded to always return any value other than on.
2. Your site is behind a load balancer, CDN, or reverse proxy which accesses your site's server over plain HTTP. Additionally, the load balancer either does not send the X-Forwarded-Proto HTTP header at all, or your server does not parse the X-Forwarded-Proto HTTP header to update its HTTPS environment variable..

The ideal solution is to track down which of these two root causes is the culprit and fix it.

In case you cannot do that, this is exactly the use case for $live_site. You would have to set it to the HTTPS version of your site's URL, e.g.

public $live_site = 'https://www.example.com';

Setting the $live_site tells Joomla to forego its auto-detection and use the scheme (https://) , domain name (www.example.com) and path (none in this example) present in the $live_site configuration variable. Essentially, this exists so you can mitigate the effects of a server misconfiguration without having to address to misconfiguration itself.