The decision to use ClassicPress or to stick with the classic editor in WordPress is not a personality test. It is an engineering decision that depends on the project, the client, the content team, and what the site actually needs to do. This hub collects practical notes on the classic editing workflow, ClassicPress as a fork, migration considerations, plugin compatibility, and the specific scenarios where the classic approach still delivers better project outcomes than the block editor. The flagship piece on this topic, Hello No WordPress Gutenberg, Hello ClassicPress, covers the broader argument in detail. The notes here complement that piece with more focused observations.
Whether you are evaluating ClassicPress for a new project, maintaining a site that still runs the Classic Editor plugin, or trying to explain to a client why the block editor might not be the right fit for their editorial workflow, these notes are written from the perspective of someone who has worked with both approaches on real client projects and has opinions grounded in that experience.
Why Some Developers Prefer the Classic Workflow
The classic editor is not a legacy system clinging to relevance. For many project types, it is a faster, more predictable, and more maintainable authoring interface than the block editor. Content sites where the editorial team produces long form text, technical documentation sites where content structure follows templates rather than freeform layouts, membership sites where the content creation workflow needs to be as simple as possible, and client sites where training budget is minimal all benefit from the stripped down clarity of the classic editing experience.
I have seen projects where switching to the block editor added two weeks of training time for the editorial team and introduced a new category of support requests around block placement, reusable block management, and the distinction between post content and template parts. That is not a failure of the block editor design. It is a mismatch between the editing interface complexity and the actual editorial needs of the project. The classic editor does not have that mismatch for these use cases.
Developers who build custom themes and custom plugins for client projects often prefer the classic editor because it gives them more control over the content output without needing to build custom blocks. A custom meta box in the classic editor is a known, stable, well documented pattern. A custom block in the block editor requires maintaining a React based build pipeline for the editor sidebar, handling block deprecation if the markup changes, and testing across the evolving block editor versions that ship with WordPress core updates. For agencies doing client work, that maintenance overhead is a real cost.
ClassicPress as a Fork
ClassicPress is a community maintained fork of WordPress that removes the block editor and maintains the classic editing experience as a first class feature rather than a plugin compatibility layer. It branched from WordPress 4.9 and has continued to receive security patches, performance improvements, and compatibility updates from its volunteer development team.
The practical question with ClassicPress is not whether it works. It does. The question is whether the plugin and theme ecosystem you need is compatible and whether the project timeline is long enough to justify the fork. For new projects that will run for years and where the classic editing experience is a firm requirement, ClassicPress removes the dependency on the Classic Editor plugin and the uncertainty about how long that plugin will continue to be maintained against future WordPress core changes.
For existing WordPress sites, the migration path from WordPress with the Classic Editor plugin to ClassicPress is documented and generally straightforward for content focused sites. Sites with complex plugin stacks need individual compatibility testing. The ClassicPress community maintains compatibility information, but the reality is that popular plugins are tested against WordPress, not ClassicPress, so you should budget testing time accordingly.
Migration and Compatibility Considerations
Migrating from WordPress to ClassicPress involves replacing the WordPress core files with ClassicPress core files. The database structure is compatible. Content, users, settings, and most plugin data transfer cleanly. The areas where migration gets complicated are plugins that have deep dependencies on WordPress core functions that ClassicPress has modified, themes that use block based template parts or the site editor, and any functionality that relies on the Gutenberg editor being present in the admin.
Before migrating, I recommend running a compatibility audit that covers every active plugin, the active theme, any custom code that hooks into WordPress core functions, and any third party integrations that interact with the WordPress admin. Most well written plugins that do not touch the editor work fine on ClassicPress. Plugins that add block types, extend the block editor sidebar, or use the WordPress REST API endpoints specific to the block editor will not work and will need alternatives.
The reverse migration, moving from ClassicPress back to WordPress, is also possible but requires restoring WordPress core files and testing everything again. This is worth knowing if a client decides after six months that they want to try the block editor after all.
When the Classic Editor Still Makes Sense
The classic editor approach makes the most sense when at least two of the following conditions are true: the editorial team is non-technical and needs minimum interface complexity, the site content follows structured templates rather than freeform visual layouts, the development team has existing workflows built around custom meta boxes and classic theme patterns, the client budget does not include block editor training and block development maintenance, or the plugin stack is mature and stable and does not benefit from block editor integration.
It makes less sense when the site genuinely benefits from flexible visual content layout, when the editorial team is comfortable with block based editing, or when the project uses modern WordPress features like full site editing, block patterns, or the site editor. Those features are native to the block editor and are not available in the classic workflow.
The honest answer is that neither approach is universally better. The classic editor is better for some projects and the block editor is better for others. The mistake is assuming that newer automatically means better for every use case. The notes on this site are written from the perspective of someone who has used both extensively and makes the choice based on project requirements rather than ecosystem momentum.
Working with Both Approaches
Plenty of development teams maintain sites on both WordPress with Gutenberg and ClassicPress or WordPress with the Classic Editor plugin. Having a workflow that works across both means keeping your plugin and theme code clean enough that the editor dependency is isolated rather than spread throughout the codebase. Custom post type registrations, custom taxonomy registrations, REST API endpoints, admin pages, and most plugin functionality can be written to work identically regardless of which editor is active.
The divergence point is the content editing interface. If you are building a plugin that needs to interact with the editing experience, you need separate code paths for the block editor and the classic editor. If your plugin operates on post meta, custom database tables, or admin pages outside the editor, the code is typically identical.