WooCommerce sites are made up of a complex set of integrated parts. There’s WordPress, WooCommerce itself, other third-party plugins, and a theme. Each of these components require frequent updates and has the potential to break critical functionality on your site. This is why it’s critical to have automated tests.
For a WooCommerce site I used to work with, we had a checklist of items we would manually run through after any major update:
Verify products on home page look correct and load
Test “Add to Cart” button
Test removing item from cart
Verify all product on /shop page look correct
Test complete checkout with Stripe for guest checkout
Test complete checkout with PayPal for guest checkout
Test complete checkout with Stripe with coupon for guest checkout
Needless to say, this took a lot of time. Thankfully, tests like this can all be automated using Ghost Inspector.
I haven’t found a solution for the Safari issue yet, but thought I’d share the method I’ve worked out for cross domain tracking with Mixpanel for the remaining browsers.
For the example, I’ll use domains a A.com and B.com. A.com is the primary website and B.com is a marketing website that refers traffic to A.com.
On domain A.com you’ll need to set up an URL that loads the tracking code when it’s called inside of an iframe. We can pass tracking data from B.com to the iframe using a query string, and an efficient method for passing that data is by base64 encoding an JSON object. Continue reading →
We use Mixpanel at Cratejoy to track a lot of user interactions across the sites. However, there was a lot of profile data we were storing (and paying for) that we weren’t actually doing much with. So, I decided to see if it was possible to back up this data locally, create re-import files (in case we ever needed it again), and then delete in bulk.
The JetPack plugin makes it easy to add share buttons to posts in WordPress. With a little custom code it’s also possible to track how often the share buttons are clicked and which URLs are being shared.
When developing WordPress sites I generally have three environments: live, staging, and local. Since I like my staging environment to be a very close replica of production, I frequently overwrite the database and files in staging. This is especially true when working with a host like WP Engine that has one-click staging environments.
However, when the database is overwritten in staging, there’s a generally a few settings that still need to be different from production. For instance, with WooCommerce sites, I may need to deactivate SSL and put Stripe into testing mode.
Occasionally I’ll also need to deactivate certain analytics plugins or third-party API integrations like MailChimp.
After making these updates manually for months, I finally moved to a programmatic update routine for many of my sites. The code basically just checks which environment we’re in. If it’s not production, it checks if the settings have been updated yet. If not, it makes the updates. Continue reading →