Develop WC

The official WooCommerce development blog

WooCommerce 2.7 beta 1 is here — December 15, 2016
2.7: A new CLI for WooCommerce — December 12, 2016

2.7: A new CLI for WooCommerce

WooCommerce brings many improvements to the WP-CLI powered command-line interface we introduced back in WooCommerce 2.5.

WP-CLI is a set of command-line tools for managing WordPress installations Our WC-CLI layer adds tools for managing products, coupons, payment gateways, shipping zones, and much more.

In WooCommerce 2.5 and 2.6, the CLI was powered by it’s own separate code. This code was separate from the REST API or WC core, meaning code could end being duplicated across the code base, or it meant that certain things possible in the REST API were not possible at all with the CLI.

2.7 introduces a new CLI powered by the REST API. We did this by forking Restful. This reduced the amount of code be need to maintain, provides a lot more power and commands, and means that the commands will always be current as we improve our REST API in the future.

Currently, following commands are available with list, get, update, and create operations:

wp wc customer 
wp wc customer_download 
wp wc order_note 
wp wc payment_gateway 
wp wc product 
wp wc product_attribute 
wp wc product_attribute_term 
wp wc product_cat 
wp wc product_review 
wp wc product_shipping_class 
wp wc product_tag 
wp wc product_variation 
wp wc shipping_method 
wp wc shipping_zone 
wp wc shipping_zone_location 
wp wc shipping_zone_method 
wp wc shop_coupon 
wp wc shop_order 
wp wc shop_order_refund 
wp wc tax 
wp wc tax_class 
wp wc tool 
wp wc webhook 
wp wc webhook_delivery 

There is a wiki page containing more information and examples. We’ll also work on generating documentation similar to our REST API documentation for each command. You can also use the —help flag to find out each commands parameters.

Please test out the new CLI commands and provide feedback or bug reports on GitHub!

WooCommerce 2.6.9 Security/Fix Release Notes — December 7, 2016

WooCommerce 2.6.9 Security/Fix Release Notes

The WooCommerce 2.6.9 security/fix release is now available. You can download it on WordPress.org or as an automatic update in your administration panel.

~44 commits made it into this release fixing several minor issues and taking care of some security hardening.

The main change was that we updated WooCommerce for compatibility with WordPress 4.7 and the new Twenty Seventeen theme!

The full changelog for 2.6.9 is below.

* Theme - Added support for Twenty Seventeen Theme.
* Fix - Excluded webhook delivery logs from comments count.
* Fix - Included password strength meter in "Lost Password" page.
* Fix - Order fee currency in admin screen.
* Fix - Variation selection on Firefox 40.
* Fix - Don't prevent submission when table is not found on cart.
* Fix - Improved layered nav counts on attribute archives.
* Fix - Fixed pagination when removing layered nav items via widget.
* Fix - Default BE tax rate.
* Fix - Downloads should store variation ID rather than product if set. Also fixes link on account page.
* Fix - Use wp_list_sort instead of _usort_terms_by_ID to be compatible with 4.7.
* Fix - Only return empty string if empty for weight and dimension functions.
* Security - Wrapped admin tax rate table values in _escape to thwart evil CSVs an admin user could upload. Vulnerability was discovered by Fortinet’s FortiGuard Labs.
* Dev - API - Only update categories menu order and display if defined.
* Dev - Fixed when should deliver wp_trash_post webhooks.

If you spot any further issues, please report them to us in detail on GitHub so the development team can review – comments on this post are closed.

WooCommerce 2.6.8 Fix Release Notes — November 10, 2016

WooCommerce 2.6.8 Fix Release Notes

We’ve made a small update today (WooCommerce 2.6.8) to fix a few issues. You can download it on WordPress.org or as an automatic update in your administration panel.

This release had ~14 commits.

  1. Fixed an issue where REQUEST_URI was missing a trailing slash during comparison in our page caching functions.
  2. Fixed an issue where empty prices were sent to PayPal.
  3. Fixed email validation on the account page.

We also took the opportunity to update our extensions screen so it’s a bit more modern.

If you spot any further issues, please report them to us in detail on GitHub so the development team can review – comments on this post are closed.

The new CRUD classes in WooCommerce 2.7 — October 27, 2016

The new CRUD classes in WooCommerce 2.7

High order volume is one of the best problems a store can have, but it can really slow down your site’s performance. That’s why our team’s main focus this year (and going into 2017) is performance and scalability.

We’ve put in motion a plan spanning several releases to help us tackle scalability head on, and you can read some of our discussions about orders in particular in this issue.

The first step, and something we’ve invested a lot of time in for WooCommerce 2.7, is abstracting the way we store and retrieve WC data. Why? Because right now we have no knowledge of how developers write data to the database for things like orders and products. A developer can use update_post_meta  calls, direct database writes with the $wpdb class, or the REST API as some examples. If we want to optimize where this data is stored, we first need to ensure developers use a single method of sending this data.

Retrieving data is also fragmented at present. You can use get_posts, $wpdb, WP_Query… all of which require you to know what type of data you’re trying to query.

Ideally, developers should not need to know or care about where and how their data gets stored. Be it meta data, or term data, it should not matter. This is why we’re abstracting everything.

What is CRUD?

CRUD is an abbreviation of the 4 basic operations you can do to a database or resource – Create, Read, Update, Delete.

The benefits:

  • We define the structured data for each resource.
  • We control the flow of data, and any validation needed.
  • As a developer, you don’t need to know the internals of the data you’re working with, just the names.
  • Once abstracted, the data can be moved elsewhere e.g. custom tables, without affecting existing code.
  • We can use the same code for updating things in admin as we do in the REST API and CLIs – everything is unified.
  • Less code = less change to malfunction and more unit test coverage.

Which resources will have a CRUD system in place?

We’re implementing CRUD in:

  • Products (in progress)
  • Customers
  • Orders
  • Order items
  • Coupons

These are the main types of data in WooCommerce and are currently each a custom post type, except for customers which are users and user meta.

Admin won’t be the only part of WooCommerce using the new CRUD operations – our REST API will too. This will make it all easier to maintain and more testable.

In addition, we’re working on making our CLI use the REST API, so again, this consolidates our code base and makes everything much more maintainable.

Examples of using the CRUD

Let’s take an existing example. I want to update an order’s address. With the current code base I’d end up doing something like the following:

$order_id = 100;
update_post_meta( $order_id, '_billing_first_name', 'Fred' );
update_post_meta( $order_id, '_billing_last_name', 'Flintstone' );

I need to know the post ID, the meta keys for each field, and I need to handle all validation myself.

Now the CRUD example:

$order = wc_get_order( 100 );
$order->set_billing_first_name( 'Fred );
$order->set_billing_last_name( 'Flintstone' );
$order->save();

I know an order has a billing first and last name property, but I don’t need to know that it’s post meta, nor that the keys are _billing_first_name and _billing_last_name. If those keys changed in the future, this code would be unaffected.

Getting data from the database follows a similar pattern. Old:

$order_id = 100;
$billing_name = get_post_meta( $order_id, '_billing_first_name', true ) . ' ' . get_post_meta( $order_id, '_billing_last_name', true );

New:

$order = wc_get_order( 100 );
$billing_name = $order->get_billing_first_name() . ' ' . $order->get_billing_last_name();

Where possible, the CRUD classes should handle mostly data reads and writes. Anything template related, such as getting HTML, should be moved to a template function. This is also something we’re working on in 2.7.

Examples of querying resources

Because we intend to move the data to a custom table in the future, it’s important that we offer a way to query the data without going through WordPress itself. Again, the developer should not need to know that orders are a custom post type named shop_order – this is irrelevant.

$customer_orders = get_posts( array(
    'numberposts' => 10,
    'meta_key'    => '_customer_user',
    'meta_value'  => get_current_user_id(),
    'post_type'   => wc_get_order_types( 'view-orders' ),
    'post_status' => array_keys( wc_get_order_statuses() )
) );

vs.

$customer_orders = wc_get_orders( array( 
    'customer' => get_current_user_id(), 
    'limit'    => 10,
) );

How will this affect existing plugins?

If you do anything with product, customer, orders, and coupons, you will be affected in some way. Even if you do a simple update meta call. This won’t break immediately, but your code will not be future proof. As soon as the schema changes in another update, your code will fail.

Helping out and testing

2.7 is scheduled for the new year. We will be releasing the first beta within the next month.

Orders, customers and coupons are all found in the master branch on Github here.

Products are still being built. Progress can be tracked in this PR.

It is very important, especially if you’re a plugin developer, that you get involved and start testing these classes as soon as possible. If you do anything with orders/products/customers, you need to be aware of the changes,  and if you need further changes or spot issues let us know as soon as possible. 

Feedback, code review, and PRs/contribution are welcome and encouraged on Github. We’d like to thank the developers working on this with us in advance. This will improve WooCommerce for everyone in the long run, so as a community let’s make it happen!