Adding a default editor role to Drupal Core

Over the past year I have been working with the Drupal Admin UI & JS Modernization Initiative to improve the administrative interface and user experience for content editors. One of the enhancements being considered is adding a default content editor role to Drupal out-of-the-box. Currently the Drupal Standard profile ships with just Anonymous, Authenticated and Administrator roles.

Some of the discovery done (survey, analysis, comparative study, card-sorting exercises) has given us insight into the user experience content editors are looking for in a modern CMS and also confirmed our expectations of common content editor tasks.

Moving forward, we conducted another survey to better understand if the Drupal community and site builders saw value in adding this predefined role in Drupal core, and if so, what set of permissions should be included.

So far, we’ve had 166 submissions. Here is a summary of the results.

Should Drupal include an out-of-the-box editor role?

More than 84% approve of including a content editor role in Drupal core. 10.8% were neutral on the proposal, and only about 4.2% actually disagreed.

Naming the role

We also asked for suggestions on what the role should be named. Of the most popular, “Content Editor” took the lead (61.4%). 42.8% opted for naming it just “Editor,” and “Content Creator” received under 12% of the vote.

In the comments given, there was some debate about “Editor” sounding like a role that would have more reviewing tasks, as compared with a Content Contributor / Author / Writer.

What permissions should be included by default in the Content Editor role?

We listed several types of permissions that could be included. Our guidelines for creating the list were to keep the basic set of permissions simple and avoid adding complexity. We included those tasks in the survey that comes enabled with Drupal core and would be widely used. Our premise is to help site builders expedite site configurations. We don’t want them to have to disable permissions, which can be easily forgotten and could lead to problems later on. Also, we would not be able to include common tasks that are found in the most popular features such as media management, revisions, and content moderation, etc., since they are not enabled by default.

Looking at the results, there were several tasks that were clear leaders. The following permissions are the ones most strongly agreed on for adding in the default set:

• Create and edit new content — articles and pages (78%)
• Use the basic HTML text format (66%)
• View unpublished content (77%)

Other tasks that were generally favored include:

• Create and edit terms (tags and categories)
• Access the administration theme

Respondents were more ambivalent about adding “Use the full HTML text format” to the basic permissions set. “Administer Blocks” is the only task that clearly received a negative rating.

We also asked about permissions on some of the most commonly used features from contrib modules to gain ideas for future consideration. A few that were generally favored are:

• View unpublished paragraphs
• View revisions
• Revert revisions

A section was included for respondents to write in what other tasks they thought should be considered. Most ideas centered around permissions from modules not enabled by default, but it is useful to have this insight for future exploration.

A few respondents suggested that they would like to see more responsibilities given to a content editor, such as:

• administer menus and menu items
• access or edit taxonomy terms
• publish, unpublish and delete one’s own content
• edit another user’s content
• access contextual links
• clear the cache
• edit the content of custom blocks (but not place/administer them)
• user management (but can’t create admins)

Respondents also mentioned default permissions that would be useful to have in certain modules, such as:

• administer comments
• create basic views
• editorial workflow access (save as draft and send for review), after content moderation is enabled
• view Webform results
• Layout Builder and Media Library modules
• translate own content

In general, there was a consensus that editors should not have complete access to Structure and Configuration pages by default.

How about adding a default Content Manager/Publisher role?

After reviewing the feedback in the issue, Twitter feeds and Slack channels, we found there was some interest in adding not one, but two roles to Core — that of an Editor and a Content Manager/Publisher. As a result, we added this question in the survey to better gauge relevance.

The respondents were more ambivalent about adding a content manager role as a default. Those who agreed/strongly agreed totaled 44%. The neutral votes were quite high at 25.3%. Those who disagreed/strongly disagreed came in at 30.7% combined.

Of those who favored adding this role, approximately 40 respondents wrote in the following permissions as ones suggested to add to the basic set of the Content Editor permissions:

• publish/unpublish/delete all site content
• see all unpublished content
• administer blocks (others say this should not even be given to a publisher role)
• administer comments and comment settings
• administer contact forms and contact form settings
• administer URL aliases
• administer menus and menu items
• administer vocabularies and terms
• edit another user’s content
• create/manage other users, but not permission management
• check logs for issues
• approve and reject content from other lower roles
• approve/revert revisions
• access some admin functions, i.e. clear cache
• make some appearance changes

Most of the tasks are focused on content moderation, although there were a range of ideas, sometimes conflicting.

Additional comments

In the survey, we also asked for additional comments and received good inputs on the content editor role as well as other recommended additions to Drupal core.

In a couple of cases, respondents wrote in that they did not agree with adding a default role because they view its usage as too specific and not relevant to a lot of websites. On the other hand, the Standard installation profile is already opinionated: it includes content types such as Basic Page and Article, as well as Taxonomy Vocabulary for tags. The goal of Standard is to try to fit 80% of use cases. Those who don’t want to start with this predefined set of defaults can use Minimal installation profile.

One suggestion that seemed interesting to us to consider in the future is to ask a question during the base Drupal install on whether to add the content editor role or not rather than installing it automatically.

Some other feedback that can inspire more discussion is to look into reviewing the Administrator role. Some took the opportunity to comment on better defining this role as they view it to be too broad, and perhaps splitting some permissions out into other admin type roles. This will be interesting to discuss on a separate drupal.org issue in the future.

What’s next

Based on the conclusions and responses received in the survey and other discussion channels, we propose to add the Content Editor role as a default role.

The permissions should start out as a basic set. We recommend adding the following, listed as generic sets of permissions to be defined in a follow up issue:

• Create and edit new content — articles and pages
• Use the basic HTML text format
• View unpublished content
• Create and edit terms (tags and categories)
• Access the administration theme

Based on the survey results, we do not see enough support for adding other permissions. It is best to start out small and then evolve the primary concepts in future releases once we can evaluate the impacts of the MVP.

We look forward to discussing this further in the Drupal.org issue.

Thanks to Cristina Chumillas, James David Saul, Suzanne Dergacheva and Lauri Eskola for their help on the survey and providing input on the article.

More ways to help

Are you a developer or designer for Drupal, and interested in the efforts to improve Drupal? Then get involved!

There are many ways to help us shape the future of Drupal. Check out the Admin UI and JavaScript Modernization initiative on Drupal.org and reach out to us on the #admin-ui channel on Slack and join in the conversation.