A big part of WordPress’ philosophies is embracing backward compatibility. And that commitment, for the most part, largely spills over to plugins and themes extending it. At least it should.
So when I read on the WooCommerce development blog about upcoming changes in 2.7+, I was at first encouraged that they’re embracing an abstraction layer for meta handling. Nice! Then I got to the part where they said they essentially plan to break backward compatibility in a future version for meta handling.
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.
Yikes.
There are several good, even necessary reasons to break backward compatibility. For instance, sometimes a product will force a backward incompatible change because something is being deliberately misused outside of the original intent. That’s not what’s going on here.
Frankly, the WooCommerce team’s decision smacks of convenience more than anything. Supporting backward compatibility is sometimes hard, but rarely impossible. And by choosing to break it, they may be unnecessarily playing with the fire that is user trust.
Won’t somebody please think of the users?
User trust isn’t something you earn and then just get to keep forever. It’s a maintenance relationship. So for WooCommerce – an extremely popular product with immense reach in the WordPress ecosystem – I would consider a backward compatibility break of this magnitude to be borderline irresponsible.
There are likely hundreds, probably even thousands of commercial and custom extensions for WooCommerce. Most, if not all of them, up until 2.7, will have probably relied on its usage of post meta for everything from products and coupons, to customer and order data.
Coming out and saying that at some point you will stop using post meta is completely fine. Coming out and saying that some point you will stop supporting post meta is not.
Use the hooks, Luke
There are more than enough hooks in the Post Meta API to facilitate backward-compatibility for previously-post-meta-now-something else data.
I know for a fact that the Easy Digital Downloads team are using those hooks since moving to a custom schema from post meta. Disclosure: I work for AffiliateWP, a sister product of Easy Digital Downloads.
There’s nothing saying that the WooCommerce team has to encourage use of post meta. Feel free to toss deprecated notices or use _doing_it_wrong()s, but don’t break what used to work before.
It’s easy enough for developers to shift to using the abstraction layers – I for one am looking forward to it – but WooCommerce wasn’t built for me. It was built for the people I (and an army of others) build things for, and it was built using post meta.
By all means, improve your code, but keep in mind: sometimes you gotta dance with the one that brung yuh.
“Chain Links” image by Danny Hope, used under Creative Commons.
But those changes are related to the CRUD classes in WC 2.7. The biggest issue in WC is doing things the WP way, which then runs into the issues of postmeta and usermeta at scale. So by using custom db tables for orders, customers and products it will address that core issue.
https://woocommerce.wordpress.com/2017/01/17/deprecation-in-woocommerce-core/
I think you’re missing the point. There’s absolutely nothing wrong with veering away from the WP way; moving to custom db tables is a great move for WooCommerce. But breaking back-compat for “the WP way” at some point in the future because it’s easier not to support how you’ve been doing it up until now (2.7) is super irresponsible. If WooCommerce wants to position itself as the go-to solution, it has to be willing to accept everything that comes along with that, which includes a certain level of stability and compatibility. If you want to wear the big britches you’re beholden to not unnecessarily rock the boat or do so at your own peril.
But CRUD classes in WC core is worth breaking backward compatibility for that huge gain. WC has had issues with how it handled session data in the options table, but worked on fixing that. Having orders and products as custom post type is fine for it being the “WordPress way” but that works fine for small product levels. At higher product levels postmeta will show those issues, so it does make sense on using custom well designed DB tables for those.
Again, I guess it wasn’t as clear as it could’ve been in the post … just don’t break back-compat for extensions is the point. It seems like you think I’m suggesting WC themselves should continue to leverage posts and post meta, and that’s not what I’m saying at all. I’m simply saying that their APIs should have a compatibility layer for the WordPress way for versions prior to 2.7.
If extensions want to leverage modern functionality they’re going to have to use the new abstraction layers and that’s a good thing, Maybe it’s just me, but forcing business owners to pay twice for the same functionality just kind of leaves a bad taste in my mouth.
But the WC extensions from WC.com will be updated to work with WC 2.7. So your not really a need to purchase twice, just update WC and extensions on staging to test.
https://woocommerce.wordpress.com/2017/01/17/wc-2-7-extension-compatibility-examples/