No Gutenberg? - Choose Where to Use the Block Editor or the Classic Editor — Full changelog

For each release, see the entries below. The latest version is always at the top.
The current release notes also live in readme.txt under "== Changelog ==".

= 2.4.0 =
* New: A Classic Editor configuration found on the site can be imported here. The page says what was found and then lists, line by line, what importing it would write and what it would clear, with a button to keep the settings you already have. It is offered once, because Classic Editor deletes its own settings when it is removed
* New: A warning when Classic Editor is running at the same time as this plugin. Both of them choose which editor opens, through the same WordPress filters, and the one that runs last wins
* Improved: The whole configuration is on screen at all times. The master switch used to hide the rest of the page, which read as there being nothing left to decide while two of the hidden settings could take the styles off content that was already published
* Improved: The site wide items are decided on their own, with the master switch checked or not. A complete disable used to force every one of them on, so the two that reach the frontend could not be turned off on a site with block content, and saving the page put them back
* Improved: A warning next to the site wide items whenever the block styles are being removed from a site that needs them, with the number of entries it affects
* Improved: The settings page now confirms when settings are saved, which it never did
* Improved: The settings page was laid out again. Every box on it ends on the same pixel, and what the plugin is doing to the site is a panel that belongs there, instead of looking like a notice waiting to be dismissed
* Fix: Installing on a site that already has content built with blocks no longer removes the block CSS and neutralizes theme.json. Those entries kept the block editor, so their markup was safe, but visitors saw them with no styles, no layout and no spacing presets. Both options now start unchecked on a site with block content or a block theme, and the page says why
* Fix: The activation notice said that block content would keep the block editor so nothing would break its markup, while the same configuration had just taken its styles off the frontend. It now also says what was left in place, and why
* Fix: The status panel reported the frontend block assets and theme.json as removed whenever the master switch was checked, whatever the real setting said
* Fix: Activating the plugin for a whole network configured only the site the network administrator was on. Every other site of that network was treated as one coming from before 2.3.0, so it ended up with the protection of existing block content off and the block styles removed from the frontend. Each of them now gets the defaults of its own site the first time its admin is opened. This is about networks activated from this version on: on a network that was already activated, every site keeps what it has
* Fix: Updating gives the block styles back to a site that has content built with blocks and was serving it with none. Until this version the master switch forced the frontend block assets and the theme.json item on while it was checked, so on those sites nobody chose that: the stored value could not even be read back, and the settings page showed a state that was not the real one. A site that had the master switch unchecked did choose, so its two values are left exactly as they are and the settings page warns about them instead
* Fix: A site with no configuration of its own, which is what a site of a network activation has until somebody opens its admin there, no longer removes the block styles while it waits. Nothing has looked at whether that site needs them yet, and removing them is the half that cannot be undone by reading the page
* Fix: Uninstall also removes the stored Classic Editor detection

= 2.3.2 =
* Fix: Sites running Divi 5 got a fatal error on every frontend page. Removing the block widgets from the classic Widgets screen unregistered the Block widget itself, and Divi asks WordPress for it while deciding which stylesheets a page needs. The classic Widgets screen is restored the same way as before, without touching the widget
* Fix: Block widgets already saved on a site stopped being rendered on the frontend and disappeared from the Widgets screen. Nothing was lost, they are back on update, but do not save the Widgets screen while running 2.3.1
* Fix: Removed a filter removal that never did anything: the callback it named was never part of WordPress
* Fix: The status panel said "1 still added by other plugins" when a single pattern was left, and gave translators two identical plural forms

= 2.3.1 =
* Improved: Tested up to WordPress 7.1, with no changes needed. The always iframed post editor, the persistent toolbar and the new client-side media processing headers only reach the block editor, and the Site Editor, Patterns and Fonts screens this plugin removes keep the same slugs
* Improved: The plugin calls itself No Gutenberg? everywhere now, the same name it has on WordPress.org, instead of No Gutenberg in the plugins list, the Settings menu, its settings screen and its notices
* Fix: Pages were loading the block styles and scripts of every plugin that registers blocks, even where no block appears. Removing the block CSS also turned off the on-demand loading that WordPress 6.8 tied to the same switch, so on a site with block plugins installed this plugin was adding weight instead of saving it
* Fix: The Block widget is now really gone from the classic Widgets screen. The cleanup ran after WordPress had already registered it, so it stayed on the list

= 2.3.0 =
* New: Existing block content is protected. An entry that already contains blocks keeps the block editor whatever the rules say, so installing the plugin on a site with mixed content no longer sends that content to an editor that reflows its markup. A checkbox under the master switch gives the protection up when you really want the Classic Editor on everything
* New: The entries list says which editor each entry opens with, and flags the entries built with blocks that are opening in the Classic Editor. A "Built with blocks" link next to All and Published narrows the list down to them, so you can finally see which entries they are instead of only how many
* New: The Classic Editor warns you when the entry you are editing is built with blocks, before you save it, with a link to open it in the block editor instead
* Improved: The editor chosen for a single entry is now honored whatever the configuration is, master switch included. It used to be read only where per entry switching was enabled, which left no way out on a site with everything disabled
* Improved: Sites arriving from the Classic Editor plugin keep the editor it recorded for each entry, instead of starting from zero
* Improved: The status panel counts drafts, pending, private and scheduled entries too, not only published ones, and links to the entries it is counting. A site in the middle of a migration was being told it had no block content
* Improved: The activation notice says how many entries are built with blocks and what is going to happen to them
* Fix: Uninstall now also removes the version option, the per entry editor meta and the content count transients

= 2.2.0 =
* New: Optional settings page under Settings > No Gutenberg, built around a single master switch. Leave "Disable Gutenberg completely" checked and the plugin works exactly as it always did, with no setup. Uncheck it and you choose what to disable. Every checkbox means the same thing, so no setting ever undoes another one
* New: Rules to disable the block editor by post type, by user role, by page template and by individual entry IDs. Rules are independent: anything that matches gets the Classic Editor
* New: Optional editor switching, enabled per post type next to its rule. Adds "Edit (Classic)" and "Edit (Blocks)" links to the entries of that post type and a switch inside both editors, and remembers the choice for each entry. The choice wins over every rule, in both directions, so one page can stay classic while its post type keeps blocks, or the other way around
* New: Status panel that reports what is really happening on your site: block patterns blocked, weight saved on every page, Global Styles, widgets, Site Editor, active theme, and how much of your published content is actually built with blocks
* New: Site wide pieces can be turned off one by one once the master switch is off: classic widgets, block patterns, frontend block assets, theme.json and Global Styles, Site Editor blocking and block theme notices
* New: Configuration can be fixed from wp-config.php with NO_GUTENBERG_OPTIONS, and the settings screen locked as read only with NO_GUTENBERG_LOCK_SETTINGS or hidden with NO_GUTENBERG_HIDE_SETTINGS, for agencies and managed sites
* New: Cleanup on uninstall. Plugin settings, dismissed notice user meta, and notice transients are removed when the plugin is deleted
* Improved: WooCommerce is no longer an all or nothing switch. Its product editor now follows the same rules as any other post type, so leaving blocks on for products really leaves them on, and its block styles are removed along with the rest of the frontend block assets
* Improved: The block theme warning is now shown only on the Dashboard and Appearance screens, and its dismiss script is properly enqueued instead of printed inline
* Improved: Site Editor menu removal now covers the Patterns menu slug introduced in WordPress 6.8 and the Fonts screen introduced in WordPress 7.0
* Improved: Minimum required WordPress version raised to 6.1, which is what the plugin features actually need
* Fix: Block patterns are now really removed. The previous cleanup hooked itself on an init priority that had already run, so core and theme patterns kept being registered, and it relied on remove_all_actions(), which would have wiped other plugins' callbacks had it ever run
* Fix: The Global Styles inline CSS and the per-block inline styles are now really removed from the frontend. Dequeuing the style handles was not enough, because Global Styles are printed inline
* Fix: The WooCommerce block styles are now really removed too. They are enqueued while the blocks render, long after the point where the plugin used to look for them, so they were always printed in the footer regardless of the setting
* Fix: Theme support removals now run after the active theme registers them, so disabling the FSE features takes effect on every theme
* Fix: Removed dead legacy code (Gutenberg feature plugin hooks, pre-5.0 branch, duplicated filters, a no-op editor setting) and unified duplicated WooCommerce asset removals

= 2.1.2 =
Tested up to WordPress 7.0

= 2.1.1 =
* Fixed headers already sent error on plugin activation

= 2.1.0 =
* Added removal of Patterns submenu from Appearance menu (introduced in WP 6.5+ for all themes)
* Added removal of Site Editor submenu
* Added blocking of direct access to Site Editor pages
* Better compatibility with WordPress 6.5+ changes

= 2.0.1 =
* Tested up to WordPress 6.9

= 2.0 =
* Complete plugin rewrite with object-oriented approach
* Added removal of FSE Global Styles and theme.json support
* Disabled block-based widgets completely
* Removed block patterns and block directory
* Added WooCommerce blocks removal
* Eliminated all block-related CSS and JavaScript assets
* Added activation notice and support links
* Improved performance by removing more block overhead
* Better code organization and security
* Updated minimum PHP requirement to 7.4
* Network/Multisite compatible

= 1.1.0 =
* Fix Fatal Error with prior version

= 1.0.9 =
* Tested up to WordPress 6.7.1

= 1.0.8 =
* Tested up to WordPress 6.6.2

= 1.0.7 =
* Tested up to WordPress 6.4

= 1.0.6 =
* Tested up to WordPress 6.2

= 1.0.5 =
* Tested up to WordPress 6.1

= 1.0.4 =
* Tested up to WordPress 6.0.2

= 1.0.3 =
* Tested up to WordPress 6.0

= 1.0.2 =
* Added the action to remove the FSE Global Styles

= 1.0.1 =
* Better and simply readme file

= 1.0.0 =
* Initial release with basic Gutenberg removal
