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.
