Orders in WooCommerce create a lot data in the postmeta table. There’s the standard WooCommerce fields (like _order_key, _cart_hash, _billing_first_name, etc.), but payment gateway plugins, marketing integrations, and other WooCommerce plugins also generate their own metadata. It’s not unusual to see more than 60 rows of metadata for each order.

I recommend the Post Meta Inspector to easily view all the metadata on any order or post. You may be surprised how much there is!

If you run subscriptions on your site and generate a lot of renewals, WooCommerce Subscriptions may be creating a lot of unneeded metadata due to how subscriptions and renewal orders are generated. This can cause your database to grow really quickly.

If you run a script to update order properties in WooCommerce, you may want to update the “post_modified” date along with the other updates. Many third-party integrations rely on the post_modified date to sync any order changes or updates.

Here’s how you can easily update the modified date (assuming you have the order object):

$order->set_date_modified( time() );

Here’s a full example which fetches the order, updates the date, and saves the order.

$order = wc_get_order( 123 );
$order->set_date_modified( time() );
$order->save();

I’ve been working with a “Trial Product” in a WooCommerce store which needs to be the only item in the cart during checkout due to shipping requirements (and because it doesn’t make sense to order a trial if you’re also going to order the actual product).

To make this clear to the customer, I’ve restricted what can be added to the cart in specific situations:

1) If the “Trial Product” is already in the cart, additional products should not be added. WooCommerce will instead display a notice asking the customer to remove the “Trial Product” from their cart if they wish to add different products.

2) If products are already in the cart, and the customer attempts to add the “Trial Product”, a notice will display asking the customer to remove the other items from their cart first.

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
• etc.

Needless to say, this took a lot of time. Thankfully, tests like this can all be automated using Ghost Inspector.

Continue reading →

In WooCommerce subscription products and standard products can’t be combined. For example, if you’d like to offer customers the option to purchase coffee as a one-time sale or as a convenient monthly subscription, you’ll need to create two separate products on the backend (even though it’s essentially the same product and SKU).

If you’re SEO focused, this might be a concern in terms of duplicate content and splitting page rank. For customers, this also isn’t a great experience. If a customer lands on the one-time product page, they might not know about the subscription option (and vicea versa).

A better example of subscription user experience is Target. If a product offers a subscription option, there’s a radio button toggle with a discount clearly highlighted. Turns out, with a little work, this is also possible to do in WooCommerce. Continue reading →

I am completely new to PHP unit testing, but I decided it was time to learn after discovering a critical bug in a small WooCommerce extension I had built for a client.

The extension I built added a feature that allowed administrators to limit specific coupons to new customers only. I had done some manual testing and made sure that new customers could use the coupon and existing customers could not. But there was a logic bug I missed that prevented existing customers from using any coupons, even ones that did not have the “new customer” restriction.

After finding the bug, I knew there were several use cases I would need to check every time an update was made to the plugin:

• New customer should be able to apply a coupon
• New customer should be able to apply a coupon with a “new customer” restriction
• Existing customer should be able to apply a coupon without a “new customer” restriction
• Existing customer should *not* be able to apply a coupon with the “new customer” restriction

Obviously, checking this manually each time would be rather tedious- which is why I turned to unit tests.