I'm in the process of evaluating e-commerce platforms, so I thought I'd give prestashop a try.

I've evaluated prestashop a few years ago. It seemed OK back then, but only by comparison to other shopping carts. The hook system seemed overly simplistic and the back-end admin interface was tired.

Let's Encrypt SSL

Ever since Let's Encrypt launched, I've secured every one of my sites. I only have port 80 open to redirect users to the SSL port.

server { 
    listen       80;
    server_name  igotaprinter.org;

    location '/.well-known/acme-challenge' { 
        default_type "text/plain";
        root        /tmp/letsencrypt-auto;
    } 
    location / { 
        return       301 http://igotaprinter.com$request_uri;
    } 
}

As you can see from the above nginx configuration, I only allow http traffic to the location required by the Let's Encrypt service. For some reason, LE doesn't work with SSL at this point :/

Prestashop Installation

The setup for Prestashop is pretty self-evident. I ran into a gothca though, after the setup and when trying to access the front store page.

I was presented with the above page in Firefox after properly installing Prestashop and trying to access the store front. I could access the back-end fine. This was kind of perplexing because I knew it wasn't a PHP / PATH_INFO / rewrite problem - because the back-end worked.

Although, it would be possible for Prestashop to have different front-end and back-end URL parsing schemes, I thought this wasn't likely. I opened up Firebug and put the network panel on "persist" to record all the redicrects.

What I found is that it was constantly redirecting AWAY from HTTPS and back to normal HTTP.

That is a really dangerous practice.

Nobody should ever redirect away from SSL as a general rule.

Prestashop's Bone-headed SSL Decision

Just before giving up and deleting my Prestahop installation I found some settings on the back-end.

I found an option to "Enable SSL", which defaults to off. Well, in a setup like mine, where I force SSL at the HTTP server level - and NOT at the PHP level - this doesn't work. It ends up in a redirect loop.

Why is this bad? You should never simply redirect someone off of SSL without good reason. In fact, I can't find any example of where it would be a good idea to redirect from a secure connection to an insecure connection.

Why else is this bad? Load balancers.

Load balancers usually terminate the SSL and forward plain HTTP into the Web servers at the same hosting provider. In this sort of setup, PHP will never see an SSL connection. PHP shouldn't care about SSL.

When a project's default settings don't work with properly secured servers and don't work in a load balanced setting, I immediately assume it's not form me. How many other decisions have been made so that this project works for the single site operator on a single machine? Probably a lot of them.

In addition, the second optino of only enforcing SSL on "some pages" - without telling me which pages those are - is pretty scary. This doesn't look like a product I want to run a business on.