What is Classic Editor?

Classic Editor is an official plugin maintained by the WordPress team that restores the previous (“classic”) WordPress editor and the “Edit Post” screen. It makes it possible to use plugins that extend that screen, add old-style meta boxes, or otherwise depend on the previous editor.

Is Classic Editor an official WordPress plugin?

Yes, Classic Editor is an official WordPress plugin and will be fully supported and maintained until 2024, or as long as is necessary.

What features does Classic Editor add?

Classic Editor adds the following features:n1. Administrators can select the default editor for all users.n2. Administrators can allow users to change their default editor.n3. Users can choose which editor to use for each post.n4. Each post opens in the last editor used regardless of who edited it last.

Does Classic Editor support other plugins?

Yes, the Classic Editor plugin includes several filters that let other plugins control the settings, and the editor choice per post and per post type.

Does Classic Editor hide the new block editor (Gutenberg)?

Yes, by default, the Classic Editor plugin hides all functionality available in the new block editor (Gutenberg).

Classic Editor - Official WordPress Plugin to Restore Previous Editor

Features Download’s trend Changelog Reviews

Restore Classic Editor

Brings back the familiar editing experience.

The Classic Editor plugin allows users to revert to the previous WordPress editor, giving them a more familiar and comfortable editing experience. This is especially useful for those who prefer the old editor or rely on plugins that are not compatible with the new block editor.

Customizable Default Editor

Choose the editing experience that suits you.

Author’s Site

1.6.3

Added some WPCS fixes, props NicktheGeek on GitHub.
Updated “Tested up to” in the readme and removed it from classic-editor.php. This should fix false positive errors in security plugins in the future.

1.6.2

Fixed bug that was preventing saving of the last used editor.

1.6.1

Fixed a warning on the block editor based widgets screen.
Fixed use of a deprecated filter.

1.6

Updated for WordPress 5.5.
Fixed minor issues with calling deprecated functions, needlessly registering uninstall hook, and capitalization of some strings.

1.5

Updated for WordPress 5.2 and Gutenberg 5.3.
Enhanced and fixed the “open posts in the last editor used to edit them” logic.
Fixed adding post state so it can easily be accessed from other plugins.

1.4

On network installations removed the restriction for only network activation.
Added support for network administrators to choose the default network-wide editor.
Fixed the settings link in the warning on network About screen.
Properly added the “Switch to classic editor” menu item to the block editor menu.

1.3

Fixed removal of the “Try Gutenberg” dashboard widget.
Fixed condition for displaying of the after upgrade notice on the “What’s New” screen. Shown when the classic editor is selected and users cannot switch editors.

1.2

Fixed switching editors from the Add New (post) screen before a draft post is saved.
Fixed typo that was appending the edit URL to the classic-editor query var.
Changed detecting of WordPress 5.0 to not use version check. Fixes a bug when testing 5.1-alpha.
Changed the default value of the option to allow users to switch editors to false.
Added disabling of the Gutenberg plugin and lowered the required WordPress version to 4.9.
Added classic_editor_network_default_settings filter.

1.1

Fixed a bug where it may attempt to load the block editor for post types that do not support editor when users are allowed to switch editors.

1.0

Updated for WordPress 5.0.
Changed all “Gutenberg” names/references to “block editor”.
Refreshed the settings UI.
Removed disabling of the Gutenberg plugin. This was added for testing in WordPress 4.9. Users who want to continue following the development of Gutenberg in WordPress 5.0 and beyond will not need another plugin to disable it.
Added support for per-user settings of default editor.
Added support for admins to set the default editor for the site.
Added support for admins to allow users to change their default editor.
Added support for network admins to prevent site admins from changing the default settings.
Added support to store the last editor used for each post and open it next time. Enabled when users can choose default editor.
Added “post editor state” in the listing of posts on the Posts screen. Shows the editor that will be opened for the post. Enabled when users can choose default editor.
Added classic_editor_enabled_editors_for_post and classic_editor_enabled_editors_for_post_type filters. Can be used by other plugins to control or override the editor used for a particular post of post type.
Added classic_editor_plugin_settings filter. Can be used by other plugins to override the settings and disable the settings UI.

0.5

Updated for Gutenberg 4.1 and WordPress 5.0-beta1.
Removed some functionality that now exists in Gutenberg.
Fixed redirecting back to the classic editor after looking at post revisions.

0.4

Fixed removing of the “Try Gutenberg” call-out when the Gutenberg plugin is not activated.
Fixed to always show the settings and the settings link in the plugins list table.
Updated the readme text.

0.3

Updated the option from a checkbox to couple of radio buttons, seems clearer. Thanks to @designsimply for the label text suggestions.
Some general updates and cleanup.

0.2

Update for Gutenberg 1.9.
Remove warning and automatic deactivation when Gutenberg is not active.

0.1

Initial release.

Musthave!

By zimdin12 on April 11, 2024

If you do not wish to use react or gutenberg then this is perfect.

I do not wish to use react and it is sad that i cannot remove it from the stack. Framework should include something robust and lightweight. everything else should be optional. gutenberg should be a plugin not core part of WP.

also not all sites should be "pagebuilders". if most of the gutenberg's features are not used then why should you have it? Just for giving a option for modes and admins to break the page?
Or if you want to build it as "unbreakable" then try to make it clear why you had to put in the extra work just to protect the site from internal people.

I do currently use roots packages (sage, acorn, bedrock) + lots of laravel like personal solutions. + ACF.
It has been quite good and fast flow. no need to develop admin panel etc.

but it seems that WP is turning against those things that made WP good. is it worth to remove so much. I think that soon it is more logical to start building directly on laravel with good CMS on top of it (it seems that there are much more CMS packages out there than couple years back.. time goes fast).

But this is just my opinion. trying to find ways how to create good sites with superb codebase (both FE and BE). I love this plugin and I hope it will stay working and supported.