People often assume that the basics are easy to master and therefore, don't require much thought. Things are not quite so simple in reality because while a site's basic setup is, more often than not, easy to implement, the more subtle problem is in knowing what to implement, and how to implement it in the first place. Precisely understanding what you need from a site is particularly important for this reason.
Does this mean that you should not start working directly on the site unless you know exactly what is required? Not really; like most things, it's a bit of a trade-off when it comes to starting out with the development of a Drupal website. This is because it is almost impossible to determine exactly what the site will need and how its functionality should be provided until you have been working with it for some time. Often, you will find yourself modifying the behavior of a site based on feedback from the users.
In this article by David Mercer, author of the book Drupal 7, we are going to talk about the following Drupal site configuration topics:
- Site information
- Actions and Triggers
- Shortcuts
- File system
(For more resources on Drupal, see here.)
Not everything that is available in Drupal's Configuration section is discussed in this article. Some settings are very straightforward and really don't warrant more than perhaps a brief mention.
Before we start
It is sensible to make note of a few important things before getting our hands dirty. Make it second nature to check how the changes made to the settings affect the site. Quite often settings you modify, or features you add, will not behave precisely as expected and without ensuring that you use a prudent approach to making changes, you can sometimes end up with a bit of a mess.
Changes to the site's structure (for example, adding new modules) can affect what is and isn't available for configuration so be aware that it may be necessary to revisit this section.
Click on Configuration in the toolbar menu. You should see something like the following screenshot:
A quick point to mention is that we aren't giving over much space to the final option—Regional and Language. This is because the settings here are very basic and should give you no trouble at all. There is also an online exercise available to help you with date types and formats if you are interested in customizing these.
Let's begin!
Site information
This page contains a mixed bag of settings, some of which are pretty self-explanatory, while others will require us to think quite carefully about what we need to do. To start with, we are presented with a few text boxes that control things like the name of the site and the site slogan.
Nothing too earth shattering, although I should point out that different themes implement these settings differently, while some don't implement them at all.
For example, adding a slogan in the default Garland theme prints it after the site name as shown in the following screenshot:
Whereas, the Stark theme places the slogan beneath the site name:
Let's assume that there is a page of content that should be displayed by default—before anyone views any of the other content. For example, if you wanted to display some sort of promotional information or an introduction page, you could tell Drupal to display that using this setting. Remember that you have to create the content for this post first, and then determine its path before you tell Drupal to use it. For example, we could reference a specific node with its node ID, but equally, a site's blogs could be displayed if you substitute node/x (in node/ID format) for the blog.
Once you are looking at the content intended for the front page, take note of the relative URL path and simply enter that into the text box provided.
Recall that the relative URL path is that part of the page's address that comes after the standard domain, which is shared by the whole site. For example, setting node/2 works because Drupal maps this relative path to http://localhost/drupal/node/2
The first part of this address, http://localhost/drupal/ is the base URL, and everything after that is the relative URL path.
Sometimes, the front page is a slightly more complex beast and it is likely that you will want to consider Panels to create a unique front page. In this case, Panels settings can override this setting to make a specific panel page as the front page.
The following settings allow you to broadly deal with the problem of two common site errors that may crop up during a site's normal course of operation—from the perspective of a site visitor. In particular, you may wish to create a couple of customized error pages that will be displayed to the users in the event of a "page not found" or "access denied" problem.
Remember that there are already pretty concise pages, which are supplied by default. However, if you wish to make any changes, then the process for creating an error page is exactly the same as creating any other normal page.
Let's make a change very quickly. Click on Add new content in the Shortcuts menu and select Basic page. Add whatever content you want for, say the Page not found! error:
Don't worry about the host of options available on this page—we will talk about all of this later on. For now, simply click on the Save button and make note of the URL of the page when it is displayed. Then head back to the Site information page, add this URL to the Default 404 (not found) page dialog, and then click on the Save configuration button:
If you navigate to a page that doesn't exist, for example, node/3333, you should receive the new error message as follows:
In this example, we asked Drupal to find a node that does not exist yet and so it displayed the Page not found! error message. Since Drupal can also provide content that is private or available to only certain users, it also needs the access denied error to explain to the would-be users that they do not have sufficient permissions to view the requested page. This is not the same as not finding a page, of course, but you can create your own access denied page in exactly the same way.
Finally, you will need to specify how often cron should run in the Automatically run cron drop-down at the bottom of the Site information page. Cronjobs are automated tasks (of any type—they could be search indexing, feed aggregation, and so on) that should run at specified intervals. Drupal uses them to keep itself up-to-date and ensure optimal operation.
Drupal uses web page requests to initiate new cron runs once the specified interval has elapsed. If your website does not get visited regularly, cron itself cannot run regularly.
Running cron every few hours is reasonable for the vast majority of sites. Setting it to run too quickly can create a huge load on the server because each time the cron is run, all sorts of scripts are updating data, performing tasks, and consuming server resources. By the same token, run cron too infrequently and your site's content can become outdated, or worse, important module, theme, and core updates can go unnoticed, among other things.
Actions and triggers
Quite often, it happens that for specific events, it is useful to have Drupal automatically perform a specified task or action. An action, in the Drupal sense, is one of a number of tasks that the system can perform, and these usually relate to e-mailing people or acting upon user accounts or content. There are a number of simple actions that are available as well as a few more advanced ones that can be set up by anyone with sufficient permissions.
To configure actions, navigate to Actions in SYSTEM under the Configuration menu in the toolbar:
Default simple actions cannot be modified, so we will ignore these for the moment and focus on creating a new, advanced action. Set up a new Send e-mail action by selecting it from the drop-down list and click on the Create button, as shown in the preceding screenshot. This brings up the following page that can be set according to how this specific action will be used:
It should be clear that the intention of this e-mail is to notify the staff/administration of any new site members. The Label field is important in this respect because this is how you will distinguish this action from the other ones that you may create in the future. Make the description as accurate, meaningful, and concise as possible to avoid any potential confusion.
Also notice that there are several placeholder variables that can be inserted into the Recipient, Subject, and Message fields. In this instance, one has been used to inform the e-mail recipient of the new user name, as part of the message.
A click on the Save button adds this new action to the list where it can be modified or deleted, accordingly:
So far so good—we have set the action, but this in itself does absolutely nothing. An action cannot do anything unless there is a specific system event that can be triggered to set it off. These system events are, perspicaciously enough, called triggers and Drupal can look for any number of triggers, and perform the actions that are associated with it—this is how actions and triggers work together.
Triggers are not part of the topic of Drupal configuration. However, we will discuss them here for completeness, since actions and triggers are integrally linked.
Triggers are not enabled by default, so head on over to the Modules section and enable the Triggers module. With the module enabled, there will now be a new Triggers link from the Actions page. Clicking on this brings up the following page:
Triggers are divided into five different categories, each providing a range of triggers to which actions can be attached. Assigning a trigger is basically selecting an action to apply from the drop-down list of the relevant trigger and clicking on the Assign button.
To continue with our example, select the USER tab from the top of the Triggers overlay and, in the TRIGGER: AFTER CREATING A NEW USER ACCOUNT box, select the newly defined action, as shown in the following screenshot:
Click on the Assign button, and the newly assigned action will show up in the relevant trigger box:
In the same way, a large number of actions can be automated depending on the system event (or trigger) that fires. To test this out, log off and register a new account—you will find that the New User Alert e-mail is dutifully sent out once the account has been registered (assuming your web server is able to send e-mail).
(For more resources on Drupal, see here.)
Shortcuts
Shortcuts are a new feature of Drupal 7 and allow administrators (or anyone with sufficient permissions) to create sets of links that can be accessed by others using the shortcuts bar—directly below the toolbar menu. By default, Add content and Find content are the only two links that are provided, but you may change these regularly depending on what you are working on at any given time.
For example, it may be useful to create a set of shortcuts that involve theme-related links for quick access when it's time to theme the site. By the same token, adding links to views and displays might be more useful when working on content.
The overlay system is integrated with shortcuts, making it easy for the administrators to add links to their shortcuts. For example, let's say we wanted a set of configuration shortcuts so that all the main configuration tasks are readily accessible at a moment's notice.
To do this, we need to first add a new shortcut set. Go to Shortcuts in USER INTERFACE under Configuration, and click on the Add shortcut set link, to bring up the following page:
Now go to your account, and select the Shortcut tab. Select the new Configuration option and save the changes by clicking Change set to ensure that you are viewing the correct shortcut set. Now click on Edit shortcuts in the shortcuts bar to bring up the list of links contained in this set:
Nothing too exciting yet. In fact, this is exactly the same as the default shortcut set. We can add new shortcuts to this list manually by clicking on the Add shortcut link and providing a name and path manually:
Clicking on the Save button shows the new link added to the list and it is also now available in the shortcuts bar on the top of the page.
The other, easier way to add links is simple; click on the plus icon next to the overlay name. A small popup appears to the right of the icon while hovering over it. Take note of this because it indicates which shortcut set the link will be added to.
The new shortcut will appear along the top of the page with the rest of the links.
Anyone with sufficient permissions can create their own set of shortcuts and use them as they choose. The shortcuts system also provides a block that can be added to the site like any other block. Making effective use of shortcuts can help you cut down the wasted navigation time—just remember to select the most relevant set from your account because it is only possible to view one at a time.
File system
How you deal with the file system settings really depends on what type of content you visualize your site using. If you know that most files should be available for anyone to download, then leave the Default download method as Public. By the same token, if you want some control over who can access the files then use the Private method.
Public files can be accessed directly through a browser without having to go through your Drupal website. So, if someone liked a video you posted, they could reference it from their own website, allowing their visitors to see the video using your bandwidth to serve it—obviously not ideal.
You need to keep an eye on this and find out if your host service provides some sort of hotlinking protection to combat this.
Assuming you want to make your download method private, you will need to specify a directory that is not directly available over the web—in other words, it is outside the document root folder.
The same technique is used for the temporary files folder that Drupal requires in order to properly handle any files you or the site users might deal with.
On your development machine, you might end up with something like the following screenshot (Public file downloads):
To make this private, create a folder outside of the web root (but still within the web server folder), add it to the Private file system path option, and click on the Save configuration button, as shown in the following screenshot:
With the new absolute path to the private folder specified (in this case, privatedrupalfiles) there will now be an additional Default download method available for selection, entitled Private local files served by Drupal.
The Default download method is the default behavior. Individual download methods can be set on each file type field added to any content type.
Before continuing, let's confirm that we can specify a download method for any file without problems. Go to Content types under Structure, and click on the manage fields link next to one of the content types, say blog entry. Add a new field of the File type and save the changes. You will then be able to select Public files or Private files in the Upload destination section on the following configuration page, as shown in the next screenshot:
The important point here is that each file uploaded to the site can be controlled on a field level basis, and more importantly on a field level per content type basis. This is a vast improvement over Drupal 6 which forced either all files to be public or all to be private.
How Drupal controls what type and the size of the files that can be uploaded is a matter for the content type specific configuration page shown in the preceding screenshot. It is not really sensible to allow any type of file to be uploaded to the site. The first thing that will happen if you do this, is that someone will upload a malicious executable file that does something nasty when it runs on the users' machines, in turn, causing them to say or do something nasty to you.
For example, you might know that for a particular content type, the only type of file that should be uploaded is a small text or .txt file. In this case, you would have something like the following settings:
In this case, we have specified that only 'txt files' of less than 50 KB can be uploaded to the blogtext sub-directory. The decisions you ultimately make should be dictated by the needs of the individual site. When in doubt, follow the tenet:
Provide only what is absolutely necessary, and no more!
The actual settings themselves are easy enough to implement, but I suggest you do not add any file extensions that you know the site will not need. Remember that it is possible to cloak nasty software within other file types, so the more variety you allow, the less secure things become.
We can test all of this out by posting a new blog and trying to upload files. Try a range of files, not just 'txt' files to see the results. For example, attempting to upload an image file gives the following result:
However, uploading a new file that does meet the criteria set, meets with success and we can check to ensure that the file is present in the proper sub-directory of the file system, as shown next:
As you can see, the site has correctly uploaded the blogtextfile.txt file in the blogtext subdirectory, as specified earlier. The field-based system for file handling in Drupal 7 represents a huge improvement over previous Drupal milestones.
Summary
This article has covered a fair amount of ground in terms of setting up the site. We began by looking at some general configuration settings, like Site information, that are important in terms of getting the nuts and bolts in working order. Many of these settings will need to be revisited as the site develops.
While triggers aren't necessarily part of a discussion on configuration, we learned that they are inextricably linked to actions that can be configured to automate many common site tasks or chores. Again, coming back to actions and triggers every once and a while can help reduce the number of repetitive tasks that have to be completed manually.
Next, we gained the ability to control file uploads and file handling using Drupal 7's new field-based paradigm. Having fine grained control over how various files are accessed is a great improvement over past incarnations of Drupal.
