I recently had the chance to get acquainted with the difficulties of installing WooCommerce in the Network Solutions hosting environment. WooCommerce is an excellent plugin for bringing eCommerce functionality to your WordPress site, where it practically works out of the box, all you need to do is add your products and hook up a payment gateway.
In my case, I am using Moneris as my payment gateway, I which requires an SSL certificate to be installed on my web server for processing payments. Once installed, I turned on the sandbox processing environment (from the Moneris Payment Gateway plugin), and also the ‘Force secure checkout (Force SSL/HTTPS on checkout pages)’ to make use of the SSL certificate (and to secure customer information). With the backend setup for testing, add a few products to the cart on the frontend, and proceed to checkout here is where things get tricky. Once WooCommerce forces SSL/HTTPS on to the client, the server gets stuck in a loop until it finally times out, and you’ll be treated with a simple “Internal Server Error”. There is very little help on the cause and possible solutions for this issue from the hosting company and support forums , however the few articles I found directly reference Network Solutions and the WordPress function is_ssl() as being the cause of the issue.
WordPress has a function
is_ssl()that it uses to check whether a page is loaded with the HTTPS protocol, so that it can use the same protocol to load scripts, stylesheets, and other assets. It relies on the web server giving it a couple of clues, but when your website is hosted behind a load balancer, those clues aren’t always available. In particular, websites hosted by Network Solutions get no clues at all when pages are loaded over HTTPS. Ref: http://snippets.webaware.com.au/snippets/wordpress-is_ssl-doesnt-work-behind-some-load-balancers/
In the case of Network Solutions, client requests are going through a proxy or load balancer, then sent to the web server hosting the WordPress site. While the client requests are secure (HTTPS) while being delivered to the proxy/load balancer, the connection from the proxy/load balancer to the web server is not. Issues arise when the code being run on the web server wants to know what type of connection it has with the client. The WordPress function is_ssl() does just this, it looks at the headers and incoming paths for HTTPS, and has a fallback which looks if the request is coming in on port 443.
1. Turn off the ‘Force SSL/HTTPS on checkout pages’, this is what calls the is_ssl() function, and puts the application into an infinite loop.
* Change ‘subdomain.yourdomain.com’ to your domain.
I haven’t tested it out, but this gist does offer a server-side solution to detecting if there is an SSL connection: