The Classicpress fork of WordPress, inspired initially by the forced introduction of Gutenberg in WordPress 5.0, is progressing positively, and today the first Beta was released, superceding the initial Alpha release.

The main feature added by the Beta is the advent of automatic updating, which of course we won’t see the benefit of until the next release, but it’s good to have it implemented.

I have ClassicPress installed on a test site on my development system, and aside from the different icon on the admin screens you’d hardly know the site isn’t WordPress – everything simply works the same, which for now is exactly as it should be.

As a developer who has wrestled with Gutenberg and would rather not have to, I’ve been closely examining the marketing copy produced by both the ClassicPress and CalmPress forks, and for now I think the right route for me is to continue testing and working with ClassicPress on my development system, and to leave CalmPress in the wings for now (but not forget about it entirely). The reason for this is that I believe the ClassicPress team are prioritising compatibility more highly than the CalmPress developer, and that is something that is important for me.

The acid test, of course, will be to use ClassicPress on a live site, and I would love to, but there are two things that need to happen before I’m willing to do that.

These days there are certain plugins that I use across all my sites and rely on heavily. One of these is WordFence, which scans my live sites and reports on vulnerabilities and attacks. At the moment WordFence will complain and throw out a bunch of false positives if run on a ClassicPress installation, because it is comparing that installation with a stock WordPress installation, and many core files have changed in ClassicPress. If the ClassicPress team are able to persuade those at WordFence to make it check against ClassicPress core files instead of WordPress core files, when it detects a ClassicPress installation, that would sweeten the deal considerably for me.

The other issue for me is that I use the MainWP centralised control system to handle core and plugin updates for all my sites and my clients’ sites. It saves me untold hours every week and underpins my ZigCare service. I’ve found that MainWP handles plugin updates for ClassicPress installations without a problem, which is excellent news, but right now it’s impossible to know if it will handle ClassicPress core updates, until another release (after the current Beta) is made. You can be sure I’ll be testing that once there’s another ClassicPress release.

Something that both of those plugins have in common of course, is that they communicate (or trigger communication) with a third party outside the website installation. WordFence communicates with its servers and the WordPress repositories to check file integrity, and MainWP’s child plugin connects with the WordPress repositories for the purpose of identifying and fetching required updates. And that, I think, indicates one of the crucial things for ClassicPress: aside from the quality of ClassicPress itself, its success will also depend on the willingness of third parties to make it part of their ecosystems.

So for me in particular, ClassicPress isn’t yet ready for using on a live site, especially one belonging to a client. However, it does show promise in a lot of ways: a solid Beta has been delivered on schedule; there is an eclectic team of people involved; they engage in discussion via their forums; and their aims for ClassicPress fit with the way ZigPress approaches web development.

I’m quite excited to see how things develop.