Migrating from WooCommerce to Classic Commerce

WooCommerce 4.0 Changelog

  • Enhancement - Included information about packages in the System Status Report. #25584
  • Enhancement - New WooCommerce Admin. #25011
  • Enhancement - Update dependency woocommerce/woocommerce-blocks to v2.5.12 #25587
  • Enhancement - Updated Action Scheduler to 3.0.1. #25566
  • Dev – Added support for placeholder attribute in quantity inputs. #25418
  • Dev – Added tax_status and tax_class columns to the product meta data lookup table. #25428
  • Dev – Introduced woocommerce_top_rated_widget_args filter. #25320
  • Dev – Introduced woocommerce_admin_process_variation_object hook. #24929
  • Dev – Added actions before and after grouped product list to allow adding custom rows. #25093
  • Dev – Added filter to tweak whether a product has enough stock while attempting to pay for an order. #25230
  • Dev – Added the automattic/jetpack-constants package and replace PHP constant definition checks with it. #25516
  • Dev – Added a triggerHandler called checkout_place_order_success on a successful order during the checkout process. #25289
  • Dev – Allow filtering of default meta value inside WC_Data::get_meta even if meta key not found. #24066
  • Dev – Includes Emogrifier composer package instead of including into includes/libraries . #25525
  • Dev – Introduce WC_Countries::get_vat_countries for returning a list of countries that uses VAT and refactor WC_Countries::get_european_union_countries with backward compatibility and deprecation to remove the VAT functionality from there. Brexit, remove GB from WC_Countries::get_european_union_countries . #24943
  • Dev – Introduced woocommerce_download_product_filepath filter. #25485
  • Dev – Introduced woocommerce_email_content_type filter. #25405
  • Dev – Updated woocommerce_email_from_name and woocommerce_email_from_address filter arguments to include wp_email() default data. #25405
  • Dev – Introduced woocommerce_shortcode_products_query_results filter. #25573
  • Dev – Removed hash_equals() polyfill as it was no longer needed. #25474
  • Dev – Removed unused .order-actions CSS. #25581
1 Like

Yeah, that filter disables the new analytics and marketing features. It seems crazy you can’t disable this from WC settings. Plus, because the filter is called before the theme is loaded, you have to create a separate plugin with just that bit of code in. Adding it to functions.php won’t work. Apparently…

1 Like

Yes, this is the case. No good in functions.php. No good in a snippet plugin. Has to be in its own separate plugin. :roll_eyes:

2 Likes

I’m sure it was calculated. That code also hides the new top level “Marketing” menu item which looks like a place purely for pushing Woo commercial products.They don’t want to make it too easy for you to hide that little gold mine.

4 Likes

I’m not using a commerce plugin at this time, but, just wanted to say that I greatly appreciate all the time, effort, research, discussion (and so much more) that you’ve all put into the project. Really great work!

7 Likes

Just to summarise what I have found so far… there are four main areas of change to the database in WooCommerce 4.x

  1. New tables created for the action scheduler.
    actionscheduler_actions
    actionscheduler_claims
    actionscheduler_groups
    actionscheduler_logs
    Note that plugins (eg WooCommerce Subscriptions) may start to make use of these tables for their procedures.

  2. New tables created for the WooCommerce Admin reporting features
    wc_admin_note_actions
    wc_admin_notes
    wc_category_lookup
    wc_customer_lookup
    wc_order_coupon_lookup
    wc_order_product_lookup
    wp_wc_order_stats
    wc_order_tax_lookup

  3. A new table created for handling reserved stock (managing stock levels for items that may be currently in the checkout process) - wc_reserved_stock
    More details here: Reserved Stock in WooCommerce 4.3 Explained | Puri.io

  4. A change to an existing table - wc_product_meta_lookup
    This has 2 new columns added - tax_status and tax_class
    See: Add product lookup table tax columns by mikejolley · Pull Request #25428 · woocommerce/woocommerce · GitHub
    It also has a change to two existing column definitions
    min_price decimal(10,2) DEFAULT NULL and max_price decimal(10,2) DEFAULT NULL
    becomes
    min_price decimal(19,4) DEFAULT NULL and max_price decimal(19,4) DEFAULT NULL
    See: Need to change `wc_product_meta_lookup` table structure datatype size for min_price and max_price · Issue #24428 · woocommerce/woocommerce · GitHub

6 Likes

@Web242 - Are you going to be migrating from WooCommerce to CC, or starting from scratch. If you are migrating, what version of WC are you currently using?

1 Like

Hi @ozfiddler I would defintely prefer to migrate, in order to retain customer orders and information. But it’s not the end of the world if I redo.

WC Version 4.4.1

My plan is to simplify everything, so we’ll get rid of the subscriptions etc. and just keep simple orders and existing products.

1 Like

OK, then you’ll be wanting to follow this discussion: Migrating from WooCommerce to Classic Commerce

and also the CC channel on Slack. I’m trying to get my head around it all at the moment.

Simplify is good! :smiley:

1 Like

@ozfiddler Yeah I hear you! WordCommerce is complicated enough. I suspect most of the new stuff, is for their marketing addons and Gutenberg blocks. I suspect there are not huge changes to the db tables/schema - but there have been db updates on WC upgrades.

I’ll go check out your post!

1 Like

@ozfiddler What is the Slack channel?

I think that gets there. It’s classic-commerce in the CP slack account.

From what we’ve seen so far, this is correct.

It looks to me like any real problems would most likely come into play only if you migrate Woo → CC then upgrade back to latest Woo. However in the interest of full disclosure this process does need more testing.

Slack (also linked to from the bottom of this page, or on our main site)

Please be sure to use that link when inviting people to Slack, since that’s pretty much the only way to guarantee that users who don’t yet have an account will be able to create one.

1 Like

@james and @ozfiddler This is an important discussion on ClassicCommerce. Let’s split this into another topic from:
https://forums.classicpress.net/t/looking-to-make-the-switch/2438/10?u=web242

I’m not a developer, but we have quite a few clients using WooCommerce now, and I feel every-time we update we are going down the path of no return.

I hope you can keep the migration from WC to CC for some time, but I also worry once it goes into “block-mode” it’s game over. I don’t think I will ever roll-back.

Yes, I know what you mean. I have the same feeling with my two remaining Woo sites. I was relieved to find that the database changes wouldn’t affect my sites, but this is something you need to assess for yourself. Creating new tables wasn’t really a concern, but when they start modifying existing tables it could start to impact us.

I hope so too. We’ll certainly be working on this.

What are their situations regarding plugin and extension usage? This will obviously be the main area to watch. It will be the same story as CP… as long as plugins work with WC version 3.5.3, they should work with CC. But I would be avoiding any official WooCommerce products. :slightly_smiling_face:

1 Like

Well therein lays the problem. My clients and I are using official WC plugins. For them they will have to stay with WP and WC, I dont see any other choice. Unless they reach the point of frustration with it all.

But to answer your question, WooCommerce Subscriptions is the most important one, and with Stripe gateway. If CC could have subscriptions option, even rudimentary, that would be very good.

The way I see it, if I build a CP and CC site from the start, it’s a non-issue.

I think it wont be long before WC and WP become divergent from, CC and CP. I dont think you have to sweat supporting WC plugins - that is too much to ask.

What you have done, is given CP users a solid eCommerce option with CC.

2 Likes

Scrap that… seems like the plugin I was going to recommend has moved to WP5+

2 Likes

It means, that

  1. You should ask plugin developers to support CP.

  2. If rejected - fork the plugin or put it on the “WP plugins should be ported to CP” list and wait, until someone wants to take care of it.

Oh, wait. We don’t have a “WP plugins should be ported to CP” list? A major lapse. It raises the question of where and how it should be created and how promoted to the potential plugin developers.

1 Like

Business opportunity here: an agency with specific experience in WP → CP migrations. Sounds like a good one :wink:

1 Like

@james I like that idea!

1 Like