Choose the Editor Around the Content Workflow
Separate Editor Choice From Frontend Styles
The Remove Frontend CSS option is on by default. It can remove block-related styles, including supported wp-block styles, WooCommerce block CSS, global styles, and classic-theme styles. This deserves attention even when your main reason for enabling the module is simply to change the editor. A page may still depend on block styling because of its existing content or other components, so editor preference alone is not a reason to assume every block stylesheet is unnecessary.
In Specific mode, frontend CSS removal runs only when the current singular post type is one of the disabled types. That is narrower than removing block styles from every page, but it still needs a content check. Review affected pages and keep the CSS option off where those styles are required. The module does not automatically rebuild a page’s design to compensate for removed stylesheets.
Keep Existing Blocks Separate From the Editing Policy
Switching an editing screen does not convert the blocks already stored in that post. Disable Gutenberg leaves the saved content in the database as it is; it is not a migration tool that rewrites every block into a new format. That distinction is particularly important when taking over an established site. Review representative content before applying a broad editor policy rather than assuming the switch also transforms old layouts.
If the goal is to keep Gutenberg but reduce the blocks editors can insert, use Gutenberg Block Control instead. It restricts available block types rather than replacing the editor. The two modules conflict and should not be enabled together. Choose Disable Gutenberg for classic editing, or Block Control when the Block Editor remains part of the workflow.
