Custom Order Table (Woocommerce Scaling)

[erikdemarco]

I'm recreating this thread. Because all the old thread about this seems always closed suddenly while in discussions.

Its been 5 years since Mikejolley starts working on it. But until now it's gone without any trace.

Is there any update about this feature?

This is the most important feature, if woocommerce want to scale.

Because we keep hearing some "woocommerce experts" says "I laugh when I hear someone say woocommerce can't scale".

In real life example. Many stores starts with woocommerce but once they become too big they always move to shopify. The most recent example is colourpop. They move to shopify after they hire many "woocommerce expert" to scale their system but all of them gave up which makes them move to shopify.

This is for comparison:
-) List of Top Shopify stores: https://www.automizely.com/store-list/top-100-shopify-stores
-) List of Top Woocoommerce stores: https://www.automizely.com/store-list/top-100-woocommerce-stores
-) List of Top Magento stores: https://www.automizely.com/store-list/top-100-magento-stores

As we can see The only real store which use woocommerce and rank under top 20000 alexa rank, only woocommerce.com.
We keep losing our "big clients" to our competitors.

[masteradhoc]

+1 👍🏻

[lkraav]

Sure, except re-filing these duplicate issues is mostly a waste of everyone's time. Everything that has been said and can be said about this, admittedly important, topic is filed at liquidweb/woocommerce-custom-orders-table#183

Only things that can move this forward are:

• qualified engineers
• funding for ⬆️ for x+1 months

[lkraav]

At minimum, this is a duplicate of #30078 which is still open.

[DavidAnderson684]

Sure, except re-filing these duplicate issues is mostly a waste of everyone's time.

With respect, the major waste of time is the WooCommerce core development team's failure to deliver upon their responsibility to deliver this feature in a timely fashion. This has been a huge management and process failure, and it should be something that the community receives regular updates on rather than simply silence and vague generalisations. All over the world, since 2015, WooCommerce store owners have burned thousands of hours on investigating and implementing work-arounds for the performance problems that come up once you reach a certain size. If users feel the need to express their frustration over that situation, that's very understandable. The idea that Automattic lack the financial resources to see this through is absurd. As someone who's sold a lot of WooCommerce-related products, I don't say this lightly or without consideration. What has been lacking on this matter has been project leadership and responsibility.

[lkraav]

With respect, the major waste of time is the WooCommerce core development team's failure to deliver upon their responsibility to deliver this feature in a timely fashion.

I think we're all in agreement on this.

Yet, filing these duplicate issues probably won't do anything to further the cause.

[juliaamosova]

Hi @erikdemarco,

Thank you for opening the issue! It requires further feedback from the WooCommerce Core team. I am adding the needs developer feedback label to this issue so that the Core team could take a look.

Please note it may take a few days for them to get to this issue. Thank you for your patience.

[Konamiman]

Hi @erikdemarco. We are actively planing to adopt a custom tables based approach, but we need to make sure that the implemented solution doesn't break any existing shops and thus it'll take some time.

[peterfabian]

Hi all.

This is fair criticism and thanks for pushing us towards a better WooCommerce we can all use effortlessly.

We have been focused on improving performance and delivered various changes that sped up WC core, most notably different lookup tables that speed up the costliest actions done on products and orders.
We have been also running test sites that have hundreds of thousands of products and orders to compare the performance of WC versions and ensure we don't see any regressions and that we can see how usable it is under such load.

We'd love to bring you custom tables, but the problem is that lots of plugins that integrate with WC are still not using the db abstractions, and that means we can't roll them out without causing significant breakage ​to peoples' shops.

We have been hearing the same voices, on the one side people asking for custom tables, but on the other side also experts saying WC can scale and it's mostly other plugins adding more unoptimized queries are dragging the sites down. Thus our evaluation between breaking a lot of stores vs adding some performance just didn't seem like a reasonable tradeoff.

In addition, we also don't want to promise things we can't deliver, so that is why we've been reluctant to give specific answers to this question.

With all that being said, we are not abandoning this idea as we still think it makes sense from multiple perspectives.

I will close the issue for now, but will update you folks here when we have some news. Hope you understand.

[KoolPal]

@peterfabian : A simple CHOICE to users would have been a better approach! Choose between Custom Order Table vs Broken plugins.

Serious plugin authors would EMBRACE this change while others would abandon ship!

Such instances forces one to evaluate the difference between mediocrity and excellence!

[DavidAnderson684]

For me, this is all very disappointing.

It's simple programatically to hook into the WPDB layer, detect which plugins are using the wrong approach, and stick a big warning on the dashboard so that store owners and plugin developers finally see a reason to act. It is understandable that after 5 years there might be ones who still don't believe that they need to act because nothing is going to happen.... how can we conclude that proving them right was the right response all along? Should bad plugins really be awarded a permanent veto on improvements?

The juxtaposition between "people asking" and "experts saying".... ug. If the WooCommerce team don't know where in the core code inefficient SQL queries caused by the posts/postmeta split is, and think it's only bad plugins that do them... I don't know what to say to this. On your stores with hundreds of thousands of orders, how many rows do you get in the monstrous join created by WC_Customer_Data_Store::get_total_spent() ? You should be seeing millions. Edit: I suppose you do at least say "mostly". But that's really a fatal concession, isn't it? Core WooCommerce's SQL is only "mostly" in proper shape for large stores. Large stores need expert hand-coding and DB management skills to cope with the rest.

[erikdemarco]

@peterfabian
"that means we can't roll them out without causing significant breakage ​to peoples' shops."
I completely agree 100%. But looking back at what we have done is the opposite. Remember "woocommerce Admin, woocommerce blocks, woocommerce analytics, woocommerce marketing? Eventhough many many people complain about this breaking their sites and many many bad reviews, We still force it to combine it into core. I dont understand who's idea to make this features (which starts as a plugin) merge it into core. That person should be fired. If people want that feature, they will install it themself. Yeah in short term maybe we get more income by doing this. But in long term it will wreck our image as a slow, complicated and heavy ecommerce platform.

I think woocommerce team should now be focus on performance. Instead of adding more and more bloat features. All this additional feature making it more and more complicated to integrate order table. As a result its very unlikely we will see this feature added in our lifetime.

[masteradhoc]

@peterfabian thank you very much for responding to this ticket and explaining the situation. EDD went the way with reworking the plugin into custom tables and i definately liked the approach.

1. Plugins
   "but the problem is that lots of plugins that integrate with WC are still not using the db abstractions"
   I think we all agree that Abstractions have been introduced a long time ago. If after such a long time important plugins still not comply they will probably never do. Should we then never continue? I doubt this is the best solution.

A solution like @DavidAnderson684 suggests to show a early warning already will lead to a lot users messaging their plugin authors to change the way their plugin works. Same worked also with the JQUERY Migrate Solution and a very very old jquery version was able to be moved to a newer solution.

2. Invests in Performance
   We all value the invests that have been done in performance so far. The newest WP Make Posts shows that their still is a big potential: https://make.wordpress.org/core/2021/10/12/proposal-for-a-performance-team/

Its really time to focus on this and invest the needed time to preinform plugin authors / users of woocommerce so they have enough time to get compliant. Then to roll it out step by step.

Thanks for all efforts and discussion of this important topic.

[makeonlineshop]

+1
@Konamiman This is already the ridiculous reply that was giver 5 years ago ! Time to feel ridiculous ?!

"We are actively planing to adopt a custom tables based approach, but we need to make sure that the implemented solution doesn't break any existing shops and thus it'll take some time"

@peterfabian YES ! Close this issue and let's hope that nobody talks about it within the next 5 years ? Exactly what all the cheaters and scammers politician do ! Are you in politics soon ?

BLA BLA BLA BLA....

BLA BLA BLA BLA....

BLA BLA BLA BLA....

BLA BLA BLA BLA....

[tonybahama]

This is a real shame.
I can only say what I say every year. The argument that "WooCommerce can scale with expert help" is weak, it's like saying the car can go over 100 km/h, but only when thrown out of an airplane.
WooCommerce should not collapse with a few tens of thousands of orders. We have several 100.000 and had to build a team of 3 devs to maintain the store and half of our time goes like figuring out workarounds for performance issues.

Shopify scales out of the box.
Now a sub 2 sec load is a must is ecommerce.

The woo leadership is a failure in this regard, with "backward compatibility" argument. Guess what, if you did not start using CRUD since 3.0, 6 fucking years ago then that is on you. Why are you prioritising the users who do not care about their store at all? Those should not update that is the end of story. What is the priority? Building the most mediocre solution possible?

You have the resources, with focused efforts both custom tables could be done is 4-6 months - since almost all is already developed, you should just wrap this up.

I cannot count how many serious store owners hate Woo just because of performance bottlenecks.

[peterfabian]

Hi,

I understand your frustration, it's been a long time, and not much progress on the custom tables.

However, there has been a lot of resources put into improving the onboarding, analytics, enabling customization via blocks, making it easy to manage shipping and payments, building the testing and release foundation so that we can ship the plugin consistently without breaking stores as much as possible. Why these instead of custom tables? Because they seemed like a higher priority from the product perspective. We are also hiring as quickly as we can to scale our ability to deliver improvements to you.

We hear you and appreciate your feedback. I wasn't trying to juxtapose people vs experts, apologies it sounded like that. What I wanted to say was that we hear feedback from multiple sources and use it as one of the inputs to our product decisions, together with feedback from our partners, internal users, user research, etc. And if user research says people can't figure out how to get their store up and running, we need to dedicate resources to improve the experience.

Regarding the WordPress performance initiative: thanks for bringing this up, we plan to to join the effort and use this as an opportunity to improve WC, too.

On your stores with hundreds of thousands of orders, how many rows do you get in the monstrous join created by WC_Customer_Data_Store::get_total_spent() ? You should be seeing millions.

Thanks for being constructive, that is exactly the type of feedback that is valuable to us. While we have a large shop that has a lot of data in it, it doesn't face live traffic and we don't use it to fulfill orders, so while there are some scenarios we run using our e2e test, etc, it's still useful to know where you folks struggle with performance in the real world.

I tend to agree that this is chicken and egg problem---plugins haven't updated to use the db abstraction, because WC haven't pushed custom tables and WC haven't pushed custom tables because plugins haven't updated to use the abstraction. The only way to break this cycle is if we push it deliberately, with a clear plan and roadmap towards the custom tables. I'd like us to work on that in the coming months.

[pacmanito]

This may sound pathetic, but you guys are building a house on sand. All the latest updates are clearly showing that Admin and Blocks are getting way more resources than WC core. The problem is that both Admin and Blocks do not solve any real problems, Blocks functionality is easily achieved through using 3rd party themes and as for Admin, all those reports are nice to have but it's not a must. In the meantime WC core has been hoarding problems over years and is lagging beyond Shopify every year. And these problems are difficult to solve by shop owners themselves because they are connected to WC architecture and tweeking it can cause a lot of troubles constantly sucking resources.
I am absolutely sure that there's no real problem with plugins compatibility. Switching the data endpoints beyond CRUD should be rather easy, therefore dedicated tables can easily be an optional feature for a year or two. And I want to second the argument about jQuery - I contacted a lot of plugin authors about deprecated jQuery and all who maintain their plugins were ready to solve the issue, while ignoring the problem was a clear sign that it's time to search for an alternative. So just make an announcement and plugins will be updated.

Beside outdated table structure there are a lot of other problems with WC core:

• you can't manipulate variations via WC bulk edit
• variations can have only one image
• you can't filter out of stock variations (AFAIK at least this one is being solved now)
• thtere's no real customer management system, they are just WP users with shipping address
• there's no built-in standard shipping tracking implementation
• there's no solution for multi-warehouses

Of course all these features are implemented through plugins which was justifiable years ago, but now in 2021 these features are expected out of the box. And what's worse most of these features when implemented through plugins lead to a need for custom solutions when you're integrating your WC store with some cloud services. The ECommerce has changed, everybody is selling on multiple channels, using multiple warehouses, dropshipping, etc., so easy integrations are a must. Just compare how many actions are available for WC and Shopify in Zapier and Integromat. Shopify has 2-3 times more because it has standard implementations while in WC some basic functionality is still in plugin territory. My SaaS inventory management platform sends tracking information to WC as order notes just because there's no built-in tracking implementation, listing products to WC leads to variations having only one image and syncing stock from multiple warehouses is not even planned because it's not in the core, etc.
So, guys please pay attention to these issues which can't be fully solved through plugins and have been asked for for many years.

[shmaltz]

If you are really worried about breaking so many sites due to developers not writing their plugins properly, why can you do what WordPress itself did with jQuery migrate? Make a helper plugin for those with broken sites and give plugin developers 6 months to fix their problems.

Also, for me and I'm sure many, having separate tables doesn't only benefit perform, but also allows you to backup/restore/migrate active stores much easier.

[DavidAnderson684]

Yes, separating orders from the WP posts table is very important for backup/restore, and also for having a proper live/staging/development split. Every shop owner, whether big or small, is affected by that one. Currently you can't just clone your site, make some changes, and then merge back the other tables, because orders, products, pages, posts and all other sorts of content are all blended together in the post/postmeta tables. So most people end up using their development sites to practise their changes, and then they do them a second time on the live.

[smgdarien]

Showing my support, a repost from Reddit

I think it's great this topic has gained attention, after some research this issue seems to be dismissed very quickly. I currently run multiple WooCommerce stores, but this is the pinnacle of WooCommerce's issue. As my clients grow, I constantly have to consider when it's time to switch them across to Shopify. It's interesting to read WooCommerce Custom Product Tables Beta and see how excited the team was to address this, and noting that it would dramatically improve the platform.

I know of all the workarounds to create an AWS environment to better scale the platform, but WooCommerce seems to always need a bandaid or multiple to compete with what Shopify can offer straight out of the box. Why would I spend a considerable amount of billable hours with a client when I could easily avoid it with Shopify? We all know WooCommerce has its pros, when it shines, it shines. The custom themes I have created are always enough of a reason to stay put until the final day of when a client will deal with their store slowing down.

[lkraav]

I felt like I had to comment on these issues for today's WC marketing blog article https://woocommerce.com/posts/can-woocommerce-stores-scale-truth-about-large-stores-with-examples/

"Truth", really? Not the whole truth, for sure, as far as I can tell.

Comment is still in moderation, but here's the text

Nice marketing article, but really – no mention of unsolved scaling issues at #30228 and Custom Orders Table feature plugin in pre-release beta for years liquidweb/woocommerce-custom-orders-table#183
Custom Product Tables plugin is doesn’t seem to be moving much either https://github.com/woocommerce/woocommerce-product-tables-feature-plugin
I think it’s a bit disingenous or misleading to talk about WooCommerce as a “simple to scale” product, today. Sure, it’ll hold up OK if you throw some tens of thousands of $ engineering resources at it. But it’s far for simple.

[glagonikas]

I'm glad to see more and more people commenting on this topic, hopefully, at some point, WC will realise it's a massive missing feature.

I get why WC goes for all the fancy features vs custom order and product tables. The fancy features drive more store owners and they drive more revenue.

Realistically, the vast majority of WC stores are small ones where they won't have (or notice) the performance degradation and will not have the skills to do anything about them. Larger stores will struggle but will probably have the revenue to spend on servers and/or developers to try and fix the issues.

I agree, WC is scalable to a certain degree and there are many ways to improve performance (caching, redis, etc) and yes, it can scale for a tiny business that's grown to become small and I think that's the audience meant to read the blog post.

For anyone who works with a large site, the blog post is simply an insult. It's a constant battle to ensure the site is fast (on non-cached pages), ensure our conversions aren't affected and we don't end up spending thousands on hosting.

It's also a struggle to fend off requests to migrate to Shopify. Why spend thousands on hosting, security, server management and fixing bugs when you can spend the same amount on Shopify and have fewer worries (and someone to blame when things go south)? Two reasons are features and extendability, but that's not always a tangible metric, compared to the loss of sales due to an outage, slow pages, and hosting costs. Are those enough to make me pick WC when setting up the next business?

I get why WC doesn't want to touch this issue. there's a lot that can break, especially on crappy plugins (some on woocommerce.com), but as people mentioned before, other big changes happened (bump PHP, MySQL, WP, jQuery versions) and WP/WC came out stronger.

@peterfabian rather than closing this bug outright, why can't we work towards the first step and break the chicken-and-egg situation? As David suggested above all it takes is

1. Announce that you're working towards merging the custom Orders and Product table plugins into core (to incentivise plugin devs). Even if you don't stick to it, it'll force most devs to clean up their act.
2. Display a warning on admin so store owners can pester plugin devs to change their plugins.

What's the worst it can happen? Nothing will break and you can phrase the message so it doesn't scare store owners onto Shopify. Something along the lines of "We noticed some of the plugins you use do not adhere to our best practices and prevent WC from releasing some new and exciting features. Please reach out to the developers of X plugin and ask them to start using CRUD. If you don't hear back from them, please let us know" . You can even keep track of the "bad" plugins via WC tracking.

Between the 14 participants on this thread, I'm sure we can make a PR for this?

Once that's done and live, we'll see how many plugins are really affected and if that's a real blocking issue or a perceived one (doubt you have real numbers at the moment?).

Also, you mentioned a lack of resources. I've suggested a few times in the past that If money is the issue (doubt it) people who want those plugins can fund them. You can estimate the cost and set a gofundme page. Anyone who thinks that's a big issue can pay you to get a dedicated team working on those. If WC becomes 20% (random number) more efficient thanks to those, that's 20% less hosting costs, more traffic and sales and for a big store, that translates to tens of thousands.

While we have a large shop that has a lot of data in it, it doesn't face live traffic and we don't use it to fulfill orders, so while there are some scenarios we run using our e2e test, etc, it's still useful to know where you folks struggle with performance in the real world.

Does WC hold a list of Big Stores (say hundreds of thousands of users/orders) when WC tracking is off? Is there a place where large store owners can register so you can reach out for feedback on issues you can't reproduce? Maybe an invitation-only slack channel or something where we can exchange information and best practices without the "noise" of low-level devs and salespeople who make unsubstantiated claims? It's likely that our site runs better than most in some areas, yet lacks improvements other large stores have.

[peterfabian]

Lots of good ideas and thoughts here. Thanks all for sharing. We really appreciate it and would love to use your help when testing the upcoming solutions for custom tables.

@glagonikas, I agree, let's keep this open and track the progress here.

[glagonikas]

Thanks @peterfabian!

What are your thoughts on adding the notice/warning proposed by @DavidAnderson684 ? Is this something we can send a PR for or it needs further discussion/specs?

[peterfabian]

@glagonikas I think that's a good first step to have it, as it encourages everyone to use good practices. We'd be happy to review such PR, and we can discuss the details in the PR itself, I think.

[shmaltz]

@peterfabian I love the sound of this!

[DavidAnderson684]

Concerning a dashboard notice for alerting if a plugin is editing order-related post/postmeta data without going through the Woo API, I think it could be done in the following way (sadly I am very short of time, but this may help someone who has the time):

• Hook into the various relevant post-meta filters for insert/update/delete/select operations, e.g. update_post_metadata

• In your filter code, go through the PHP stack (e.g. see in wp_debug_backtrace_summary() for code that does this) to see if the call has passed through the WooCommerce API or not (i.e. the stack trace contains API classes). If it has, return.

• note the ID of the post object for which metadata is being updated/selected/deleted/inserted.

• Get the post type for that ID. If it's a WooCommerce order, then save a summary of the stack trace in the DB as one that needs attention. If that stack trace already exists, just update the "most recent" timestamp for it. I'd also suggest saving the lookups for the most recent post IDs in a transient to improve performance. Or alternatively, if it was a SELECT (i.e. get metadata operation), then only lookup a percentage. (Write operations are more expensive anyway, so an extra SELECT won't hurt). (I haven't checked to see if WordPress already looks up the post type anyway - perhaps it does).

• When someone is on the dashboard, on WooCommerce pages, look in the DB for the existence of any recent stack traces. If there are some, then a notice, showing the names of the responsible plugins (which you can get via the stack trace, which allows you to get the file, which you can then translate into a plugin name). Allow the user also to download the stack trace data for that plugin so that it can be shared with a developer.
  You could also add a "Site Health" item using relevant hooks.

• You'll also want a cron job to clean-up old stack traces so that the database doesn't fill up.

The above suggestion implies that it'd be best to introduce a new table with fields for time (of most recent stack trace), number of occurrences (of that stack trace) and the stack trace itself, to store this data.

The above just deals with postmeta, going through the WP postmeta API. Of course, plugins might also operate on the posts table. But surely if they are going directly to the DB, then they'll touch postmeta at some point - it'd be very unlikely that they use the WP API for the post object, but the WC API for the postmeta one. And of course, in theory they might also be doing the WPDB::query() calls directly and skipping the postmeta API too. But this is also pretty unlikely. And the above scheme could also be extended to trap those via the query filter. But that may be getting excessive. It's hard to imagine coders who prefer direct SQL (except for ones who are doing mass-gathering of data for analytics, but such people are likely to be keeping a close eye on the database schema if their plugins are still maintained).

[masteradhoc]

FYI: https://developer.woocommerce.com/2022/01/17/the-plan-for-the-woocommerce-custom-order-table/
Keep up the good start @vedanshujain !

[smgdarien]

Great to see this getting attention!

[jurijc]

Hello, great news!
I would like to add some feedback to structure

It would be good to add to the order table - billing phone

1. it will be faster to find orders by phone.
2. there are implementations where email is empty, it can be done as optional field on checkout.
3. probably depends on country, but phone can be much more important than email, becoming main way to identity customer and look for orders.

[feastdesignco]

Just a request before you push even the first version of this live - please ensure total compatibility with your own subscriptions and memberships add-ons.

[feastdesignco]

As we can see The only real store which use woocommerce and rank under top 20000 alexa rank, only woocommerce.com. We keep losing our "big clients" to our competitors.

As someone who moved over to Shopify Plus a few years ago from a non-Wordpress platform (ZenCart), the reason we opted for it is because they have much tighter integrations with key ecom needs. Reports are all built right in. Many integrations are built into the platform rather than being nickel and dimed. The end-user experience (the people processing the orders) is simply more refined, and this is where the clients spend 90% of their time.

Yes, there are still third party apps, and custom development needed.

You just get more bang for your buck out of the gate.

But if you're doing millions per year, $24,000/year for Shopify+ is a rounding error and more than compensates for even just not having to manage hosting.

Going with custom order tables is laudable, but it wouldn't have made any impact on our decision and very few other companies I've spoken to at ecom conferences.

One other key benefits to Shopify is the significantly reduced rate of breaking changes. If developers and clients find this update difficult then there will be even more draw to Shopify. IMO spend 2x as long on QA and testing and automated migrations than actual development (eg. see request above for subscriptions+membership seamless migration).

The current messaging and documentation I'm seeing reads like "well here's the guidelines for the plugins but we're not really concerned if they break": https://developer.woocommerce.com/2022/01/17/the-plan-for-the-woocommerce-custom-order-table/

Listing the extensions/plugins that are compatible will go a long way.

If you have to, contact a few key clients and hand-hold them through the migration process at no cost so that you can see what they encounter in the real world.

Edit: I also wouldn't use Alexa rank for this purpose. Ecom stores don't necessarily get a lot of TRAFFIC because purchase intent keywords have much lower volumes than information intent keywords. You can't glean conversion rate, average order value, profit margin or even social or email conversions off this. Totally unrelated. You can have an ecom store getting 1,000,000 visits per month doing $100 per year, or the same store doing $10,000,000 per year.

IMO the much larger opportunity here is FBA businesses that don't even have a store and are at huge risk of being wiped out by Amazon. They're not building on woocommerce because its too complicated and they don't have the ability to acquire customers. Build in best practices for conversion optimization. Make the work flow as simple and close to Amazons as possible. Make it easier for them to attract customers.

You're fighting with Shopify over 10% market share for a few clients when you should be focusing on how to get the other 90% of the pie, and growing the pie 200% by making things easier.

[glagonikas]

@feastdesignco I'll have to disagree with a few of your points, because Shopify comes with hidden costs and/or limitations that simply increase the cost.

The price of $24k is for their starting package of Shopify+ and states

The Shopify Plus plan starts at $2,000 USD a month for standard setups and integrations. For more complex, higher-volume business structures, our variable fee option flexes with your requirements.

For a website like ours that needs to support 20k+ orders in 10-20mins (during peak times) and contains over a million orders, Shopify wouldn't come that cheap.

On top of those, we use Subscriptions, Composite Products, Product Bundles and Composite/Bundle subscriptions which don't come as standard on Shopify. There are plugins that can do some of those (for example Recharge) but they have a fee (higher than the equivalent WC one) and some (like Recharge) also have a per-transaction fee.

Additionally, (correct me if I'm wrong) Shopify doesn't make it easy to change payment gateways and you have to pay a per-transaction fee, which is on top of the Recharge fee?

I know there are bigger stores than us in WC but I doubt you'll find thousands at this size. I also understand WC needs to target the smaller stores to remain profitable, BUT how do you promote trust to the WC brand if you don't have big brands using it? Why would a small store owner (who frankly doesn't know and doesn't care about coding and optimisations) go for WC when all his competitors run on Shopify?

As it stands, I'm having to defend our decision to build the site on WC originally and keep using it. It has served us good so far, but we had a lot of blood sweat and tears, even at early stages, because of bad performance. It's not acceptable to have to pay thousands on hosting per month to support a busy e-commerce site.

With the right table structure, you can achieve this with much fewer resources and I'm pretty sure Shopify has a much better structure.

I agree with you that they should be making things easier for the smaller companies, but I think that's where they are headed anyway? You buy a hosting package that comes with WP/WC, Gutenberg is vastly improved over the past few years, Full Site Editing has just launched, WC is working to fully support GB, so it seems to be getting easier already. Why not finally improve the bad foundations and try to win back people?

p.s. Over the past few years, I've not come across any breaking changes with the plugins we use. All updates worked flawlessly (for us). The bugs we encounter come from third-party plugins (not maintained by WC) but I'd assume custom Shopify plugins might break too?

This change is meant to be made as an opt-in initially, followed by opt-out, whilst keeping the tables running side by side for a while. I think this is the best approach and should give plugin developers plenty of time to update their code, so most stores won't be affected. Stores with custom plugins using wp-posts might have some issues, but it will probably be over a year before they see a breaking change and they'll likely have plenty of warnings before then.

[vedanshujain]

It would be good to add to the order table - billing phone

@jurijc I replied to your comment on the blog post, but for completeness, IMO adding billing phone as one of the primary identifiers would be more work than just adding a column. Therefore, we should take it up as a separate project sometime down the line rather than picking it up with this one. wdyt?

Just a request before you push even the first version of this live - please ensure total compatibility with your own subscriptions and memberships add-ons.

We plan to ensure compatibility at least with popular extensions irrespective of whether it's owned by WooCommerce. This is something we have been focussing on for some time now, where we would make sure that new features are compatible with extensions and do not cause disruptions.

@feastdesignco I appreciate the candid feedback, and while I am glad that Shopify is working out for you, don't be surprised if you find yourself switching to WooCommerce very soon. You, me, and all of us are here for our combined love of everything open source, and I have no doubt we are building the best commerce experience one can have, open-source or not.

We are still early in the project and doing the research work, but most concerns you listed are already being (or should be) addressed. We realize the complexity of this project, but we aim to complete this without disruptions by building whatever user journey paths that would allow us to do this.

[jurijc]

@vedanshujain thank you for feedback. I understand your plan make as less changes as possible in structure.

In the same time it's good starting point to see where it will be going and take some things now into account because later it would be to much work to do to alter again (and it will not happen probably - it's reality).

Regarding access to phone and email from blog post I think it's equal.
For more people smartphone is becoming the only computer ever used and not everybody utilize emails on them but phone, browser and social - always.

Why I am proposing on including phone in order table, because it's one of main ways to identity customer, searching orders by phone is natural ( for example when you got a call from client: what is easier? search by this phone or ask "what is your email, can you spell it? ), or search all orders by phone ( there are a lot of cases when person uses different email and then have few accounts and usually only 1 phone) = that can be used to connecting order to one user profile (now it's not out of box).

And guest order, or when you got order by customer calling shop, why do you need to ask email at all?) a lot of businesses receive calls and sometimes orders on phone.

And also you can grab phone for any automation to send sms, and it will be there in one table.

Real life cases and future use cases should shape DB.

Maybe for starting point just including it as regular field, not as an index, is a way not to loose this and don't make it hard. One important field will not hurt but can be very useful.

[peterfabian]

@feastdesignco
Thanks for sharing your perspective, you raised a lot of valid points. I'd just like to add to what @vedanshujain said above that custom tables for orders is one project of the core team, there are other teams that work hard on improving and simplifying the store management experience and one does not exclude the other. I see it actually as quite the opposite: if we provide a solid foundation for working with order data storage, that opens much more opportunities for UX improvements built on top of that (search, archiving, bulk updates, etc).

[kdamsmt]

Planing: https://developer.woocommerce.com/2022/01/17/the-plan-for-the-woocommerce-custom-order-table/

[beaulebens]

HPOS was made available as part of WC 7.1 - https://developer.woocommerce.com/2022/11/08/woocommerce-7-1-0-released/