Disappointing support from WooThemes

Makalu was recently hired to redesign an e-commerce site running on WordPress, and implementing its shop using the WooCommerce system.

To begin the process, we mirrored the production site to a staging server, and over the course of a week or so redesigned the site using a new theming framework. The customer approved the new design, giving us the green light to launch. Unfortunately, launching wasn’t as simple as flipping a switch.

The problem was that while we were working on the redesign, the production site’s WooCommerce data progressed with respect to the data on the staging site—i.e. some new orders came in, and several of monthly subscriptions renewed. So before launching the redesigned site, we needed a way to selectively update the staging site with just the WooCommerce data from the production site.

But the problem with that is that Woo orders, being just another “content type” in WordPress, are found in the WordPress “Posts” table, and live alongside the short-code based definition of the site’s web pages—meaning that if we copied over the entirety of the Posts table from Production to Staging, we’d lose all of our redesign work! (The architecture of WordPress is so brittle in that regard, but that’s the subject of another post.)

I decided to contact WooThemes support, and after 10 days have gotten nowhere, as you’ll see below.

Here’s the question I posted on March 4th:

Four days later, Constantin Schneider replied, explaining that an FTP client is needed to synchronize files and a database plugin needed to synchronize the database:

So Constantin answered a question I didn’t ask—i.e. how do you completely mirror one WordPress site to another. So I reminded him that I’m asking specifically how to move just WooCommerce data:

Two days later, I got a follow-up reply from Constantin saying he did understand my question, and that I should migrate only the tables containing Woo data. To help with that, he linked to a document which basically lists all tables prefixed with “woocommerce” as belonging to WooCommerce.

Of course, this completely ignores the point I raised about Woo orders being located in the Posts table, and therefore mixed in with the site’s layout information. The needed update isn’t as simple as moving the WooCommerce tables.

So I replied, pointing that out:

Four days later, Mindy Postoff replies, that yes, the Woo orders data does live in the Posts table:

Heavy sigh. Evidently, she didn’t take the time to read the thread’s history; otherwise, she would have known that by answering “yes” to that questions, that my original question remains completely unanswered!

So here we are, 10 days after my original post, and we have no progress at all. This is what happens, I guess, when your support staff try to blow through a backlog of requests at the speed of light. People don’t take the time to understand what the customer is actually asking, nor do they take the time to understand the background context of a thread they’re jumping into the middle of.

So disappointing. Thanks Woo.

Update: Woo makes things right

I notified Woo about this blog article, and credit where credit is due, they responded by acknowledging the deficiency in the process, apologizing for it, and taking some actions that went above and beyond what would be necessary to make things right. Hopefully this experience will allow Woo to re-consider how support is handled (which these days isn’t just a challenge for Woo, but all providers trying to figure out how to scale support), but thanks and hats off to Mindy Postoff for her response, and I’m again a happy Woo customer.

Update 2: How we ultimately did the migration

Ah, for those of you stumbling across this article, and interested in how we finally migrated the data: Unfortunately, even with the extensions offered by Mindy as part of their effort to help, it turns out there simply does not exist a straightforward way to migrate only the WooCommerce data from one site to another. This is almost shockingly surprising, since one can only imagine that an occasional re-design would exist as part of the lifecycle of any WooCommerce-based site.

In the end, though, we had to actually take the production site offline, while we manually re-built it according to the work we did on staging. In our case, this was possible because of two things:

1. The new site is built using Divi, which provides a mechanism to export saved layouts, and then import them in another site. Not quite as convenient as something like "export this whole theme setup", but certainly better than having to manually re-build each page in Production. So the way this worked was, I exported a saved layout for each page in the site, and then imported that layout into the corresponding page on the Production site.
2. Our customer's site only has about 10 pages in total, and so it only took us about an hour (during which the site was offline) to completely rebuild it.

Enjoy this article? — You can find similar content via the category and tag links below.

• Categories — Rants
• Tags — WordPress

Questions or comments? — Feel free to email me using the contact form below, or reach out on Twitter.