This discussion will focus on the results of the poll and users’ feedback. It’s limited to core contributors (@Core_Committers) and will be kept private. Keeping this discussion on the forum, instead of Slack, ensures everyone can participate in the discussion without timezone limitations over the course of a few days/weeks.
The option to re-fork has 20 votes while continue-as-is has 18.
The goal of this discussion is to find a way forward.
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.
But, we’re also not going to be WordPress without Gutenberg. WordPress has shown a lack of care for the needs of the community more than once since Gutenberg was introduced. We have to make the right decisions for the ClassicPress community even if that means deviating from WordPress core at times.
We need to be our own community while leveraging WordPress core, we can’t let commercial interests controlling WordPress control ClassicPress.
For example, and this is my personal example, WEBP generation should be disabled by default.
The re-fork gives us an opportunity to do certain things differently and improve the processes.
- For example, as suggested by Daniele, we can stop prefixing WordPress versions in docblocks
wp-and instead do that for CP versions.
- Automate the replacement of static strings such as API endpoints in the code.
- Automate the replacement of WordPress with ClassicPress.
- Possibly automate replacement/rewriting of dockblocks as needed.
- We also need to keep a list of any new changes that ClassicPress may introduce that deviate from WordPress core.
- If I’m not mistaken, code_potent rewrote installation screen/steps, unless there’s something specific for CP, we can probably let that go and keep WP’s code.
These are items off the top of my head, there are more so please share what you know.
In addition, we need to figure out what changes were introduced by ClassicPress in v1.x that we would like to keep in the re-forked version.
- Security page, post ID column, and customizing login page banner can be left out.
- Privacy-oriented changes should be kept (anonymizing data CP sends to APIs).
- All API endpoints must use ClassicPress APIs as in v1.x.
- Documentation URLs should point to ClassicPress documentation if available.
- News widget should be kept.
- Petitions widget needs to be rewritten to use GitHub data, so for now it can be left out.
Next, coding standards and tests. Alvaro mentioned his fork uses WPCS and tests, and everything is working. We need to review WPCS and see if we want to stick with it or continue with our custom WPCS rules, which may need additional changes. This also applies to tests, when we introduce certain changes WP tests may need to be changed so they can pass.
The big question is, how do we proceed with the fork?
- Alvaro’s fork WP-CMS can be a good start, it removes Gutenberg code and is up-to-date.
- Matt has done some work forking WP’s
developbranch, changing over 200 files, to see how hard it can be. He can talk about that more.
This also begs the question, who is willing to put in the time/work to help move ClassicPress forward and succeed?
2023 will be a great year for ClassicPress with your help!