ClassicPress: WordPress without the block editor

The recent WordPress controversy is not the first time there's been tension between the WordPress community, the interests of Automattic as a business, and Matt Mullenweg's leadership as WordPress's benevolent dictator for life (BDFL). In particular, Mullenweg's focus on pushing WordPress to use a new "editing experience" called Gutenberg caused significant friction—and led to the ClassicPress fork. Users who want to preserve the "classic" WordPress experience without straying too far from the WordPress fold may want to look into ClassicPress.

Gutenberg background

In 2017, Mullenweg announced that one focus for the year would be "to create a new page and post building experience". The goal was to make it easier to develop sites using WordPress without resorting to custom HTML, shortcodes, or so-called "mystery meat": features supported by WordPress that were perhaps known to developers but not easily accessed by those simply authoring content on a WordPress site.

For much of WordPress's history, it had used TinyMCE as its default editor to create blog posts and site pages. This rich-text editor was fine for creating posts and pages with simple layouts, but WordPress was seeing competition from companies like Wix and Squarespace that offered drag-and-drop site-builder tools. However, while that competition was a problem for Automattic—the community as a whole was not convinced that WordPress needed to go in that direction.

The new editor took on the name Gutenberg, a nod to German inventor Johannes Gutenberg who developed the movable-type printing press. The WordPress 5.0 release in 2018 included Gutenberg as part of its core features and removed the classic editor. (Users could and, for now, still can use the classic editor by installing a plugin.) The idea was to move to a system of blocks that make up the content and layout of a WordPress post or page. Each element is a separate block: paragraphs, headings, images, and so forth are each discrete blocks with properties that can be edited separately. The screenshot below shows the Gutenberg editor in WordPress 6.6.2 (the most recent as of this writing), with a paragraph block selected. It has its own, contextual, menu of options for formatting, alignment, or converting the block to another type.

That represented a major departure from the way users and developers were used to managing content in WordPress. Since the initial Gutenberg release, WordPress has moved to a full-site editing (FSE) approach that expands the blocks editing concept to editing all aspects of a site (not just the page or post content) using blocks and a GUI.

As with any major change in a popular open-source project, Gutenberg caused a fair amount of controversy. Some of that could be fairly summed up as "people hate change". The Gutenberg approach to editing content is something of an acquired taste, and many users simply did not see value in a block-based editor for writing blog posts. It also meant that some themes and plugins would need to be updated to adapt to the block editor and its underlying changes. But not all of the objections were a matter of taste: Gutenberg's development had a real negative impact on accessibility in WordPress.

Adrian Roselli wrote about those problems in 2018. Roselli identified several problems, such as failure to staff the project with accessibility experts, an accelerated schedule, and unfamiliar technology (Gutenberg used the React framework, which was new to WordPress) led to problems addressing accessibility issues caused by the move to Gutenberg. The team that did work on WordPress accessibility, he said, were volunteers facing "a constantly shifting codebase" where issues fixed one day might reappear a week later. Rian Rietveld, who had been the WordPress accessibility team lead, resigned due to problems with the development process for Gutenberg and the lack of emphasis on accessibility.

Accessibility aside, many other WordPress users simply have not acquired the taste for the new editor (it has more than 2,400 one-star ratings on its review page, out of fewer than 4,000 reviews) or its implementation. David Bushell wrote in 2021 that Gutenberg "has been a constant thorn in my side" with "so many problem to discuss it's overwhelming" and claimed that the majority of web developers he knows disable the editor. Users can, for now, still enable the classic editor via a plugin which restores the old editor and hides the block editor. It is an official plugin that was due to sunset in 2021, and now "will be fully supported and maintained until 2024, or as long as necessary" according to the plugin page. It has currently more than 10 million active installations, so one hopes it is still considered necessary for some time to come.

ClassicPress fork

The fallout from Gutenberg led to a fork of WordPress called ClassicPress in 2018. The project provides a "pre-5.0 WordPress publishing experience" with a governance process and a ClassicPress Initiative non-profit that covers the project's expenses. It currently has an annual budget of less than $2,000. There is no for-profit entity behind the project, and the foundation does not pay any developers to work on the project. ClassicPress began with a fork of WordPress 4.9.x, the last major version without Gutenberg, and the ClassicPress 1.x releases were based on that branch. The most recent is ClassicPress 1.7.3, which was released in March 2024. Like WordPress, of course, the project is licensed under the GPLv2 and is primarily composed of PHP with a fair amount of JavaScript.

The ClassicPress project is not immune to controversy. In June 2022 the directors of the foundation resigned, with departing director Wade Striebel saying that it was clear that "the community feels that the Directors of the ClassicPress Initiative are now hindering the progress" of the project. The outgoing board appointed new directors who took over the foundation, with a plan for community governance. The project decided via a vote by contributors in December 2022 to "re-fork" from WordPress 6.x, rather than try to be its own content-management system (CMS). It was felt that there were not enough developers to keep the project relevant without backporting code from upstream WordPress. There are currently nine people identified as "core committers", with 38 contributors who voted on the project direction.

The first release of ClassicPress based on WordPress 6.2.3 was announced in February 2024 as ClassicPress 2.0, and the most recent release in that series (2.2) was announced in September 2024. It pulled in some of the new WordPress features such as the Site Health status check, compatibility with more themes and plugins (so long as they do not require blocks), as well as security updates.

While the primary selling point for ClassicPress is that it preserves the pre-Gutenberg WordPress experience, the project has added some enhancements unique to ClassicPress. For example, the 2.0 series introduced HTML5 output by default, and accessibility improvements for using widgets, menus, and other controls. The latest release made some small enhancements to the media library to allow bulk editing of images or other content stored in the library. For the most part, though, the ClassicPress is more about retaining the original WordPress experience and not about unique features.

Moving to ClassicPress

If starting from scratch, users can install ClassicPress more or less the same way that they would install WordPress. It requires a server with PHP, MySQL or MariaDB, and a web server (Apache, NGINX, or LightSpeed/OpenLightSpeed). The user needs to be able to upload files to the server, and know the username, password, and other database-access details to add the credentials to the wp-config.php file. The rest is simply connecting to the web-based administrative interface and walking through a brief setup routine. It is slightly more involved than that, but only slightly.

It is even easier for users with an existing WordPress site. They can switch to ClassicPress by installing and using the migration plugin. After the plugin is enabled, it runs a check against installed themes and plugins to verify whether they are compatible with ClassicPress or not, and recommends disabling those plugins for the migration. Users are advised to install and use the WordPress Twenty Seventeen theme to ensure compatibility during the migration. Users can re-enable compatible plugins and themes after performing the migration, if they do not depend on blocks. The actual migration takes just a few seconds. It is an easy process, so long as the site does not depend on any plugins or themes that use blocks.

Once installed (or migrated), ClassicPress looks and feels like old-school WordPress. It has the familiar menu structure, administrative interface, and (of course) the standard rich-text editor that so many users still prefer. Fans of the WP-CLI tool will be happy to know that it works well with ClassicPress too.

ClassicPress is also a little bit more responsive than standard WordPress, and much slimmer. The source for a WordPress install is 76MB uncompressed, while ClassicPress weighs in at 37MB.

Plugins and such

The ClassicPress dashboard allows installation of themes and plugins via the directory on WordPress.org. The dashboard displays all of the available themes and plugins, but shows a warning and blocks installation of those known to be incompatible with ClassicPress. For example, if a theme requires FSE capabilities, it cannot be installed through the dashboard.

Note that a plugin or theme may still have an incompatibility that slips through the cracks. For example, I installed the WP fail2ban plugin on ClassicPress 2.2 and WordPress 6.6.2 sites running on the same host. The plugin gave an error about permissions when trying to access its Settings tab on ClassicPress, but worked fine on WordPress. The other plugins and themes I've tried, such as Antispam Bee for fighting comment spam, have worked without any problems. (Or at least any problems that have come to my attention.)

The project also has lists of plugins and themes created expressly for ClassicPress, as well as an integration plugin that allows users to manage them from the dashboard as they would WordPress themes and plugins. There are fewer than 100 plugins and 13 themes custom-made for ClassicPress at the moment. Whether this is a problem or not, of course, depends on what a user wants to do with their CMS. For WordPress's original purpose, blogging, ClassicPress is just fine.

For a business web site with all the bells and whistles, it may depend. ClassicPress does have a project based on a fork of the WooCommerce online-store platform for WordPress, called Classic Commerce, for those who want a "business-focused CMS" with e-commerce functions. It is missing an answer to Jetpack, which is Automattic's bundle of free and paid tools for things like malware scanning, backups, statistics, and more. It is possible to cobble together much of that functionality through other plugins.

One of the primary concerns many users will have is about security updates for their CMS. WordPress has been known to have a security issue or two, and one might wonder whether the ClassicPress team is on top of security updates that might affect it. Tim Kaye, one of the core developers, told me that the project has backported "all relevant security updates" from WordPress, though he also asserted that most of the security updates "don't apply to us because they are blocks-related". He recommended users refer to the merged pull requests to audit the security updates applied to ClassicPress.

Why bother?

The ClassicPress effort may strike some as quixotic. Currently, users can still grab the Classic Editor plugin and pretend Gutenberg doesn't exist. However, there's no promise that it will be supported forever. The block-editor experience is, for many, an unwanted departure from the way they have worked with their site for years. That workflow seems worth preserving, even if it is for a minority of users.

The project encourages contribution, and has an active forum and real-time discussions via Zulip (sign-up required). ClassicPress seems to be a small, but healthy, project. For users who are disillusioned with the direction of WordPress, or simply want to avoid the newfangled editing system, it provides a useful alternative without having to port content to a completely new CMS.