Have you heard about CRUD? In programming it stands for Create, Read, Update, and Delete, basic operations we all perform with our data. With WooCommerce, that includes products, orders, customers, coupons, and other data stored in your database.

Recent changes to WooCommerce relating to CRUD mean that the platform is on its way to being more scalable. Note: This post does get technical and assumes a certain comfort level with PHP code.

Audio-learner? The points in this post are from my talk at WooConf 2017.

A more scalable WooCommerce

To make lives easier for our developers, we added special CRUD objects in WooCommerce 3.0. This replaces all previous post meta code in WooCommerce and must also be used by all extensions to enable a WooCommerce site to scale.

At the same time we added another set of objects called Data Stores, which are designed to load and save your WooCommerce data to and from the database. These abstractions are designed to enable WooCommerce to handle a larger amount of orders, products, and customers. This is accomplished by hooking into WooCommerce to have it use different means to store data.

Each data store implementation determines how the data is stored and retrieved, whether it’s from a database or another way of storing data altogether. By using them, it is now possible to scale WooCommerce up to enterprise sale volumes, with implementations that can handle millions of orders. All that must be done is to hook into a filter that redefines what WooCommerce uses to store data.

In addition to performance enhancements the CRUD and data store abstractions can provide, these constructs enable a lot more flexibility in how you save and load data for your WooCommerce store. For each type of WooCommerce datum (products, orders, customers, etc.), you now have the ability to programmatically decide from where that data should come, and where it should go. This allows store builders to tailor WooCommerce to fit their needs by interfacing with other systems, or upgrade performance of different parts of WooCommerce as needed.

In addition to performance enhancements the CRUD and data store abstractions can provide, these constructs enable a lot more flexibility in how you save and load data for your WooCommerce store.

What exactly does that mean? Well, think about the possibilities:

• Saving order data in a separate database from wpdb.
• Getting product data from an existing database on another system.
• Sharing product inventory across multiple sites (example below).
  Fetching product data via an API from another source.
  Making a CLI command to load from one data store and save to another (built-in import/export).

Extending data stores

With the CRUD and data store abstractions, WooCommerce no longer cares where the data comes from or how it gets saved. You can control that all yourself.

In the example below, I retrieve the inventory count from a separate service, and only the inventory count of each product object is changed. One benefit of doing this is I can have multiple WooCommerce sites sell from the same inventory count and be sure that I haven’t oversold my stock.

Here’s the entry point, the install_data_store filter.

https://gist.github.com/coderkevin/50eed1e4923428e51ece4fcfd45d0107

For the actual data store, there are two interfaces to implement: WC_Object_Data_Store_Interface and WC_Product_Data_Store_Interface.

This data store is designed to augment the existing data store (usually the default post meta implementation). It takes the existing data store in its constructor and only modifies the way inventory is handled. Everything else is handled normally through the existing data store.

https://gist.github.com/coderkevin/9d10818a5b7dbf8dcb9318c36148a7e0

For most of the required functions, this data store just calls the parent data store:

https://gist.github.com/coderkevin/6c2ae3fe60c13597de6354658cb6ea4a

The only change this data store introduces is how the inventory is read. For this case, it reads from the parent data store normally but overrides the stock quantity before returning:

https://gist.github.com/coderkevin/f56d649e38d1f214c76e109bad41395c

With the CRUD and data store abstractions, WooCommerce no longer cares where the data comes from or how it gets saved. You can control that all yourself.

The stock quantity above is retrieved from an API. In a real-world application, this API call could go to an inventory control system, or a POS, or even another WooCommerce site.

Complete code for the above example is available at: https://github.com/coderkevin/woocommerce-product-inventory-datastore

Endless possibilities with CRUD objects and data stores

As demonstrated in examples above, the possibilities are endless. WooCommerce 3.3, due for release on January 30, contains a further exciting milestone relating to CRUD. More at: WooCommerce 3.3 New Webhooks CRUD.

Use your imagination to create data solutions in new and interesting ways with CRUD objects and data stores, and be sure to let us know how you fare either in Comments or by joining the WooCommerce Slack community.