Today I was checking up on ClassicPress, the project created by Gutenberg. Many WordPress developers were fed up with the hundreds of thousands of hours Automattic devoted to Gutenberg, instead of improving WordPress core. Gutenberg was a project to turn a professional CMS (WordPress) into a page builder (Wix). So a group of developers decided to fork WordPress at version 4.9, before Gutenberg became part of core. ClassicPress hasn’t exactly taken off like a rocket, but there is still a core group of contributors who collaborate on a Discourse forum.
It’s quite telling that Discourse is preferred over bbPress, another one of the unloved children of WordPress who could have benefited from a tiny amount of the love and resources Matt Mullenweg squandered on Gutenberg.
A contributor KMH offered a very sensible insight. He mentioned that ClassicPress claims to be more secure than WordPress out of the box, but still requires an enormous amount of hardening to be secure. His suggestions for security issues to be incorporated are:
- enforce strong passwords
- limit login attempts to prevent brute forcing passwords
- change the table prefix
- change/hide the login URL from /wp-admin or /wp-login
- prevent usernames from being exposed
- add math captcha or 2FA to login
- block bad queries
- disable theme and plugin editors
These would be very sensible defaults for a WordPress alterantive to implement. Otherwise advanced developers like us all waste hours and hours implementing them by hand on every site we build. Less advanced users simply live dangerously or install exotic security plugins which take days to set up properly and still create problems. There is such a thing as too much security: image a house where there is a twelve-foot fence, plus three sets of doors each with three sets of locks on them. One could almost never leave the house or receive visitors. By building in enough security, ClassicPress makes publishers’ lives easier and their sites more secure.
More importantly, KMH questioned longstanding WordPress doctrine that “everything should be a plugin”. The ClassicPress team seems to have inherited from Automattic:
In that other thread most of the suggestions to close those exploits by default in the core were “declined” saying it should be handled by a plugin. I don’t really agree with that, I think it’s an opportunity for CP to be more secure than WP out-of-the-box without any plugins. Without admins having to change settings or install a hodgepodge of plugins, trusting they’ll be maintained, remain compatible, are coded rights, and won’t be the weak link that gets the site compromised.
Absolutely. Just make ClassicPress secure out of the box. Force publishers to disable essential security, not hunt for it. The whole WordPress “everything should be a plugin” doctine was wrong from the beginning. Crippled core has always been a way for Automattic:
- to sell WordPress VIP (only real experts like Automattic, Pantheon, Foliovision and later Kinsta and WP Engine could run WordPress sites securely and fast, with millions of monthly visitors)
- to push JetPack spyware on the WordPress community (remove so much functionality that if a less technical user wants to have Markdown or decent image management, s/he must install Automattic’s spyware, remember user data is revenue)
- to make hosting on WordPress.com more attractive (the only place where one can inexpensively and successfully run a WordPress site is WordPress.com)
The WordPress.com advantage is more or less the truth at this point. If I had to run a hobby WordPress site, I’d properly put it on WordPress.com as I just don’t want to deal with the security and backup issues. Our commercial sites require between twenty and fifty plugins to run properly and securely. Of course most of these sites include quite a bit of advanced functionality which would be near impossible to run on WordPress.com. But if I were looking for the basics, including basic ecommerce, I’d run it on WordPress.com (or Squarespace) at this point. WordPress never grew up, and it was by design.
Returning to the plight of ClassicPress, it’s a project without an identity or a mission. In response to KMH, Founding Committee Member Tim Kaye just repeated the WordPress dogma about keeping WordPress/ClassicPress core crippleware:
Many of those things are handled by a good host. If we put them in core, there’d be a problem of two things trying to do the same thing, which is a recipe for disaster. That’s why they are better in plugins; if your host doesn’t provide them or you run your own server and don’t want to implement these things at server level, you can add a plugin to do so.
The incomplete and insecure out-of-the-box experience requires both a slough of plugins and an advanced hosting provider to run securely. When WordPress.org was still a group of like-minded developers helping one another and creating simple and free plugins which we could all use, the situation was tenable. Now the plugin situation is a used-car lot filled with hundreds of dodgy vendors, each of which offers free crippleware versions with telemetry now (yes Syad Balkhi I’m looking directly at you and the telemetry you added Pippin’s Easy Digital Downloads, telemetry which cannot be turned off and shares all of a site’s sales numbers directly with Balkhi).
ClassicPress needs a competitive advantage and there is one here for the taking.
Something clear like a “more secure WordPress” would be a good start. “No plugins required. We’ve got your back,” would be a good second act.
What’s so very annoying about WordPress is how Gutenberg and the page builder mania has made WordPress so much clunkier and less productive a CMS. I’d love to try to explain to people that ClassicPress is a high productivity CMS, not just a page builder but that’s probably too much thinking for the current publisher crowd who are far too interested in fiddling with blocks and not nearly interested enough in building out content quickly and efficiently.
Tim Kaye does mention that ClassicPress does a couple of security basics better:
First, ClassicPress uses a much stronger form of hashing than we inherited from WordPress. We use bcrypt instead of md5. Secondly, ClassicPress ships with a Pepper plugin. You can also download it from ClassicPress Pepper for Passwords | ClassicPress Plugin This is in addition to the built-in “salt” that has traditionally been added to the hashing mechanism.
Third, the ability to disable both Emoji and XML-RPC is built into ClassicPress. Just go to Settings -> General and scroll down to check the boxes to turn them off.
That’s a good start but not enough. Most of KMH’s suggested security measures should be in ClassicPress core. As KMH points out:
These measures should be in the core IMO. Especially with the mission statement asserting “We aim to provide a CMS that is…secure…” It doesn’t seem much more secure than WP, which isn’t very secure at all or we wouldn’t need a pile of third-party plugins just to secure it.
This is a great idea. One of the issues which annoys me so much about Automattic WordPress is intentional neglect of core functionality. Basics like a form system, basic SEO (something like our FV Simpler SEO, nothing complex), caching, performance improvements, an SMTP plugin – all of that should be built-in. In a simple and robust way.
That way if a forms plugin wishes to further enhance the WordPress forms logic, the path is straightforward. Use the existing functionality and build on top.
ClassicPress should abandon once and for all the deliberate crippling of the WordPresss CMS. Automattic has already locked up the broken car paradigm with subscription heated seats in the CMS space. ClassicPress should be secure and great, straight out of the box.
Alec Kinnear
Alec has been helping businesses succeed online since 2000. Alec is an SEM expert with a background in advertising, as a former Head of Television for Grey Moscow and Senior Television Producer for Bates, Saatchi and Saatchi Russia.
Leave a Reply