ClassicPress Community Considers Re-forking WooCommerce for Classic Commerce v2

ClassicPress, the fork that has been keeping WordPress 4.9 on life support for those who don’t want to use the block editor, will soon be moving into version 2.0 after the community voted to re-fork a newer version of WordPress (6.x) to keep moving forward. Version 1.6.0 was released a few weeks ago as the last minor release before version 2.0.

ClassicPress contributors are discussing the future of Classic Commerce, which is a fork of WooCommerce 3.5.3 created to provide a reliable e-commerce solution for ClassicPress users. The community is now bracing for the inevitable compatibility issues introduced by version 2.0 that will require a massive undertaking to resolve.

In a forum thread seeking community input, @shimmy, an IT solutions business owner with an interest in supporting a long term e-commerce solution, proposed the following options for Classic Commerce’s future:

  • Re-Fork Woo-Current
  • Re-Fork Woo-Previous
  • Fork a different eCommerce solution
  • Migrate CCv1 to current
  • Complete Rewrite

“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 ClassicPress or do we fork it and continue to patch it every time it doesn’t work because blocks or just keep it frozen?” Elisabetta Carrara said.

After some discussion multiple participants in the conversation were in agreement that forking the latest version of WooCommerce to make it work with ClassicPress is not a viable option.

ClassicPress director Viktor Nagornyy suggested exploring a refork similar to the method used for ClassicPress 2.0.

“With CP v2.0, we didn’t take WP v6.2 and rip out blocks, FSE, and React,” he said. “@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. WooCommerce and Classic Commerce 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.”

@shimmy, who would be leading this effort, said he is leaning toward this approach.

“I think this provides a more natural upgrade path and to some degree backwards compatibility,” he said. “At some point in the course of merge-fork WC plugins will no longer be compatible with CC; which is fine because I think that CC should have it’s own plugin ‘bazaar.’ This ensures compatibility with CC; if you need a feature then it should be a filtered result with what you already have in place.”

Nagornyy also encouraged a nascent plugin ecosystem to grow up around these forks to provide additional features. Although the WooCommerce plugin ecosystem has thousands of options for extending stores, they are not guaranteed to be compatible with forks built on older versions of WordPress and WooCommerce.

“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,” Nagornyy said. “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.”

With the major changes coming to the WordPress admin in Phase 3 of the Gutenberg project, maintaining these forks will continue to be an uphill slog, as fewer plugins from the wider ecosystem will remain compatible with ClassicPress.

Maintaining payment gateways and shipping integrations for compatibility with these forks is also going to be challenging, as this discussion indicates that the community doesn’t have many experienced e-commerce developers who are eager to step up and donate their time to this project. If Classic Commerce cannot deliver on the ambitious ‘merge-fork’ option, users may need to look towards integrating external e-commerce solutions.


5 responses to “ClassicPress Community Considers Re-forking WooCommerce for Classic Commerce v2”

  1. “With the major changes coming to the WordPress admin in Phase 3 of the Gutenberg project, maintaining these forks will continue to be an uphill slog, as fewer plugins from the wider ecosystem will remain compatible with ClassicPress.”

    It doesn’t matter, newer plugins will be added to the ClassicPress plugin repository. They will be rebuilt in no time.

  2. It’s a good article covering our discussion, but it’s missing one part: context.

    Why would anyone want to fork WC? Here’s what users said in that same discussion:

    “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… I truly definitely and strongly hate the dashboard and analytics crap WC has”

    “Like Woo, it’s probably more complex than it needs to be.”

    “I would certainly not recommend forking the current WC version. It is now a bloated, slow mess of a program.”

    This is only from the current discussion. More was said when the original fork happened a few years ago.

    WordPress is a fork. WooCommerce is a fork. Forks exist because users want something different from the original project. That’s the beauty of open source.

    ClassicPress and Classic Commerce are not out to compete with WordPress and WooCommerce. They exist to give users something different that matches their needs better than WP/WC.

    Something privacy-focused, so their data isn’t shared or they are being tracked.

    Something accessible, so users with disabilities can use it.

    Something lightweight and performant without all the React/JS.

    There’s a reason people still don’t like Gutenberg/block editor and now FSE. I see them complain on social media every day.

    WordPress/WooCommerce way isn’t the only way forward.

    • Thank you. The block editor and FSE do not take into consideration the various users of WordPress. I am a developer, but my clients aren’t. They don’t need FSE access, and the block editor is crazy clunky and overly confusing. I would never hand a client a website built in blocks. They would be overwhelmed. I use a page builder like WP Bakery or SiteOrigin that is easy to use and understand. I don’t even know who FSE is being developed for. Why would I or my client need to edit a header or footer while viewing the page content? I don’t want my clients to see any settings. How are roles taken into consideration? I’m starting to freak out about not having access to classic features that make WordPress a clean, easy-to-use interface for my clients. My clients are small business owners and not always tech-savvy. They need a solution that works for them. I care equally about how easy it is for me to build and how easy it will be for them to update.

  3. As long as the Classic Editor and Classic Widgets plugin are working I’m using them on most of my sites. I think there will always be a “classic” way to add content/widgets, because of the popularity of both plugins. Cannot imagine all those users will adopt the block editor at some point.

    • I agree with you Guido, but that may be wishful thinking. It sounded like that option was going to be taken away at some point. And that is why non-technical users switched to ClassicPress.

      If they had any intention of keeping the Classic Editor available, it sure didn’t sound like it to me.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: