ClassicCommerce v2

Considering the changes with Classic Press v2 and the compatibility issues of Classic Commerce v1, I perceive a looming need for CCv2. I know some others have looked into this and started down this road, and after some private discussions I think there is an opportunity to move forward as community on this front. As such there are some things to consider and evaluate with each of the options in front of us.

  1. Re-Fork Woo-Current
  2. Re-Fork Woo-Previous
  3. Fork a different eCommerce solution
  4. Migrate CCv1 to current
  5. Complete Rewrite

From php/sql developers, I’d like to hear individual opinions on the pros/cons from you about feasibility, time, and the community about the options provided.

From website admins, I’d like to know what features are absolutely necessary for you to embrace a CPv2 specific eCommerce solution. I’ll start the list with things on my mind:

  • ClassicPress v2 Compatibility
  • ClassicSEO v2 Integrations
  • Woo data import

Also, if you are interested in helping to develop or support a lasting community solution, please reach out to me. PMs are welcome from all, and thank-you for your responses ahead of time.


I’ll reply with my perspective when I’m at my desk, but I wanted to tag a few folks I know use CC to get their thoughts.


And maybe @ozfiddler still lurks around :slightly_smiling_face:

I will also promote this thread through CP’s social media channels.


Current woo has a terrible dashboard.
Current ClassicPress is perfect, so just modernizing would have my vote.
Easily done too for someone knowledgable with the code as it works mostly issue free now.

Don’t fix what isn’t broken…

If current woo is forked to CC2 I won’t update to to it as I truly definitely and strongly hate the dashboard and analytics crap WC has. I switched to CC for a reason… Simplicity and liking the dashboard.


Sorry, I’m not a CC user. Attempted it once and ran into an issue I no longer recall; ended up implementing WP EasyCart, which works very well with CP1.x (have not tested with CP2).


I’ll take a look at it. Besides working with CPv1, anything that you really like or dislike about it?


I am a very junior dev and a user.
First of all: CC is great but…
It’s a race to stay current with backports and avoiding GB stuff IMHO.

In case of a re-fork I suggest starting over with the latest release of woo, clean it up again. But it will need polifills and compatibility plugins to work with extensions and CP unless it’s decided that we make it a CP plugin and we develop it on our own, making our extensions for it and the like.

Another plugin that I discovered the one by Implecode that I tested a while back. It is a complete solution, at the time they said they had no plans to remove the Classic Editor stuff so it works well with CP. They did not commit to supporting CP however.

We can talk about re-forking, using something that works or asking ourselves: are we ready to really fork and support it on our own developing it in a way it works in CP or do we fork it and continue to patch it everytime it doesn’t work because blocks or just keep it frozen?

If we fork to make it a CP plugin I am in, whatever you fork, I can test and translate.

To be considered that the majority of people that will likely be able to help are also the ones that belong to core team, and with V2 endeavour in progress we should be careful not to put too much on their plate. V2 is a big thing per se.

1 Like

Just a few things to consider;

If nothing else and it has to be a refork. Pick the last version before they forced the terrible new dashboard on people. That’s the one before 5.0 or somewhere in that area if I remember correctly.
If people want analytics and more of such things that can (and should be) a separate plugin.

For a time the new dashboard could be disabled with a single line of code. A separation can be made there, keeping the old dashboard with a hook that if the ‘analytics dash plugin’ is active it overrules the default or something. That’ll please everyone.

Also consider that Woo seemingly no longer includes proper payment gateways out of the box and everything is handled modularly. While this is fine in a simple sense as in ‘why bundle paypal if you’re not gonna use it’ kinda way the replacement of those default gateways is NOT a good alternative from what I’ve seen and found out with upset users in the past year.
Either it only works in the US or it doesn’t work at all, requiring needless 3rd party services and connections. WooCommerce Payments or something? Not a fan… Alternative plugins of other devs? Often low quality or worse, subscription based. Also bad.

I briefly tested CC on PHP 8.1.something and my dev localhost uses 8.0.something and that seems to work fine. So not much work or forking needs to be done to modernize the current code it anything at all for the time being.

That said, I didn’t try WooCommerce lately and I don’t really know the current state of affairs. But seeing the route Automattic and Woo seems to take lately I doubt things have changed for the better.


Current version of WooCommerce don’t work with ClassicPress v.2.

Don’t think forking version 7 and make it work with ClassicPress is a viable option, as latest version of WC is using a lot of JavaScript libraries from WP, that we have removed from CP.
If someone is going to refork WC, she must decide which old version to pick and do a pretty big job to fix that version to support modern versions of PHP. Think version 4 is the last without that many libraries.

At the moment I have mainly sites in catalog mode, and I’m happy with Classic Commerce and CP v.1.
I’ve also two sites with WC and WP at the latest version, because at the moment this is the only viable option to keep WC updated and working.

1 Like

Like Woo, it’s probably more complex than it needs to be. But it seems solid.

1 Like

Rewrite? Sounds a bit insane to me, WooCommerce is quite the complex beast.
Forking something else: Maybe Jigoshop? Its the ancestor of WooCommerce, after all.

Refork from a different version of WooCommerce: At least 3.9.x, because else its useless for Europe (most country-tailored legal support plugins, eg. German Market, Germanized for WooCommerce / WooCommerce Germanized, etc. DO NOT WORK with anything before 3.9.x, because of the rearranged taxation “framework”).

That is also the reason why I did my “personal” / small-time fork - compatiblity to essential plugins (you certainly are able to build a shop in any European country WITHOUT them, but its MUCH MORE effort, esp. in terms of law and legal matters).

At some point in the next 2 weeks I’m at least gonna do a coordinated test with CP v2 and several versions of WC, starting from the 3.9.x, which was still gutenborg- and rotpack-free (mostly), and then working my way up until it breaks.

cu, w0lf.


The core team would not lead CC development, only helping as needed. Shimmy would lead development.

WC v5.0 deprecated legacy reports. So that might be the cut-off.

With CP v2.0, we didn’t take WP v6.2 and rip out blocks, FSE, and React. @MattyRob merged develop branch with CP v1, and worked his way through all the files to resolve merge conflicts. That was a lot of work, and he did a great job. WC and CC are plugins, so I assume they have fewer files than WP/CP core.

This type of “merge-fork” could be a viable option for CC to save time and effort. Matt might be able to provide some tips and tricks for doing this type of re-fork.

When it comes to the actual e-commerce plugin, the three most important things to keep in mind:

  • Payment gateways. PayPal and Stripe would have to be available and functional at the minimum.
  • Accessibility. WP ignores accessibility, partially due to accessibility issues in React. CP doesn’t have React, so we’re already doing better on the accessibility than WP.
  • Privacy. Not just legal obligations but also not forcing users to sign up for accounts and share their data in exchange for services. What WC does with their nonsense.

Whatever approach is taken, it’s best to focus on getting the most bang for your time invested. We will all help as much as possible to ensure Classic Commerce can thrive again. A privacy-focused and lightweight e-commerce solution is needed.

Side note: While the core CC is free, I encourage plugin developers to consider developing paid plugins for CC to ensure they get paid for their time and effort. It only strengthens CP and CC knowing premium, supported plugins are available. For e-commerce, the two profitable (and critically important) categories of plugins are payment gateways and shipping integrations.


I think I will see if the Implecode plugin works with v2, then we have another alternative to try to use (since they stated that classic editor code won’t be removed at the time we can take an older version keeping the classic editor code and stripping blocks and then go from there, it is a complete solution as far as I remember).

I will have more time in the coming weeks to do so (will test the v2 multisite with and without dir plugin also) and report what I find.

1 Like

And I was very curious, I prepared a CP v2 and installed the Implecode plugin.

It WORKS nicely. very very…

It can do enquiries, catalogue, shop with all the needed things and has an ecosystem of free/paid extensions by Implecode.

I have tried in the past to ask them to publicly support CP and got the “we won’t remove classic editor from its code, so it should continue to work” - should we try again to see if they agree to have it in our directory now that we are very near to releasing the plugin that brings it in core?

modernizing to include updates for CP2

Dependencies are always bad to rely on (updates and all) Maybe eliminate JS that is not crucial (UI etc) and keep to minimum.

Good statement… making simple(er) would allow others to create addon plugins to compensate for simplicity “out-of-box”

Thanks for the mention @viktor - I appreciate it.

I think I am only using CC now on one site and that is a catalog-style display (running on WP). I certainly wouldn’t use it for anything with a payment gateway as it hasn’t been supported for quite a while now and I no longer trust it.

I would certainly not recommend forking the current WC version. It is now a bloated, slow mess of a program and I agree 100% with this…

But I really just came here to point out that the OP has missed one other option…

  1. Do nothing

I have now moved all of my ecommerce sites over to an external solution - Ecwid.

I also looked at Snipcart, but Ecwid has a free plan for 10 or less products and all of my clients were small-time sellers and this was a neat way to handle their sales. I have very happily rid myself of WooCommerce completely. Ecwid is now doing a great job of handling their ecommerce requirements.

So, my main point (yet again) is that CP contributors might want to think about focusing their limited resources. Trying to get a new dedicated ecommerce solution going is a huge undertaking (I know!). Is it really necessary, when there are good external options already available?


Thanks for stopping by. We have a developer interested in possibly maintaining CC, so we’re exploring possible paths forward.

Okay, we are getting somewhere! Great responses so far.

I will address the most recent post first and work back as I have comments/thoughts/questions. Forgive me as I group them for my own coherency.

I’m guessing you know what they say about “assumptions”, standby. I didn’t miss the option that you proposed, if that was an option for me then why would I have “done something” and posted? Seems like a bit of flawed logic. My version of “Do nothing” as you put it, is probably much different than what you meant; more on that later. From my perspective you answered that option for yourself.

Viktor thanks, but that’s a somewhat misleading; not that you could have known.

Oz, because it’s prudent to this conversation. It will provide a more accurate version of Viktor’s statement which should read something like,

“We have a business owner (that employs/contracts other IT professional) and developer, who is considering investing his companies resources into this project. Most importantly, he’s willing to make this investment without RHELie dangerous consequences to the community.”

That’d be more accurate. Back to the discussion:

I will allow you to answer you.

I’m curious, if CC had met your requirements, would you have migrated away? I suspect from what I know of you, that you would prefer to “Do nothing”. You argue to do nothing, but yet you did something, you migrated to another solution, at first blush that seems a bit hypocritical, but upon further consideration, I can stipulate that emotionally it felt like you were “doing nothing.”

From, my emotional perspective “do nothing” means building out a proprietary solution that I want for my company. Here’s the thing, I don’t need to own CCv2 to get what I want, in the mean time I can support the community (PR loves this) and perhaps meet some new talent(HR loves this). Marketing is eager to make the claim that we did what other said was,

From a business perspective “doing something” makes sense to me. Thank-you for you thoughts and your contribution.


I think we are in agreement, but I have thoughts about some options. Not of them have to do with UI.


This is Viable. IMO, as of PHP8.0 and it’s new shiny JIT engine, there is less need from a UX perspective to rely so heavily on JS.


If @ElisabettaCarrara and @fwolf worked together, perhaps you both save time, learn from each other, and as a result you will have a more comprehensive report for your individual tests. Let me know what I can do to support your efforts. I am eager for the results.

1 Like

I see no need too. But it might be prudent from a business perspective for them once this project is underway. Competition Creates First Place.

1 Like