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.