In December 2022, the ClassicPress neighborhood voted on whether to re-fork WordPress or proceed on with the challenge as-is. As WordPress continues to evolve, ClassicPress fell behind in pursuit of PHP 8+ compatibility. The fork relies on WordPress 4.9 and customers are more and more restricted in what plugins will work with the five-year-old codebase.
In a discussion restricted to ClassicPress core contributors, Viktor Nagornyy, one of many challenge’s administrators, introduced the outcomes of the vote: “The choice to re-fork has 20 votes whereas continue-as-is has 18.” Nagornyy summarized earlier discussions and instructed an method that will be extra real looking for the challenge’s restricted contributors:
ClassicPress can’t be WordPress with out Gutenberg, nevertheless it can also’t be its personal CMS with a small core workforce at the moment. There are merely not sufficient builders to make progress with out backporting code from WP to maneuver away from WP.
An virtually even cut up within the ballot suggests the most suitable choice may be a hybrid one, discover a compromise resolution that may fulfill each side.
With a small core workforce, now we have to search out methods to be extra environment friendly, to get extra performed with much less. The one method to try this is to leverage all of the work that’s performed by WP contributors. Because the core workforce grows, we will all the time discover the opportunity of splitting away from WP however at this cut-off date, it’s merely not possible.
Some members within the earlier dialogue noticed re-forking as suspending the inevitable, kicking the can down the highway till the subsequent re-fork, however it’s the solely possibility if customers need to retain compatibility with the remainder of the WordPress ecosystem.
“In the event you learn latest threads, you discover out that the neighborhood expects plugin compatibility with WordPress… one more reason for the re-fork possibility,” ClassicPress core committer Álvaro Franz mentioned.
Franz, who can be the writer of the WP-CMS fork primarily based on WordPress 6.0, beforehand said he could be unwilling to assist with a continuation of the present model primarily based on WordPress 4.9.
“It [ClassicPress] doesn’t should be a contest (and it by no means might compete with WordPress anyhow), however it may be a leaner model, for people who find themselves already disabling Gutenberg through plugins, for builders who desire a completely different method to the best way they develop their tasks (nearer to ‘the basic’ expertise, however but… fashionable!),” Franz said.
“Finally, it received’t make sense to run a contemporary copy of WordPress to then go and set up a plugin that ‘disables’ half of it. What’s the purpose? Why not have a model that covers that particular use case?”
As a part of Nagornyy’s proposed hybrid method, he instructed the challenge retain some adjustments that had been launched in ClassicPress in v1.x, such because the privacy-oriented adjustments (anonymizing knowledge CP sends to APIs), the information widget, and be sure that all API endpoints use ClassicPress APIs as in v1.x.
The dialogue continues round easy methods to proceed with the fork. ClassicPress contributors are leaning in the direction of utilizing Franz’s WP-CMS fork primarily based on WordPress 6.0 however haven’t finalized the small print but.