WooCommerce is a WordPress plug-in. In order to facilitate development using the convenience of WordPress, the WooCommerce development team uses WordPress’s custom post type to store orders. I believe friends who have developed WooCommerce themes or plug-ins know this.
Issues using post types to store WooCommerce data
Confusing WooCommerce data access methods
Since products and orders are both post types, we can use WordPress’s get_posts or WP_Query to store or get these data. The wp_posts data table that stores articles has limited fields and cannot store rich product and order data tables, so part of the data is stored in post_meta. We can access this data through WordPress’s get_post_meta and updata_post_meta functions.
At the same time, WooCommerce provideswc_get_product*andwc_get_order*Functions to help developers access data.
Some developers prefer to use native MySQL or someORM, access WooCommerce product or order data by directly operating the MySQL data table.
I have to say, it’s really confusing.
Performance issues caused by a large number of post_meta
In addition, by default, if a user places an order on the site, WooCommerce will create at least 40 post_meta data for each order. That is to say, if the website has 10 orders every day, the post_meta data table will add 400 rows. The larger the post_meta data table is, the longer it will take to execute the order query. This is a performance issue that cannot be ignored.
In order to solve the confusion of data access methods, we need to require developers to access data in one and only one way. In order to solve the performance problem, we need to change how and where the data is stored.
What is the WooCommerceCRUD abstract class?
In version 3.0, WooCommerce provides new CRUD classes to solve this problem. This is an abstract interface through which we can implement it.
- Customize the data structure for each type of data
- When accessing data, perform necessary verification on any kind of data
- As developers, we don’t need to know where the data is stored, we only need to know the API functions to operate the data
- Store data in custom data tables without affecting how the data is called
- Use the same code to update data behind the scenes as in the REST API and CLI – everything is unified.
- Less code also means fewer bugs and higher unit test coverage.
What data will be migrated to this CRUD system?
- product
- customer
- Order
- Order items
- Coupon
These are the main data types in WooCommerce, each of which is currently stored as a custom post type. Except customer data is stored in user and user metadata.
Comparison of two methods of storing WooCommerce data
Let’s look at how the new CRUD system is used through code. In the code below, we need to update the customer’s order name.
$order_id = 100;
update_post_meta( $order_id, '_billing_first_name', 'Fred' );
update_post_meta( $order_id, '_billing_last_name', 'Flintstone' );We need to know the article ID of the order, the meta_key of each data, and have to deal with all the verification. It’s so tiring!
Using CRUD, here’s how we update these two data.
$order_id = 100;
$order = wc_get_order( $order ); //得到 $order 类
$order->set_billing_first_name( 'Fred );
$order->set_billing_last_name( 'Flintstone' );
$order->save();Wait, why does the code seem to have one more line? Don’t worry, in the above code, we only need to know the data $order_id. As for the class method to obtain the data, we can enter it through the prompts of the IDE (such as PHPStorm). And in this way, we don’t need to care about how the data is stored in the database, which is very convenient and compatible with future WooCommerce versions.
What WooCommerce’s new CRUD class means
It seems that WooCommerce is gradually breaking away from WordPress. On the surface, this is the case. In fact, WooCommerce still uses a lot of WordPress APIs at the bottom level, and it is unlikely to completely break away from WordPress. Don’t forget, WooCommerce is now a product of Automatic, the parent company of WordPress.
On the whole, this change is good. The WooCommerceCRUD class provides developers with a more unified data access interface, which means better stability. As long as the data is accessed in a standard way, developers do not have to worry about changes in the underlying data; it provides an abstraction layer for data access, which means greater flexibility. WooCommerceCRUD data can be easily stored in other data tables, and developers do not need to change the way to access the data.
