A WordPress update should not leave staff wondering why a familiar page now looks completely different. If your website has several people creating news posts, updating service information or checking contact details, you may need to disable Gutenberg for user roles while keeping it available to trusted administrators. This gives each person an editing experience that matches their responsibilities.
For a disability support provider, consistency matters. A small formatting error on a referral page, service description or contact form can create unnecessary confusion for participants, families and coordinators. Role-based editor settings are not about limiting people unnecessarily. They are about providing clear, reliable tools and protecting approved website content.
When to disable Gutenberg for user roles
Gutenberg is WordPress’s block editor. It is flexible and useful for creating layouts with images, columns, buttons and reusable sections. However, flexibility can also mean more settings, more visual controls and more opportunities to accidentally change a page layout.
The Classic Editor uses a simpler writing screen. For staff who only need to update a phone number, add a short notice or publish a straightforward article, this can be less distracting and easier to follow. It may also suit an established website built with older page templates, shortcodes or plugins that were designed around the classic editing screen.
A common arrangement is to keep Gutenberg enabled for Administrators and disable it for Editors, Authors or custom staff roles. Administrators can manage page design and technical settings, while other users can focus on accurate content. It depends on how your site is managed. If an Editor is responsible for building campaign pages and has received WordPress training, Gutenberg may be the right choice for them.
Do not confuse WordPress user roles with people who receive support. These roles apply only to accounts that log in to administer your website. Participants and family members should never need editor access simply to find information, make an enquiry or understand your services.
Start with roles, permissions and a backup
Before changing the editor, review who has access to the WordPress dashboard. Go to Users and check each account’s role. The standard WordPress roles are Administrator, Editor, Author, Contributor and Subscriber, although your website may have additional roles created by a membership, booking or security plugin.
Avoid making broad changes without a record of the current setup. Take a full website backup first, including files and the database. If you have a staging site, test there before changing the live website. This is particularly worthwhile when your pages use a page builder, custom fields, older shortcodes or an integrated contact and referral system.
It is also helpful to nominate one person as the content owner. They do not need to make every update, but they should know which editor each team uses and who can approve structural changes. Clear ownership prevents the familiar problem of several well-meaning people changing the same page in different ways.
Option 1: Use a role-based editor plugin
For most organisations, a maintained plugin with role controls is the clearest approach. Choose one that specifically states it can disable the block editor by user role, rather than one that only switches Gutenberg off across the whole website.
From the WordPress dashboard, open Plugins, select Add New, search for a suitable Gutenberg-disabling plugin, then install and activate it. Just activate and done is not always the whole story, though. Open the plugin’s settings page and look for controls such as user roles, post types, editor mode or disable block editor.
Set the roles that should use the Classic Editor. For example, you might select Author and Contributor, leave Administrator unselected, then save the settings. Some plugins also allow different rules for posts and pages. That can be useful if staff should write news posts in the Classic Editor but administrators still need Gutenberg to maintain service pages.
After saving, test the result with a non-administrator account. Do not rely only on what you see while logged in as an Administrator, because administrators often retain access by design. Create a temporary test user if needed, assign the relevant role, log in and open an existing draft as well as a new post.
A good plugin should preserve existing content rather than converting or deleting it. Still, open a few older pages after the change. Check headings, links, buttons, images, accordions and forms. If anything looks unusual, restore the backup or reverse the setting before publishing further updates.
Keep the configuration screen restricted
Some editor plugins let you hide their settings from non-administrators. Use this option where available. Staff who need to edit content should not also be able to change the system that controls their editing environment.
This is a practical security measure, not a matter of distrust. Separating content tasks from technical settings reduces the chance of accidental changes and makes troubleshooting much quicker. Administrators should also use individual logins, strong passwords and multi-factor authentication where your hosting or security tools support it.
Option 2: Use a small code rule
If your website is maintained by a developer or an experienced WordPress administrator, a small code rule can disable Gutenberg for defined roles without adding another settings plugin. Add code through a child theme or a code-snippet management tool. Do not edit the parent theme directly, as theme updates can remove the change.
The example below turns off Gutenberg for users with the `editor` or `author` role, while leaving the existing editor setting in place for everyone else.
“`php add_filter( ‘use_block_editor_for_post_type’, function( $use_block_editor, $post_type ) { $user = wp_get_current_user(); $classic_roles = array( ‘editor’, ‘author’ );
if ( array_intersect( $classic_roles, (array) $user->roles ) ) { return false; }
return $use_block_editor; }, 10, 2 ); “`
Role names in code are usually role slugs, not the label you see on screen. A custom role called “Content Team” may have a slug such as `content_team`. Check this carefully before applying the rule. One incorrect line can affect the wrong users or make the dashboard harder to manage.
Code gives precise control, but it needs ongoing ownership. WordPress core, themes and plugins change over time. Record why the snippet was added, which roles it affects and where it is stored. That note will save time when another staff member or web developer reviews the site later.
What this setting does not control
Disabling Gutenberg for a role does not automatically control every visual editing area in WordPress. Depending on your theme and installed plugins, users may still see the Site Editor, widget screens, page-builder panels or custom fields. Those areas have their own permissions and settings.
It also does not replace proper role management. If someone should only publish news articles, do not give them Administrator access just so they can use a preferred editor. Give the lowest level of access that allows them to complete their work. This protects private information, reduces the risk of unwanted changes and keeps responsibilities clear.
If a person needs to update one section of a page but should not redesign it, consider creating a dedicated post type, a structured form or reusable content fields instead of granting broad editing access. The best solution is often a simpler workflow, not another permission.
Test the workflow people will actually use
Once the editor rule is active, ask a staff member to complete a real-world test: update service hours, add a short article, save a draft and submit it for review. Check the workflow on a desktop computer and, if staff use one, a mobile device.
Pay attention to clarity. Can they find the edit button? Do they know whether a change is saved, pending review or published? Are they able to add accessible headings and meaningful image descriptions? A familiar editor is useful only when the publishing process remains clear and safe.
The right setup gives people enough control to keep information current, without asking them to navigate tools they do not need. When roles, editor settings and approval steps are organised with care, your website becomes easier to maintain and more dependable for the people relying on it.
