Classic Editor plugin review and common issues

Go to Settings → Writing and verify “Default editor for all users” is set to “Classic Editor.” Also ensure “Allow users to switch editors” allows individual users to select Classic Editor. After saving, log out and log back in, then open the page in the editor — it should show the WPBakery backend editor. If still showing Gutenberg, check that the Classic Editor plugin is active and no other plugin is forcing Gutenberg for that post type. Some page builder themes also have their own editor preference settings that override Classic Editor.

The TinyMCE toolbar has two rows — the second row is collapsed by default. Click the “Toolbar Toggle” button (the last button in the first toolbar row, which looks like a paragraph symbol or toggle icon) to expand the full second toolbar row with additional formatting options. If the toggle button is missing or the toolbar is still limited, a plugin may be modifying the TinyMCE configuration — temporarily deactivate other plugins to identify any that alter the editor toolbar. Also verify the browser’s zoom level is not causing toolbar buttons to overflow out of view.

Some post types may explicitly declare support for the block editor in their registration (show_in_rest => true combined with supports including “editor”). Classic Editor respects these declarations. Override this by adding a filter in your theme or plugin: add_filter(“use_block_editor_for_post_type”, function($use, $post_type) { if ($post_type === “your_post_type”) return false; return $use; }, 10, 2); This forces Classic Editor for the specified post type regardless of its registration settings.

Go to Settings → Writing. Under “Classic Editor Settings,” set “Allow users to switch editors” to “Yes.” With this option enabled, each post and page will show a small switcher in the edit screen header allowing the current user to toggle between Classic and Block editor for that specific post. Users can also set their default preference in Users → Profile. This is useful for teams where some members prefer Gutenberg and others prefer Classic Editor during a transition period.

Classic Editor affects the post and page editor only — it does not affect the Site Editor (Appearance → Editor) which is used for FSE theme customization. With Classic Editor active, posts and pages use the TinyMCE interface, while the FSE theme’s Site Editor remains Gutenberg-based. If your FSE theme uses template parts and block patterns for the post layout, Classic Editor content still renders correctly — the classic editor only changes the editing experience, not the rendered output.

Classic Editor is actively maintained and safe to use. The plugin is an official WordPress plugin, reviewed by the security team, and updated as needed. The functional concern is long-term: WordPress’s new features (synced block patterns, Site Editor, Block Themes) are Gutenberg-native. Sites remaining on Classic Editor indefinitely will progressively miss new WordPress capabilities. For sites where the migration cost to Gutenberg outweighs the benefits — particularly content-heavy sites with established workflows — Classic Editor remains a practical choice. Plan for eventual migration rather than indefinite dependency.

No — Classic Editor only restores the post/page editor. The block-based widget editor (introduced in WordPress 5.8) is separate. To restore the classic widget editor (Appearance → Widgets), install the official Classic Widgets plugin separately. Many sites run both Classic Editor and Classic Widgets together to maintain the pre-Gutenberg WordPress experience across the admin.

Yes, that can happen, especially on older sites with many plugins. This usually happens when the plugin, theme, and add-ons are updated out of sequence. In most cases, testing on staging catches the issue before it reaches the live site. From experience, backups and changelog reviews save a lot of cleanup time.

Start by checking whether another plugin already does the same job. In most cases, overlap is what creates avoidable conflicts and performance issues. A common issue is installing a plugin because it looks convenient without checking the stack first. From experience, a short compatibility review avoids most of the pain later.