How to Make WooCommerce Work with PHP7, Redis, Varnish Cache, Memcached and HTTP/2

I am an internet entrepreneur and was self managing my own server for the longest time. Without knowing how to use command line, what SUDO means, or being familiar with the Linux file system, I fired up a Rackspace server configured for WordPress and WooCommerce and began my journey as an online seller.

Things were going fairly good for a while but eventually I would need better performance and caching layers to keep things snappy and profitable (more speed, more conversions). And so the nightmare began. There I was, not sure how to implement these things and spending more time learning about being a sys admin rather than increasing my sales.

I learned how to get Varnish working and it did indeed make my website much snappier. But to my demise, the cart no longer accepted products and customers who wished to pay were greeted by empty order confirmations. I set out in a frenzied search to try and salvage my effort of becoming sped up with Varnish.

My journeys took me to the forums of wordpress.org. Other WordPress patrons were also having trouble getting Varnish working with WooCommerce and the cart and checkout pages. We collaborated and tested each other’s solutions. I read up on the Varnish documentation and learned that certain cookies weren’t being excluded from the cache which resulted in customer sessions being lost. I found examples of other Varnish commands on Stack Overflow and copied one command that contained the overall structure and went from there. I cross referenced with the Varnish documentation and inferred where edits should be made and commands added to achieve the exclusion of cart and customer session cookies. I fixed issues with the VCC-compiler by trying various combinations until I discovered what caused the compiler to fail.

I was in the end capable of producing several lines of code.

First draft:

 if (req.url ~ "^/(cart|my-account|checkout|addons)") {
return (pass);
}
if ( req.url ~ "?add-to-cart=" ) {
return (pass);
}

Longer attempt:

acl purge {
"localhost";
}
include "/etc/varnish/include/example.com_.vcl";

sub vcl_recv {
set req.backend = default;
return(pass);
if (req.url ~ "^/(cart|my-account|checkout|addons)") {
return (pass);
}
if ( req.url ~ "\?add-to-cart=" ) {
return (pass);
}
}

In the end, none of this worked. Customer session cookies were still being lost and carts remained empty. I turned off Varnish and gave up, at least for the time being.

And then the reply finally came. Someone had cracked the code and managed to get Varnish fully operational and compatible with WooCommerce – including with carts, products, customer sessions and all. The code was however not directly available to us. Instead, the person who was now successfully operating a WooCommerce + Varnish server had done it using a managed cloud hosting provider. He did not have root access and hence could not directly view the code. He said he would ask the engineers at the cloud company to hopefully share their fantastic discovery with all mankind.

As the days passed, so did the silence. The cloud company had not provided details, and one of the participants in the group had himself given up and instead signed up for the managed cloud hosting provider. He reported that the Varnish and WooCommerce server did in fact work. No one knew how the engineers at the cloud company had made it, but made it they had.

This put me in a peculiar situation. I was morally opposed to fully managed cloud hosting as I believed I would not learn as much and hence have less control over the intricacies of my online business. But it was also dawning on me that if I truly wanted to become a good sys admin, I would have to forgo becoming a good online seller. I chose to go with the latter and signed up for the managed cloud hosting provider as well, dreaming of the possibilities of a Varnish-enabled WooCommerce store.

The new cloud provider had a tool that would let me migrate my entire WordPress site from RackSpace to one of their cloud servers in one click. I was highly skeptical of this given my previous experiences with bold claims. But to my surprise the store migrated perfectly. All I had to do was enter my domain name and my website was back up and running, now emboldened with Varnish directly injected into its veins. Varnish was fully working and gloriously caching away while never touching a WooCommerce customer session cookie or cart cookie ever again. I had finally accomplished what I had set out to do – making WooCommerce play ball with Varnish.

I can’t access root so I can’t tell you which settings ultimately got Varnish to work with WooCommerce. But the managed cloud hosting provider that ultimately figured it out is called Cloudways. I recommend you give them a try if WooCommerce is your bread and butter. I am using them now with great results.

Aside:

To be fair, at first I hated the fact I had been swooned over to Cloudways since it meant less control for me. I was however tired of pretending to be a sys-admin. Rackspace also required a minimum of $500 per month to get their managed service level activated, to then attempt to fix my Varnish configuration with no guarantees. The same performance for $60 at Rackspace cost $30 at Cloudways. I went up one level and got better performance than Rackspace for $75, and another perk is finally not having to dabble with the back-end anymore. I also switched because of running PHP7, and updating that on Rackspace turned out to be a pain.

 

Leave a Comment