When WordPress 5.0 shipped with Gutenberg as the default editor, it changed more than the editing interface. It changed the development model, the training costs, the plugin compatibility assumptions, and the long term maintenance calculus for every WordPress project in progress or planned. This page covers what that shift meant for developers who were already building and maintaining WordPress sites, why the classic editing workflow still makes practical sense for specific project types, where ClassicPress emerged as an alternative, and how to think about the Gutenberg question as an engineering decision rather than a community loyalty test. The ClassicPress hub collects additional notes on migration and compatibility. What follows here is the longer argument, grounded in years of working with both approaches on real projects.
What Gutenberg Actually Changed
The surface level change was visual. Instead of a single content area with a toolbar, the editor became a collection of individual blocks: paragraph blocks, heading blocks, image blocks, custom blocks, and a growing library of layout blocks. Each block could be configured, moved, and styled independently. The editing experience became more visual and more flexible.
The deeper change was architectural. Gutenberg introduced a React based editor framework into WordPress core. The content editing interface was no longer a TinyMCE instance that could be extended with simple JavaScript and PHP filters. It became a full client side application with its own state management, its own component model, and its own build pipeline requirements. For developers, this meant that extending the editor now required React knowledge, a Node.js build setup, and familiarity with the WordPress block API, which evolved rapidly across WordPress releases.
For plugin developers, this was the most consequential part. Any plugin that added functionality to the editing experience, whether it was custom fields, content templates, SEO meta boxes, or editorial workflow tools, needed to be rearchitected to work within the block editor framework or relied on the backward compatibility layer that WordPress provided for legacy meta boxes. That compatibility layer worked, mostly, but it positioned existing plugins as legacy components rather than first class editor citizens.
The Training Cost Problem
One of the least discussed impacts of Gutenberg was the training cost. For agencies and freelancers who hand off WordPress sites to non technical clients, the classic editor had a significant advantage: it was familiar. It looked and worked like every other rich text editor the client had used. Microsoft Word, Google Docs, email composers. The metaphor was understood. Type text, apply formatting, insert an image. Done.
Gutenberg replaced that familiar metaphor with a block assembly metaphor. Content creation became a layout construction exercise. Clients needed to understand what a block was, how to select it, how to configure it, how to move it, and how to distinguish between block level settings and page level settings. For clients who published text heavy content, this was overhead that added no value. The classic editor let them write and format. Gutenberg required them to assemble.
I tracked training sessions across several client handoffs during the first year after WordPress 5.0 launched. Projects that used the classic editor required an average of 30 minutes of editorial training. Projects that used Gutenberg required two to three hours, and those projects generated more support requests in the first month after handoff. The requests were not about bugs. They were about confusion. Where did my sidebar go? Why did my image jump to a different position? How do I put two things next to each other? These are questions that the classic editor did not generate because the editing model was simpler.
For projects with large editorial teams or clients with limited technical comfort, the training cost difference is not trivial. It translates into longer onboarding, more support hours, and a higher likelihood that the client will ask you to "just make it simpler" six months after launch.
Where the Classic Workflow Still Wins
The classic editor is not a downgrade. For specific project types, it is the better tool. Content sites where the editorial workflow is text focused. Documentation sites where every page follows a consistent template. Membership sites where the content creation interface needs to be as low friction as possible. Client sites where the editorial team does not have the time or interest to learn block manipulation. Agency projects where the development budget does not include building and maintaining custom blocks.
The classic editor also has practical advantages for developers. Custom meta boxes are a well documented, stable pattern. The TinyMCE API is thoroughly understood. The editorial interface behaves predictably across WordPress versions because it is a mature, stabilized component. There is no need to track changes in the block editor API, no need to maintain a React build pipeline for editor customizations, and no need to handle block deprecation when markup requirements change.
I have worked on projects where the classic editor delivered a better outcome specifically because of its simplicity. A membership site where content authors needed to publish lesson text and nothing else. A documentation portal where every page used the same structure and the editing experience needed to reinforce that structure rather than invite freeform layout experimentation. A small business site where the owner updated their own content and needed an interface that worked like writing an email. In each case, the classic editor was not a compromise. It was the right tool for the job.
The Case for ClassicPress
ClassicPress exists because the WordPress project made Gutenberg non optional. When WordPress 5.0 shipped, the official recommendation for users who did not want Gutenberg was to install the Classic Editor plugin. That plugin works, but it creates a dependency on a compatibility layer that is maintained at the discretion of the WordPress core team. There is no guarantee that the Classic Editor plugin will continue to function correctly as WordPress core evolves further toward the block based architecture.
ClassicPress removes that uncertainty. It is a fork of WordPress 4.9 that maintains the classic editing experience as a core feature, not a plugin workaround. The ClassicPress community handles security patches, compatibility updates, and the ongoing maintenance of the classic code base. For projects where the classic editor is a requirement and not just a preference, ClassicPress offers a more stable foundation than depending on a plugin to undo the default behavior of a platform that is actively moving away from that behavior.
The practical consideration is ecosystem compatibility. WordPress plugins are tested against WordPress. ClassicPress inherits compatibility with most WordPress plugins that do not depend on Gutenberg, but "most" is not "all." Before committing a project to ClassicPress, you need to audit every plugin in the stack for compatibility. The ClassicPress community maintains compatibility lists, but the definitive test is running your specific configuration and verifying behavior. Budget that testing time into the project plan.
Where Gutenberg Is the Right Choice
This page would be dishonest if it did not acknowledge where Gutenberg genuinely excels. For sites that need flexible visual content layouts, for editorial teams that are comfortable with block based editing, for projects that use the full site editor and block based templates, and for developers who want to build rich interactive content experiences within the WordPress admin, Gutenberg provides capabilities that the classic editor simply cannot match.
Full site editing, block patterns, reusable blocks, and the site editor are powerful features for the right use case. If a project genuinely benefits from giving content editors visual layout control, Gutenberg delivers that in a way that the classic editor with shortcodes and page builders tried to approximate but never fully achieved from within the core editing experience.
The question is not whether Gutenberg is good. It is whether Gutenberg is right for the specific project you are working on. The answer depends on the editorial team, the content type, the development budget, and the long term maintenance plan. For some projects, the answer is clearly yes. For others, it is clearly no. Pretending otherwise in either direction does not help anyone make better decisions. See the official WordPress editor documentation for the current state of block editor features and development.
Cost, Maintenance, and Client Fit
When I scope a WordPress project, the editor choice is one of the earliest architectural decisions. It affects development cost, maintenance cost, training cost, and client satisfaction over the lifetime of the project. Here is how those factors typically break down.
Development cost is higher with Gutenberg if the project needs custom blocks. Building a custom block requires React development, a build pipeline, block registration, editor sidebar configuration, and deprecation handling for future markup changes. Building equivalent functionality in the classic editor with custom meta boxes requires PHP and vanilla JavaScript. The classic approach is faster to build and easier to maintain for developers whose primary skills are in PHP and WordPress development rather than React.
Maintenance cost depends on the rate of change in the editor environment. Gutenberg evolves rapidly. Block API changes, deprecation of block features, and changes to the editor UI can break custom blocks across WordPress updates. The classic editor is stable and changes rarely. For agencies maintaining dozens of client sites, the lower maintenance overhead of the classic approach is a meaningful operational advantage.
Client fit is the most project specific factor. Some clients love the visual flexibility of Gutenberg. Others find it confusing and frustrating. The only reliable way to predict this is to understand the client's editorial workflow, their technical comfort level, and how much time they are willing to invest in learning a new editing interface. Asking the client before making the decision is more reliable than assuming they will adapt.
Making the Decision
My recommendation is straightforward. If the project needs flexible visual content layout and the editorial team is willing and able to work with blocks, use Gutenberg. If the project needs simple content editing, consistent templates, and minimum editorial complexity, use the classic editor. If the project needs the classic editing experience as a permanent architectural commitment rather than a plugin workaround, evaluate ClassicPress.
Do not make the decision based on what is newest. Make it based on what the project needs. The classic editor is not obsolete just because Gutenberg exists, and Gutenberg is not wrong just because the classic editor is simpler. They are different tools optimized for different workflows, and the best choice depends on the specific circumstances of the project in front of you.
For additional notes on ClassicPress migration and compatibility, see the ClassicPress hub. For the broader collection of development resources on this site, visit Resources.