While that is better than throwing up an "insecure connection" message at the user, it defeats the purpose of having HTTPS.
Minimally, we want the HTTPS pages working and not redirecting the user to an insecure page. Even better would be to have the HTTP pages redirecting to the secure HTTPS pages (i.e. the opposite of what is currently happening). A purist would also want only the secure HTTPS pages to work.
For example, all the links in the body of the About ecocloud article has HTTPS links. But the pages visited end up insecure (e.g. there is no padlock shown in the URL field).
It is now working, after submitting a support ticket with FreshDesk. Apparently, the "problem was it was added to your portal but it was not enabled from the backend".
If you visit any https://support.ecocloud.org.au (secure HTTPS URL) you get redirected to the insecure version of the page http://support.ecocloud.org.au.
While that is better than throwing up an "insecure connection" message at the user, it defeats the purpose of having HTTPS.
Minimally, we want the HTTPS pages working and not redirecting the user to an insecure page. Even better would be to have the HTTP pages redirecting to the secure HTTPS pages (i.e. the opposite of what is currently happening). A purist would also want only the secure HTTPS pages to work.
For example, all the links in the body of the About ecocloud article has HTTPS links. But the pages visited end up insecure (e.g. there is no padlock shown in the URL field).