High-Performance Order Storage Upgrade: FAQs

Over the past few weeks, we have been meeting with the community in the #upgrade-party Slack channel, providing support to extension developers in the community who are upgrading their extensions to be compatible with the new High-Performance Order Storage (HPOS).

We’ve collected some of the questions which have come up in the V1 edition of the HPOS Upgrade Party in hopes that it will help others who may encounter similar issues.

If you are in the process of upgrading and don’t see your question answered here, we’d love to help you get ready for HPOS on October 17th–18th between 6:00 and 20:00 UTC in the #upgrade-party Slack channel. Find out more in the official Upgrade Party V2 Invite


Q. Are any code changes required where a custom taxonomy has been registered against the shop_order post type?

A. No, not for existing orders. However, for new orders, we insert a placeholder row in the posts’ table with post_type set to shop_order_placehold. If you check post_type directly, you may need to modify it.

Q. What is the recommendation for dealing with wpdb queries where joins happen to the posts/post meta tables?

A. If you are joining custom metadata, then using WC_Query with meta_query param will handle both data storage types. If you are joining a meta_key, which is now migrated to a proper column in the HPOS, then you should be able to use a field_query param with the same property as a meta_query. We plan to backport this to CPT so that the same query works for both tables.

Q. When looping through lots of orders and updating meta is there a way to update some meta without needing the full $order object?

A. You can get all the orders in one go using wc_get_orders and then use the returned order objects to loop over. `wc_get_orders` uses very few queries to fetch in bulk, so it should be fast.

Q. Marketplace plugins are using post_author to assign the vendor to the order. Will there be a need to create a lookup table?

A. It would depend on how that field is being accessed. It could continue to work as before if they are using WordPress APIs directly, as it would work around the fact that it’s not included in the default Order fields. As we still create the placeholder post in the posts table, extension will have a place where to store the data. However, we might add this field to the Orders database if there will be a strong need for it.

Q. Will users get the updates of extensions like WooCommerce Stripe Payment Gateway & WooCommerce Subscriptions to support HPOS?

A. Yes, both of these plugins are under active development to support HPOS. 

Q. My existing orders don’t seem to be automatically syncing. What’s wrong?

A. Try clicking on the Save Changes button. That should trigger the sync again. Ensure you have checked the “Keep the posts table and the orders table synchronized” checkbox.

Admin WooCommerce>Settings>Advanced>Custom data stores

Q. All of my interactions with order data happen through the CRUD. Will everything continue working as expected?

A. If all interactions with order data happen through CRUD, then everything should work as expected, and you shouldn’t need to change anything.

Q. Which hooks and filters are available in the new HPOS? 

A.  We are using the same WP_List_Table class that custom post types use to render all order admin screens. This means that all hooks and filters that were available in the posts screen are available with HPOS, however, the screen_id have changed. For example, if you have been using manage_shop_order_posts_columns, you can use manage_woocommerce_page_wc-orders_columns. The parameters passed will remain the same, but wherever you have been getting a post object, you will get an order object instead.

Similarly, you would need to replace the screen_id for all hooks and filters from shop_order_posts to woocommerce_page_wc-orders.

Q. The WooCommerce FeaturesUtil::declare_compatibility is not available in the latest, public WooCommerce release. If I build this check into my plugin, what type of check do you recommend before calling that function?

A. For the moment, you may use the class_exists check like this. You will be able to remove it once the minimum supported WC version for your plugin goes above 7.1.


6 responses to “High-Performance Order Storage Upgrade: FAQs”

  1. Perhaps a stupid question: how do I enable the HPOS feature, when there are plugins that don’t support it? The point is precisely to work on adding support for it, so I need it enabled to run my tests, and there are other plugins (not relevant to my tests) that keep blocking the feature.

    1. Sorry, still waiting for an answer about this. Thanks.

  2. Regarding the third question: “When looping through lots of orders and updating meta is there a way to update some meta without needing the full $order object?”

    The reply concerns getting the orders and not updating them. Is there a way to update orders in a more performant manner? This goes for products as well

  3. Arun Manglick Avatar
    Arun Manglick

    Please help to understand this change is released with which WC version – https://developer.woo.com/releases/

  4. Hi Woo team!

    We are happy to learn that High-Performance order storage (COT) has been rolled out. Looking forward to starting working on moving our integrations with inbuilt tooling in our company towards it.

    Before enabling it, I do have a question regarding the compatibility of other plugins. Almost all plugins we use to support our WooCommerce shop are on the not supported list. Since it is quite new I can understand this.

    I do wonder though why the warning at Settings>Advanced>Features says: “Shouldn’t be enabled…” From what I understand the HPOS implementation is in parallel to the old system, and both are fully synchronized.

    So my question is, what is the risk to enabling it when not all plugins are compatible, knowing that both systems can be used in parallel and are in sync? Will enabling HPOS break these non-compatible plugins?

    Cheers,
    Tim

    1. Hey Tim! Thanks for reaching out.

      The synchronization is a temporary failsafe system. Some operations will actually be slower with synchronization enabled, as changes to order data will need to be reflected in two structures instead of one. So it wouldn’t make much sense to run a store with the synchronization turned on long-term.

      And while there are no additional specific risks to enabling HPOS in your situation, more code will run. And statistically that just means there’s a few more moving pieces with more opportunities to fail.

      For these reasons we recommend only enabling HPOS when all the extensions you use are compatible. At first have it run with synchronization turned on to ensure everything runs smoothly with your specific store and setup. When you’re certain that everything works well it would then also be safe to turn off synchronization — and obtain the performance benefit from HPOS.

      Also note that even if you turn off synchronization and then discover a bug, you can still turn synchronization on again, wait for tables to get in sync, and then roll your store back to the posts table structure.

      Hope that helps!

Leave a Reply

Your email address will not be published. Required fields are marked *