Many clients aren’t familiar with WordPress and have never used a CMS before, so handing it off to them with unlimited access to the backend is like giving them a live grenade. Things are gonna get messy. They may mess up your design, or worse, break the entire site. Then it is left to you to pick up the pieces. That’s why it is best to get ahead of this possible disaster and take the time to set your client up with the right user role settings. This ensures they can access only the parts of the site they need and nothing more.
Divi’s Role Editor is a magnificently easy-to-use solution for client hand-off. With its simple interface, you can easily enable and disable permission settings for each of the user roles giving you full control over what the client can see and use inside the Divi Builder.
Today I’m going to show you how to configure your user role settings for handing off a site to your client. I know that all clients are different, so think of this as a general best practice for most clients.
Let’s get started!
Understanding User Roles
In WordPress, you can choose from 5 different roles to give your users. Here is a quick breakdown of each of these user role capabilities:
Administrator – Has access to everything. No limitations.
Editor – Has access only to edit all pages, all posts, all comments, all categories, all tags, and all links. Doesn’t have access higher level settings like themes, plugins, or core files.
Author – Only has access to their own posts. This includes editing, uploading photos, and publishing posts.
Contributor – Has access to write and edit their own posts, but not the ability to publish.
Subscriber (follower) – capable of receiving updates and only has the capability to read and comment on posts and pages.
Understanding these role options, only two have the capability of making ongoing edits to all pages and posts – administrator and editor. You probably don’t want to risk giving your client the administrator role. This gives them complete control of your site including the capability of messing with themes, plugins, and core files. A better option for a client would be the editor role. That way they don’t break anything too important. Plus it simplifies things for the client giving them a less overwhelming CMS to deal with. For example, check out the difference between the WordPress dashboard menu for administrators and editors.
Here is the dashboard menu for administrators:
Here is the dashboard for users with the editor role:
There are less options and less clutter in the editor role dashboard menu. Your client will like this simplicity.
Assign your client the Editor Role
You can assign your client a new user role from the WordPress Dashboard. Go to Users → Add New. Enter your client’s information and select the “Editor” role for the role option.
After you select Editor. Click the blue Add New User button.
Now Customize Divi’s Role Editor Settings for the Editor Role
Although your client has an editor role with certain limitations to WordPress, the client still has access to all things Divi. This can become a problem if you don’t want clients messing up your core design features and layouts that you worked so hard on using the Divi Builder. That’s where the Divi Role Editor comes in handy.
The Divi Role Editor allows you to limit user role capabilities for Divi specifically.
You can access the Role Editor in the WordPress dashboard under Divi → Role Editor.
Notice you have four different roles you can choose to customize – Administrator, Editor, Author, and Contributor. Subscriber is not listed here since that role has zero editing capabilities by default.
Select the Editor tab to edit the role settings for editors.
High Level Actions
The first row of options contains the high level actions or capabilities:
Here is a brief overview of each of these options:
Divi Library – access to saved templates and modules.
Split Testing – access to enable and perform split testing
Page Options – the options at the top right when editing page that allows you to access settings for Dot Navigation and Hide Nav Before Scroll.
Portability – capability to import and export Divi Builder Layouts.
Since these are all capabilities only an administrator normally uses, I would suggest disabling all of these for your client’s editor role.
Note: One possible exception I would make here would be access to the Divi Library. This may be useful for clients who have been coached on how to use pre-made templates and want the ability to generate new templates easily for things like landing pages.
The next row of options are for the Divi Builder Interface.
On this row I suggest disabling every option except two – Edit Item and Use Visual Builder.
This allows the client to edit what is already there without the ability to add or move any content. The result is a streamlined builder interface your client will appreciate.
Here is an example screenshot of what the Divi Builder Interface looks like before changing the settings:
And here is a screenshot of the Builder Interface with the changes in place:
Notice certain options and buttons are missing. This is because the high level options and most of the Builder Interface options have been disabled. What I like about this setup is that the client is less overwhelmed with choices making easy for them to make edits to the content.
The next section of role capabilities is the Library Settings. Since we already disabled Library Settings at the high level, these options are disabled by default. (If you wanted to enable the Library Settings but limit the functionalities within the Library Settings, you would do that here.) Go ahead and mark them disabled just so there is no confusion.
The next row includes the actions for the Settings Tab. These control the settings for each module and include three types: General Settings, Advanced Settings, and Custom CSS.
I suggest the following options for the Settings Tab Section:
General Settings: ENABLE
Advanced Settings: DISABLE
Custom CSS: DISABLE
I suggest keeping the General Settings enabled because this allows the client to change the actual content of the module like headings, subheading, text, images, etc…
I suggest disabling Advanced Settings and Custom CSS because this is where most of your design and development is built. And a client could easily start making edits that will conflict with the overall design and layout of the site.
Now when your client clicks to edit a module’s settings they will not see Advanced Settings or Custom CSS tabs. Also notice that there is no option to save and add to library at the bottom left:
The next row of role capabilities is the Setting Types. This controls which type of settings can be edited within the Module Settings. Here are my suggested options for the Setting Types section:
Edit Colors: DISABLED
Edit Content: ENABLED
Edit Fonts: DISABLED
Edit Buttons: DISABLED
Edit Layout: DISABLED
Edit Configuration: DISABLED
I suggest disabling everything but Edit Content here. Limiting the client’s ability to edit colors, fonts, and other design elements will ensure the design of the site stays intact.
The next section of role capabilities is Module Use. These options give you the ability to limit the user’s access certain modules.
Since we already disabled the ability to add/delete an item under Builder Interface, the client will not be able to add modules, only edit them. However, you can use the Module Use section to disable the client’s ability to access modules completely. But since we are already limiting the client to editing only content for modules, I think we can keep all modules enabled.
If you want to give the client the ability to add modules, you must first enable the option Add/Delete Item under the Builder Interface section above.
After that I would suggest only giving them access to the modules that you want them to add or edit and get rid of everything else. For example, if you don’t have an ecommerce site, you would definitely want to disable the Shop Module. Or, if your client is going to be writing blog or page content using the Divi Builder, you will want to give them access to the Text Module and maybe the image and button modules as well. Then disable the rest. It is better to have less options for your client in order to keep things simple and efficient.
The last section is Portability. This controls access to all the Divi main settings like the theme customizations, options, and layouts. I suggest disabling all of these as well.
Don’t forget to scroll to the very top of the page and click “Save Divi Roles” before you leave.
When it is all said and done, only four actions are given the editor role – Edit Item, Use Visual Builder, General Settings, and Edit Content.
The above settings are meant to serve as a general best practice for most clients. Of course, all clients are different and some will want more access than others. The important thing to remember is that a little coaching in the beginning goes a long way. If your client is going to be adding and/or editing content, send them some Divi tutorials or make your own video tutorial. Your client will feel at ease knowing they won’t have to keep coming to you for every little thing. This will save time and money.
When it comes to handing off a site to a client, giving them an editor role makes the best sense. They have the ability to edit pages and posts without the power to crash the site by accident. Also, customizing the editor role capabilities using Divi’s Role Editor helps to streamline the client’s ability to edit what is already there and nothing more.
I hope you find this helpful when handing off your next project.
I look forward to hearing from you in the comments.
I really wish I could get the role editor to work. I created an editor role in which they were not allowed to access advanced settings/custom css, and they were allowed access to divi theme options. However, when I log in as the editor, they do have access to advanced settings/custom css, and they are not allowed access to divi theme options. Furthermore, my administrator account is now missing the advanced settings and custom css tabs from all modules. I deactivated all of my plugins and the issue persisted. Any ideas?