Grids vs No Gutenberg? – Choose Where to Use the Block Editor or the Classic Editor

👉 For more information about the plugin, visit the documentation website. A layout builder is a tool that helps you creating visual structures in your page, from a simple layout made by adjacent columns, to more complex compositions. Grids is entirely based on the WordPress block editor, which means that you’ll be able to use it together with the myriad of content blocks that developers and designers from all around the World are creating. With Grids, we’re bringing a visual structure to the content written with the WordPress Block Editor. 👉 Sections & areas A Section is a portion of the page that aims at being visually distinct from the rest of the content. Sections are usually top-level blocks that you add one after the other; the sequence of sections is what makes your page layout. Each Section that you create is composed by several different Areas. In their most basic form, you can think of Areas as columns, which are nothing else than containers for content blocks. For more elaborated compositions, the Grid Designer allows you to create exactly the grid structure you want within the boundaries of a Section, by using CSS Grid. 👉 Want to know more? Read the plugin documentation! 👉 https://justevolve.it/grids/documentation/ 👉 Still struggling? That may depend on one of the known issues 👉 https://justevolve.it/grids/documentation/known-issues/ 👉 1.3.12 FIX: Prevented admin assets from being enqueued on the frontend. 👉 1.3.11 FIX: Message regarding translations being loaded too early FIX: Styles and scripts correctly load in the editor iframe FIX: Compatibility with WordPress 6.9 👉 1.3.10 FIX: Compatibility issues with WordPress 6.4 👉 1.3.9 FIX: Security fix. 👉 1.3.8 FIX: Fixed display settings functionality for sections and areas. 👉 1.3.7 FIX: Fixed a fallback variable issue for Sections and Areas background. 👉 1.3.6 FIX: Fixed an issue with the margins, paddings association on different media queries. FIX: Fixed background repeat and position default behavior on frontend. 👉 1.3.4 & 1.3.5 FIX: Synced row dimension logic on frontend/backend: empty rows will collapse also on the Block Editor screen. 👉 1.3.3 FIX: Fixed 500 error that occurred when using wide-aligned sections. 👉 1.3.2 FIX: Changed the grid column declaration to minmax(0,1fr) in order to prevent grid blowout. FIX: Fixed nested sections issues. 👉 1.3.1 FIX: Reverted row dimension logic: in Sections created with the advanced editor, empty rows will collapse. 👉 1.3.0 ENHANCEMENT: Added compatibility with the Full Site Editor. ENHANCEMENT: Enhanced compatibility with single page application websites. FIX: Fixed style being applied to nested sections. Updated compatibility to WordPress 5.9. POSSIBLY BREAKING CHANGES: In this version, we have removed the global page setting that allowed for the editor area to be wider when editing a page with the Block Editor. We feel that this should be better handled by the theme itself, especially if it supports the Full Site Editing mode. We have also removed the global page setting that determined the horizontal gutter between areas. This is now handled individually by Section blocks (look for Gap settings). As before, both horizontal and vertical gaps are subject to media queries. We have removed the grids-s-$section_id and grids-a-$area_id classes from their respective elements, since they were no longer needed to generate the element’s style. If you need to specifically identify a section or area, you can use their custom class/anchor controls provided by the Block Editor. 👉 1.2.28 ENHANCEMENT: Added the ability to specify the types of blocks allowed in content areas of a section through the grids/area filter. ENHANCEMENT: Added the ability to specify the size units used in Grids, as well as the default size unit suggested by the editor, through the grids/general filter. FIX: Removed unwanted log to console. Updated compatibility to WordPress 5.7. 👉 1.2.27 FIX: Fixed an issue that occurred when editing custom-created sections and affected previously created areas. FIX: Fixed an issue that prevented post meta to be saved when using Grids with a Custom Post Type. 👉 1.2.26 FIX: Added compatibility with WordPress 5.6 and the latest version of the Gutenberg plugin. 👉 1.2.25 FIX: Minor backend UI fix. FIX: Fixed the dimensioning of blocks in content areas on frontend. 👉 1.2.24 Enhanced support for AJAX-powered content pages. 👉 1.2.23 FIX: Fixed React warnings and errors that occurred when the SCRIPT_DEBUG constant was set to true. FIX: Fixed section styling when in preview mode. FIX: Removed double scrollbar when dragging areas. 👉 1.2.22 FIX: Increased compatibility with WordPress 5.4. 👉 1.2.21 FIX: Fixed a bug that caused section IDs not to be rendered in the page markup. 👉 1.2.20 FIX: Fixed compatibility with Gutenberg 7.3. 👉 1.2.19 FIX: Fixed blocks toolbar issue. 👉 1.2.18 FIX: Fixed reusable block functionality on Sections. FIX: Various minor UI tweaks. FIX: Minor bugs. 👉 1.2.17 FIX: Fixed compatibility with Gutenberg 7.2. FIX: Minor UI tweaks. 👉 1.2.16 FIX: Fixed grid display issues on Internet Explorer 11. Thanks to @amddtim for providing the fixes. 👉 1.2.15 Improved the visualization of units in spacing controls. Added an option to expand the editor width. 👉 1.2.14 FIX: Fixed compatibility with WordPress 5.3. 👉 1.2.13 FIX: Fixed a z-index issue for the area selection highlight. FIX: Fixed an issue that prevented the correct display of duplicated sections. 👉 1.2.12 FIX: Improved the editing of blocks in two vertical adjacent areas in an advanced grid. FIX: Fixed an area width display issue in the block preview. 👉 1.2.11 Added visual feedback to elements when using dimension controls. FIX: Fixed a regression that prevented the correct use of vertical align in Areas. 👉 1.2.10 FIX: Fixed a bug that prevented Sections to be saved correctly when they have an anchor specified. FIX: Minor UI tweaks. 👉 1.2.9 Added anchor support to Sections: you can now add IDs to Section elements on frontend. Various UI tweaks to highlight the grid structure and rendering. Removed the Section block from the Grids section, and made available in the Layout blocks section. Changed the Section and Area block icons to match the plugin brand. FIX: First block selection after inserting a Section in page. FIX: Minor bugs. 👉 1.2.8 FIX: Style alignment for areas when duplicating sections in the Block Editor. 👉 1.2.7 FIX: Restore block insertion mode for newly created areas when using the Gutenberg plugin. FIX: Compatibility fixes with Gutenberg 5.9.0. 👉 1.2.6 FIX: Behavior of content areas when adding lateral spacing. 👉 1.2.5 Added a new “Stretch” option for backgrounds on sections with “wide” alignment. FIX: Minor bugs. 👉 1.2.4 Submitted Grids to the Blocks directory on WordPress.org. Include JS and SCSS source files. 👉 1.2.3 FIX: Fixed an issue that prevented to properly visualize the Block Inserter when the z-index of an area had been tweaked. FIX: Fixed an issue that could cause multiple areas to be added to a section, without using the Grid Designer component. FIX: Minor bug fixes. 👉 1.2.2 FIX: Fixed an issue that prevented custom accent colors to work as intended on the Twenty Nineteen default theme. 👉 1.2.1 FIX: Minor visual tweaks. FIX: Editing of sections composed with the Grid Designer. 👉 1.2 NEW FEATURE: Added page-wide gutter control. ENHANCEMENT: Grid Designer is now available when editing a section, and areas can be rearranged. FIX: CSS style for grids not displaying in loops. FIX: Sections can now be used as reusable blocks. FIX: Minor bugs. 👉 1.1.1 FIX: Translation support. FIX: Issue with blocks toolbar. 👉 1.1.0 NEW FEATURE: Grid Designer. FIX: Translation support. FIX: Minor bugs. 👉 1.0.0 Initial public release.

The most configurable way to leave the block editor behind. Activate it and everything block related is gone: the block editor, Global Styles, patterns, block widgets, the Site Editor and the block CSS and JavaScript that every page loads. From there you decide the scope: everywhere, or only for the post types, roles, templates and entries you choose. What this plugin removes: Core Gutenberg Features Gutenberg Block Editor (completely disabled) Full Site Editing (FSE) Global Styles and inline CSS Block-based Widget Editor (reverts to Classic Widgets) Block Patterns and Pattern Directory Theme.json support and processing Block Directory integration Site Editor functionality Performance Optimizations The block library CSS and JavaScript that every page loads The Global Styles inline CSS, which dequeuing the handle never reaches The block assets of any other plugin that registers blocks, on pages where no block appears The block editor assets in the admin, wherever the Classic Editor is the one opening WooCommerce Integration The block based product editor, which follows the same rules as any other post type The WooCommerce block styles and scripts, removed along with the rest of the block assets Nothing else: leave blocks on for products and the block product editor keeps working Admin Experience Removes the welcome panel that promotes the block editor Removes the Patterns submenu from the Appearance menu (WP 6.5+) Removes the Fonts submenu from the Appearance menu (WP 7.0+) Blocks access to Site Editor pages Shows activation success notice Warns you when a block theme is active Adds settings and support links to plugin actions A default that asks nothing, and a settings page for everything else – Activating the plugin disables the block editor and every block feature across the site, which is what most people install it for. The rest of this page is about wanting less than that. Full control when you need it – The settings page lives under Settings > No Gutenberg?, built around one master switch. Leave it on and the whole site keeps the complete disable. Turn it off and you decide where the block editor goes away: by post type, by user role, by page template or by individual entry. The site wide pieces (classic widgets, block patterns, frontend block assets, theme.json and the Site Editor) are then yours to keep or remove one by one. Every checkbox means the same thing, so no setting ever undoes another one. Switch editors entry by entry, where it makes sense – Editor switching is chosen per post type, right next to the rule that disables the block editor. Enable it for pages, for instance, and every page gets “Edit (Classic)” and “Edit (Blocks)” links in the list plus a switch inside both editors, while your posts stay untouched. Each entry remembers the editor chosen for it, and that choice beats the rules in both directions: one landing page can stay on the Classic Editor while the rest keep blocks, or the other way around. It tells you what it is doing – The settings screen opens with a status panel for your particular site: how many block patterns are being blocked, how much weight is off every page, whether your theme is a block theme, and how much of your published content is really built with blocks. That last number is the one that should decide whether you strip the block styles from the frontend or not, and no other plugin tells you. Built for agencies and managed sites – The whole configuration can be fixed from wp-config.php, and the settings screen locked as read only or hidden altogether, so a site you deliver keeps the setup you left behind. A whole network configured in one file – This is where the plugin stands alone. Every single setting it has, and not just which editor opens, can be written in wp-config.php, the same file every site of a multisite network reads. A network of a hundred sites is set up once, all of them with the same rules, all of them with the same block CSS gone, and none of them able to drift away from it. The plugin can also be network activated and left alone, because settings are stored per site, so a network can equally let each site decide for itself. Same mechanism as the locking above, and this is how it is written. One configuration for a whole network, or for a site you deliver Everything the settings screen does can also be written in wp-config.php, where nobody changes it by accident, and what you write there wins over whatever is stored in the database. It is the same file for every site of a multisite network, so it is also how you set up a network without repeating the configuration site by site. Add the lines you need above the comment that says “That’s all, stop editing! Happy publishing.” To disable Gutenberg everywhere and leave no settings screen for anyone to touch, which is the usual setup both for a network and for a site you hand over to a client: define( 'NO_GUTENBERG_OPTIONS', array( 'complete' => true ) ); define( 'NO_GUTENBERG_HIDE_SETTINGS', true ); Drop that second line and the settings page is still there, showing the configuration the site is really running, but read only. And if all you want is to lock the screen, leaving the configuration as each site has it stored: define( 'NO_GUTENBERG_LOCK_SETTINGS', true ); NO_GUTENBERG_OPTIONS takes any of the settings on the screen, so a selective setup is written the same way: define( 'NO_GUTENBERG_OPTIONS', array( 'complete' => false, 'disable_post_types' => array( 'post', 'page' ), 'disable_roles' => array( 'editor', 'author' ), 'frontend_css' => false, ) ); The keys are the settings on the screen. complete, widgets, patterns, frontend_css, theme_json, site_editor and fse_notices take true or false, while disable_post_types, disable_roles, disable_templates and switch_post_types take an array of slugs, and disable_ids an array of entry IDs. Any key you leave out keeps the value stored on the site. Note that defining NO_GUTENBERG_OPTIONS already turns the whole screen read only, so NO_GUTENBERG_LOCK_SETTINGS is not needed on top of it. It fits sites that: – Work better in the Classic Editor and want it back – Run classic themes and plugins that were never built around blocks – Are paying for block CSS and JavaScript on pages with no blocks in them – Need the Classic Editor for everyone except a few post types, roles or people – Are a multisite network that wants the same editing experience on every site Support Need private support or custom development? Do you need one-on-one help, priority troubleshooting, or a custom feature, integration, or tweak built specifically for your site? I offer private support and custom development. Just contact me and tell me what you need. Need help or have suggestions? Official website WordPress support forum YouTube channel Documentation and tutorials Love the plugin? Please leave us a 5-star review and help spread the word! About AyudaWP We are specialists in WordPress security, SEO, and performance optimization plugins. We create tools that solve real problems for WordPress site owners while maintaining the highest coding standards and accessibility requirements.