Tag: classicpress

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.

In December 2022, the ClassicPress community voted on whether to re-fork WordPress or continue on with the project as-is. As WordPress continues to evolve, ClassicPress fell behind in pursuit of PHP 8+ compatibility. The fork is based on WordPress 4.9 and users are increasingly limited in what plugins will work with the five-year-old codebase.

In a discussion limited to ClassicPress core contributors, Viktor Nagornyy, one of the project’s directors, announced the results of the vote: “The option to re-fork has 20 votes while continue-as-is has 18.” Nagornyy summarized previous discussions and suggested an approach that would be more realistic for the project’s limited contributors:

ClassicPress can’t be WordPress without Gutenberg, but it also can’t be its own CMS with a small core team at this time. There are simply not enough developers to make progress without backporting code from WP to move away from WP.

An almost even split in the poll suggests the best option might be a hybrid one, find a compromise solution that will satisfy both sides.

With a small core team, we have to find ways to be more efficient, to get more done with less. The only way to do that is to leverage all the work that’s done by WP contributors. As the core team grows, we can always explore the possibility of splitting away from WP but at this point in time, it’s simply not feasible.

Some participants in the previous discussion saw re-forking as postponing the inevitable, kicking the can down the road until the next re-fork, but it is the only option if users want to retain compatibility with the rest of the WordPress ecosystem.

“If you read recent threads, you find out that the community expects plugin compatibility with WordPress… another reason for the re-fork option,” ClassicPress core committer Álvaro Franz said.

Franz, who is also the author of the WP-CMS fork based on WordPress 6.0, previously said he would be unwilling to help with a continuation of the current version based on WordPress 4.9.

“It [ClassicPress] doesn’t have to be a competition (and it never could compete with WordPress anyways), but it can be a leaner version, for people who are already disabling Gutenberg via plugins, for developers who want a different approach to the way they develop their projects (closer to ‘the classic’ experience, but yet… modern!),” Franz said.

“Eventually, it won’t make sense to run a fresh copy of WordPress to then go and install a plugin that ‘disables’ half of it. What’s the point? Why not have a version that covers that specific use case?”

As part of Nagornyy’s proposed hybrid approach, he suggested the project retain some changes that were introduced in ClassicPress in v1.x, such as the privacy-oriented changes (anonymizing data CP sends to APIs), the news widget, and ensure that all API endpoints use ClassicPress APIs as in v1.x.

The discussion continues around how to proceed with the fork. ClassicPress contributors are leaning towards using Franz’s WP-CMS fork based on WordPress 6.0 but have not finalized the details yet.

ClassicPress is polling its users to determine the next step for the software. The project is a pared back fork of WordPress based on version 4.9 that uses the TinyMCE classic editor as the default option with no block editor. It’s run under a non-profit organization called the ClassicPress Initiative.

In July 2022, the project appeared to be on the rocks when its directors resigned, saying that the community felt they were now hindering the progress of ClassicPress. The organization was struggling to meet its required financial support but has since rallied and is in a more stable place after moving the donation process to Open Collective.

In a recent forum post titled “The Future of ClassicPress,” one of the project’s directors, Viktor Nagornyy, presented the community with two paths: re-fork ClassicPress using WordPress 6.0, or continue as-is.

“Over the past few years, our core team has been working on improving ClassicPress and backporting features from WordPress,” Nagornyy said. “As WordPress continued to evolve, ClassicPress got a bit behind in adding new features as the focus became PHP 8+ compatibility.”

An exploratory fork of WordPress 6.0 with the block editor removed exists in a GitHub repository called WP-CMS. It is not finished but could potentially become ClassicPress 2.0. This option has the benefit of helping the project catch up to WordPress and improve compatibility with more recent versions of PHP, and open up more plugins and themes for users that require 5.0+ in order to be compatible. The downside is that it will take months to complete with ClassicPress’ limited number of contributors and ClassicPress 1.x would need to be maintained in terms of security for some time.

The alternative is continuing to maintain the project as it is with no requirement to maintain separate versions. Nagornyy identified the cons of this approach:

• Our small core team will continue to focus on PHP compatibility
• Backporting from WP is prioritized, so new ClassicPress features might not happen
• We won’t be able to catch up with WordPress, functions/features will be missing
• Plugins/themes compatible with WordPress 5+ would be incompatible with ClassicPress

The project is now at a crossroads considering the two options, which has forced the community to reexamine the purpose of ClassicPress.

“So the real question is ClassicPress a Pre-Wordpress 5.0 or just WordPress without Gutenberg?” founding committee member Daniele Scasciafratte said.

“Considering also that CP is based on a codebase of 5 years ago and the web is moving on, I think that we should move to Re-Fork and find a way to automatize it as much possible and simplify it.”

ClassicPress core committer Álvaro Franz, who is also the author of the WP-CMS fork based on WP 6.0, said he is unwilling to help with a continuation of the current version.

“I don’t see the point in working on an outdated version of something that has already been improved by many great developers at WordPress (as stated by @Mte90, there have in fact been A LOT of improvements),” Franz said. “But I can take care of v2, since I already am the author of the mentioned fork, I can help with keeping WP-CMS up with WordPress and then using that as a base for CP v2.”

WordPress core contributor Joy Reynolds commented on the thread, indicating that ClassicPress has a grim future ahead if it keeps struggling to backport all the improvements made after 4.9. She contends that continuing on the same path leads to a dead end, given the project’s small contributor base:

The whole point of backporting from WP is because they have thousands of developers, millions of users testing every combination of version and plugin and host to find problems (plus a testing team), a security team, and a performance team. CP has none of that and it’s kind of silly to not take advantage of their efforts. But the more things we ignore or fall behind on, the harder it is to backport anything.

There are many things that continue to evolve, outside of WP, like PHP, Javascript, CSS, HTML, and various bundled tools (like jQuery and TinyMCE and PHPMailer and Simple Pie and Requests…).

CP can’t stand still at 4.9. That’s dead. But if you tried to backport all the PHP8 stuff, you’d find it very difficult because of all the formatting changes they made, plus all the bug fixes, plus all the new features. The new fork bypasses the backport problem by taking it all at once and deleting the block stuff that is unwanted.

I personally think that CP doesn’t have any features of value that WP doesn’t have. It has a bunch of fixes and a few features from WP, but it’s a dead end, especially with the limited roster of people who contribute code.

In a contrasting comment, ClassicPress founding committee member Tim Kaye distilled why the poll seems to be so divisive.

“If all that people want is WordPress without Gutenberg, there’s absolutely no need for ClassicPress at all since there’s already a plugin that provides what you’re looking for,” Kaye said. “It’s called Classic Editor.

“The idea that the question is whether CP should essentially mirror a stripped-down version of WP or not is therefore entirely misconceived. Those who desire that objective should be using that plugin. It’s really that simple.

“CP (and the work that goes into it) only makes sense if it’s its own CMS with its own decision-making process and its own features.”

Former ClassicPress contributor @ozfiddler, who likened working on the project to “polishing the brass on a rudderless ship,” suggested ClassicPress identify a destination before choosing between two paths.

“But then, that’s the problem with CP – it never really knew where it was going, beyond ‘WP-without-Gutenberg,’” @ozfiddler said. “So, it means you get statements like this listed as a con for one of the options: ‘We won’t be able to catch up with WordPress.’

“When I was contributing to CP I always thought that the ambitions greatly outweighed the available resources. I occasionally suggested a drastic pruning back of the project, but this was always met with widespread disapproval. I still think that if CP is going to survive at all (and I very much doubt it) then you will need to define a narrower subset of users and focus your limited efforts on catering to them.”

ClassicPress’ poll and the 80 comments in the discussion offer a glimpse into the frustrating reality of maintaining a fork of a fast-moving, large project like WordPress. So far there are 31 votes and Nagornyy plans to close it within the next few days if it doesn’t receive any new votes.