The Future of ClassicPress Discussion

What is the full list please?

Custom login screen, “anonymous” API calls, an extra column in the posts table which shows the post ID, a security screen (which doesn’t do anything), … something else?

Users who NEED WordPress, should just stick to use WordPress. Period.

Only concern is, plugins like ACF… will they eventually stop working because they NEED block-related functions? We don’t know… but for a few fundamental plugins we can actually make some pressure and ask that they add some conditionals. It’s not going to work for most cases, but… at least maybe for the fundamental ones like ACF.

Docker is the standard today. Wasting time for the sake of using something else is… well, that, a waste of time. Docker works perfect, no need to hate on it. Plus… if it’s not Docker, it’s going to be something else which you also HAVE TO SETUP. It’s never going to just work magically, you always need a server, PHP, a database… so yeah, installing Docker is a no-brainer.

So, the point is:

  • Is it harder to now go and chase PHP 8.1?
  • Or is it harder to now go and fork WP-CMS and rebrand it into ClassicPress?

I’ve been doing some early work on looking at a re-fork. My feeling is we should maintain our current infrastructure - no need for creating Docker images or any alternative. Our src code runs fine on a local *AMP stack.

I have started the process once already and paused pending this discussion.

The issue for me is that there are enhancements and features currently in WordPress 6.1.1 that at worth considering, for example some changes we almost certainly don’t want:

  • Block Editor
  • JSON based Themes
  • Application Passwords
  • Textdomain registry

Some changes we probably should now adopt:

  • Sitemaps (can be disabled if desired)
  • Error recovery (helps keep sites functional trapping and bypassing errors)

One other small but possibly significant change would be in the documentation block, dropping the WP- prefix used in the @since markers for upstream code and instead marking our additions with @since CP-1.1.2 for example.

There are still a lot of files to update and review, as well as file and references to delete with this work. But if we can agree on a starting point at least we can create a branch and begin the work.

What’s the reason for not including application passwords? We’ve had petitions in the past asking for API auth.

And also textdomain registry?

The less features we remove, the easier it will be to backport stuff. We can also disable features by default, allowing users to enable it if needed.

Site Health is another feature to keep. I find it very helpful for debugging, at least the part where you can see current server resources, permissions, etc.

As a sidenote, I would like for us to adopt conventional commits for writing commit messages so we can try to automate release notes and changelogs. It would be ideal to start with the new branch. If our release process allows for this:

We can include Application Passwords if that is the consensus, again I suppose it can be disabled. My personal issue is opening another potential surface for infiltration, especially when it isn’t something I can envisage ever using. (But I can disable it).

I suppose the Textdomain registry is linked to API privacy issues and reliance on upstream translations that may not work 100% in ClassicPress - but again I have no major opposition to including it.

Site Health is a helpful addition - I agree with that.

Also, commit messages based on convention makes sense - we have always tried to make useful commit message with no more than 72 characters, further conventions could well prove helpful.

I do also wonder about the replacement of WordPress with ClassicPress in the core documentation blocks. Is that something we can leave (apart from file headers with the @package tag where we should probably keep it. Could the document website parser then be extended to replace WordPress with ClassicPress when parsing the documentation?

I don’t know what the solution is, but it would be nice to provide some form of API auth. Initial petition, probably before application passwords were introduced, did gather a lot of votes (60).

So it’s another API? I don’t think I’ve heard about this. I’ve only seen information in the code reference.

It may not be quite the same thing but REST-API can be blocked for anyone who is not logged in as follows:

add_action( 'rest_api_init', 'rest_redirect' );
function rest_redirect() {
	if ( ! is_user_logged_in() ) {
		wp_safe_redirect( home_url() );

And looking at the Text Domain Registry - perhaps it isn’t a new WordPress API, ticket is here:

Perhaps something we should keep as it seems to fix a multilingual problem.

I would definitely like to see Application Passwords included. At present I use the plugin on which the core code is based.

This is the sort of thing that would be perfect for a core plugin. But it seems that (for a variety of reasons) we’re dropping that idea (or, at least, delaying it indefinitely).

1 Like

It sounds like text domain registry might be good.

I would say we should keep application passwords just up eliminate additional merge conflicts removing it would create. We can keep it as is or disable it by default, so it can be enabled with a filter or option.

I think focusing on blocks and JSON themes would be a good start. We can always decide to remove something later, which might be easier once blocks/JSON themes stuff is already gone.

And for the docblocks, whatever you think is the easiest option for us is good with me. The phpdoc-parser isn’t really working, I’m trying to figure out why.

Considering that reforking also mean deciding if a functionality is needed, this can be the right moment to add “switches” where possible.

if ($i_need_it) require_once 'feature.php'

For me using constants, filters, “hidden” options or even a new setting page it’s the same.

This way we can also avoid many discussions on each feature.


I think adding a switch should be based on the feature’s intended users.

  • Application passwords (developers) - use a filter to enable it. Can be left enabled. Plugins that may need it should be able to enable it, something similar to add_theme_support(). Enable it if plugin/theme declares support for it.
  • Automatic webp generation (users) - add a checkbox to enable it under Media settings.
  • Sitemaps should be left as is. They are important and with Classic SEO unmaintained at this time, that’s good to have.
  • Site health should be left as is.
  • Error recovery should be left as is.

Anything else we’re missing? We don’t have to decide every feature’s fate at this point. We may come up on a feature we want disabled or add a switch while working on the fork. At that time we can figure out what the best option is.

Since it’s a major version, I would recommend dropping official support for PHP 5.6. It may still work, but we shouldn’t waste our time chasing it. Any issues coming up with 5.6 will not be fixed.

Our primary focus should be the removal of blocks and JSON themes code. Any additional changes should be made after unnecessary code has been removed. Mixing things will cause problems debugging issues.

@MattyRob do you think we should proceed with your approach, applying changes one file at a time? Or should we take Alvaro’s WP-CMS, ensure blocks and JSON theme code is removed, and then begin applying any CP related stuff?

You’ll know better than me, but from my end, it seems that using WP-CMS as a starting point and making it into CP would be more efficient:

  • We don’t have to remove any CP features we’re not keeping, we just bring in what we want.
  • All the docblocks are already back to the original WP docblocks, so we can add CP stuff.
  • Blocks (and maybe JSON theme) code has already been removed, so we just need to check if anything else is left.

Is there anything I’m missing?

As a side question, should we drop composer.json? We are listed on Packagist, but I’m not sure if we have access to that account.

1 Like

I’ve been thinking about attracting more core contributors and this issue with Docker started to bother me a bit. Since WP uses Docker, wouldn’t it make sense to keep the process/tools as similar to WP as possible for anyone familiar with WP process to be able to contribute to CP?

For example, if a WP contributor decides they want to contribute to CP and they are familiar with WP process, it might make them re-think contributing to CP if they see the process is different and tools used are different.

This aligns with one of my other hopes for re-forking, an updated codebase might attract core contributors. So it only stands to reason the tooling might play a role here too.

Something to consider.

1 Like

I suspect any WP contributor will find it much easier to build and test on ClassicPress. Docker is used due to the complex build needed due to the Block Editor code.

Personally speaking, if Docker becomes a necessity for ClassicPress it is going to put me off developing for CP.

That makes more sense. Thanks.

Any thoughts on this? So we can try to move forward in some way:

So after further discussions today on Slack, I think we agreed on a tentative plan to proceed with re-fork.

  1. We will begin work in an experimental repository using WP-CMS codebase only.
  2. A separate repository will allow us to do the work without polluting main repository and history of v1.
  3. When v2 is considered ready we will branch v1 and drop v2 codebase into develop branch.
  4. When changes from v1 are brought in to v2, the commit should follow this structure:
  5. Next, we will need to come up with a list of features (and their PRs) to migrate to v2. This should be done as an issue in Github with checkbox tasks to keep track.
  6. We need to make a list of APIs that need to be updated.
  7. We need to make a list of branding changes that need to be done.
  8. We need to review the code and remove/update any WP-CMS specific code (for example, core update and translations have WP-CMS specific code)
  9. We need to make a list of new changes that we may want to implement. (Ex: disabling WEBP by default.)
  10. We need to review the core code/files for any remnants of block code. I saw at least one so far /wp-includes/theme.json.
  11. Once we break down the work into a manageable list, we will need your help to start! With a clear list of tasks to complete, I would like everyone interested in helping to claim the tasks they wish to complete. Even if you can only complete one task, that’s a lot of help and we will appreciate it!

We may find additional work that needs to be done as we begin forking.

A blog post announcement will be published for the general public once we get some feedback on this roadmap.

Anyone willing to help either leave your GitHub username here or private message me to be invited to the repository.


Since there haven’t been any additional comments on the tentative plan, the discussion can now be completed and will close in 3 days.

@Core_Committers interested in helping with v2.0 can join us on GitHub. The list of issues is beginning to grow and PRs are being submitted. If you don’t have time to submit PRs, help review them!

We welcome all the help we can get! Including writers to help write/rewrite documentation, translators helping with translations, and anyone else willing to help! Message on Slack in the #community channel, start a discussion on the forum, private message me, or join us on GitHub.

v2.0 repository:

v2.0 project to track progress:

Thanks to everyone who participated in the discussion:



This topic was automatically closed after 3 days. New replies are no longer allowed.