Many of Drupal's modules include a settings screen that can be accessed from the Configuration menu. In this chapter, we will work our way through these screens to describe the options available and how they apply to the web site.
The user account settings screen can be reached at Configuration | People | Account settings (admin/config/people/accounts
).
The section is quite extensive and covers a few different areas, so we will look at them individually.
The type of website you are building will dictate the exact choices you make here, but it's important to consider all the options in turn before you allow users to start creating accounts.
Note that the actual management of users and permissions is covered in the Chapter 9, Users and Access Control.
The website you are building has the following requirements:
Keep these requirements in mind as we work through the user configuration pages.
The configuration comprises multiple sections shown in the following screenshot, all collapsed to save space:
When a user has a personal contact form, a contact tab appears on that user's account page:
By unchecking the checkbox here, all newly created users will not have a personal contact form on their account page. You can still select it to enable one on a per-user basis; the setting here only configures the default for new users. If the setting is enabled on a particular user, other users with the permission Use users' personal contact forms will be able to send e-mails to them using the form.
If you allow anonymous users to perform any actions such as comment or create content on the website, then that content will be shown as being submitted by the Drupal username Anonymous. The name displayed is easily changed here to something of your choosing—a common alternative is to use the word Guest
.
Change the value to Guest
now.
When modules are enabled for the first time, they may define new permissions. It is generally convenient that your highest permission role is granted these new permissions so that users in that role are able to use and configure the module right away.
The Administrator
role is the default role that is assigned the new permissions, but you can use this dropdown menu to change the role to an alternative. For example, you may have a Superuser
role to which you want all new module-management permissions to be assigned automatically.
This screen allows you to define the behavior for newly created user accounts. Firstly, you can determine who is entitled to create new user accounts. The setting here is often determined by the type of site you are building:
Who can register accounts |
Example uses |
---|---|
Administrators only |
A private site or intranet. A site that does not have user interaction. |
Visitors |
A blog site where new users are encouraged to create content, an open forum, or an e-commerce site. |
Visitors, but administrator approval is required |
A blog where comments are moderated. |
Based on the requirements we mentioned at the beginning of this section, we will need to change the setting to Visitors.
We will keep the checkbox for e-mail verification ticked so that people can only create accounts if they have a valid e-mail address. This should reduce the amount of spam accounts.
Unchecking this box will prevent the password indicator showing on the new user creation page. While this is a useful tool to assist the user in selecting a password, some find it annoying and it might not work well on old browsers.
A canceled user account in Drupal does not necessarily mean that the account is deleted. The next option allows you to determine what happens to the user account itself and to the user-generated content when the user account is canceled.
For example, if a user has commented on a news article, what should happen to the comment if the user account is deleted?
The options are given in the following table:
Option |
Examples of why you might use this option |
---|---|
Disable the account and keep its content. |
You want to keep any content the user has created but do not want the user to access the site or create any more content. You may want to allow the user to access the site again at a later date. You want to preserve the threads of conversation in comments. |
Disable the account and un-publish its content. |
You want to keep the content the user has created but want to prevent other site users seeing it. |
Delete the account and make its content belong to the Guest user. |
You want to permanently remove the user account but keep the content the user generated. Any content this user generated will now be displayed as "guest" or anonymous content. |
Note that it is possible to set a permission for a role to enable the user to make their own decision on what happens to their content when they delete their account.
For our example, to make sure you don't lose any content if a user account is deleted, you should use the third option otherwise when a key member of the content-editing team left, all of the content they created would be deleted.
Select Delete the account and make its content belong to the Guest user. Now, when a user account is deleted, the author of the article or comment will be shown as belonging to Guest.
There are a number of system e-mails (discussed next) sent in response to certain user-related events.
The from
address of the e-mails will default to the site e-mail address set in Configuration | Site information, unless you set a different value here.
For example, you might want the site e-mail to be [email protected]
but the from
address for automatic e-mails to be [email protected]
.
These are the emails that are sent out automatically in different user scenarios.
They are triggered based on some of the settings you have just been looking at in the previous section.
You can change the contents of any of these e-mails so that you can set the tone of voice and message to match your audience.
When you edit the templates, note the use of tokens here again such as [user:name]
.
Tokens are elements that are replaced live by actual content in the message that gets sent out. For example, the [user:name]
token gets replaced by the actual username of the currently logged in user, in our case admin
.
While some tokens are optional, it's important not to remove key information like the one-time login URL ([user:one-time-login-url]
) on a password reminder e-mail.
Available tokens are as follows:
Token | |
---|---|
[ |
The name of the site as set in Configuration | System | Site information. |
[ |
The full URL of the site including the prefix |
[ |
The username of the user the e-mail being sent is related to. |
[ |
The e-mail address of the user the e-mail being sent is related to. |
[ |
A link to the login page of the site. |
[ |
The website URL. |
[ |
A link to the user profile edit page of the user the e-mail is related to. |
[ |
A link that allows the user to login to the site once only without their password. This is used for password resets. |
[ |
A link to a page allowing the user to confirm cancellation of their account. |
In our scenario, the e-mails that will be active are as follows:
If you are using Dev Desktop for your site development, you will be able to test these e-mails assuming that you used real e-mail addresses when setting up the site and user accounts.