Configuring Site Settings

To begin configuring Drupal, make sure that you are logged in as the administrator (the account that you created in Chapter 1), and then select administer> settings in the navigation block to get to the site settings page (the URL to the page is http://localhost/?q=admin/settings).

When you access the site settings page, Drupal takes the opportunity to check some aspects of your installation in order to help you avoid problems. Because of this, you may be confronted with one or more messages when you access this page for the first time.

One thing that Drupal checks is whether a directory exists for uploaded files. If you followed the instructions in Chapter 1, that directory should exist and be ready for action. If it isn't there yet, Drupal will try to create it. If Drupal succeeds in creating the files directory, you will see this message:

The directory files has been created.

If Drupal tells you that it was unable to create the files directory, the most likely problem is that the web server doesn't have permission to write to the files directory. For Linux servers, you can solve this problem by changing the group ownership of the folder to the same user that runs the web server, often apache or www.

Another message that you may see, especially if you are running Drupal on Windows, is this:

The built-in GD image toolkit requires that the GD module for PHP be installed and configured properly. For more information see http://php.net/image.

If you see this message, you are encouraged to follow the link to http://php.net/image and follow the instructions there.

The rest of the page is divided into eight main sections: General Settings, Error Handling, Cache Settings, File System Settings, Image Handling Settings, RSS Feed Settings, Date Settings, and String Handling. You can expand or collapse each section by clicking the section heading.

General Settings

The General Settings section contains settings that help define the site, including its purpose, how to contact the administrator, the front page, and so on. The following settings are available:

Name: The name of your site has several important functions. First, it appears in the HTML <title> element and thus in the title bar of the browser. Second, it can be toggled on or off to be displayed on the site itself (some themes don't support this option). Finally, if you enable RSS syndication for your site, the name of your site will show up in the RSS feed for your site as well.

■ Note RSS stands for Really Simple Syndication. See http://en.wikipedia.org/wiki/ Really_Simple_Syndication for more information about RSS.

E-mail address: This e-mail address should belong to the administrator of the site. Be prepared to receive all site-related mail traffic to this address. For example, it is used in the welcome e-mail that is sent to newly registered users.

Slogan: The optional slogan summarizes the purpose of your site in a couple words or sentences. If you enter a slogan, it will be used in the <title> element of your front page in conjunction with the site name. For example, a site named CoolWidgets.biz with the slogan "You can't live widgout it!" will display CoolWidgets.biz | You can't live widgout it! in the title bar of the browser. The slogan can be displayed on your site and can be toggled on or off from the theme settings pages (see the "Choosing Theme Settings" section later in this chapter). The slogan is used in your site's RSS feeds as well.

Mission: The mission is another, generally longer, blurb of text, which is usually displayed on the front page. It, too, can be toggled on or off from the theme settings pages.

Footer message: The footer message is text that will appear in the site's footer. Some people use this as a space for banner ads or links to their terms of service, legal, or contact pages.

Tip The name, slogan, mission, and footer message all play a significant role in defining your site in the eyes of search engines, so it is worthwhile to make sure that they accurately reflect the purpose and content of your site.

Anonymous user: This determines the name that will be given to site visitors in logs and posts if they are not logged in. For example, if someone visits your site and leaves a comment without first creating an account and signing in, the post will be attributed to whatever name you set here. The default is Anonymous.

Note In Drupal, the anonymous user is represented by the user id (uid) 0.

Default front page: This is the Drupal path that will act as your front page. You can use any valid path. The following are some examples of paths:

• node: A listing of all content that has been promoted to the front page. This is the default setting.

• node/nid: Where nid is a specific node (content) ID, such as node/302. Use this syntax to make a specific node (page, blog, story, and so on) function as the front page.

• blog: A listing of all published blogs (requires the Blog module to be enabled).

• user: The current user's homepage or a page where visitors can log in, register, or request a new password.

Clean URLs: Enabling "clean" URLs is a means of hiding the GET parameter q. The result is that the characters ?q= no longer appear in the URL. What is this worth? It is more human-readable, first of all. Furthermore, it is more search engine-friendly, as the URL doesn't immediately announce to the spidering engine that the page is being built dynamically. Clean URLs are dependent on Apache mod_rewrite support. (See http://httpd.apache.org/ docs/1.3/mod/mod_rewrite.html for more information about mod_rewrite.)

Figure 2-1 shows an example of a front page with its name, mission, slogan, and footer visible.

Name

Slogan

Name of site. | This is the/^iogan. - Mozilla Firefox id it View Go Book mad Q Nam\ of site. | This is the slogan.

Mission

Name of site. | This is the/^iogan. - Mozilla Firefox id it View Go Book mad Q Nam\ of site. | This is the slogan.

Name of site.

Syndicate

This is the mission statement.

create content

► administer

Submitted by admin on Sat, 2005-08-06 10:57.

Community Portal Sites If you want a news v the audience and the best stories bubble up Kerneltrap

Personal Web Sites Drupal is great for the u; links. Examples: urlgreyhot | Langemarks Ca

Personal Web Sites Drupal is great for the u; links. Examples: urlgreyhot | Langemarks Ca

Aficionado Sites Drupal flourishes when it po

Figure 2-1. Front page with name, mission, slogan, and footer

HOW DRUPAL BUILDS URLS

Drupal gets all of its information about which page to display from the URL in the address bar. Because Drupal is database-driven, and each page is dynamically created by PHP scripts, these URLs do not point to physical files on the server, but rather convey information to Drupal about what is being requested.

In Drupal, all requests are directed to index.php. This happens by virtue of the request rewriting that is defined in the .htaccess file. Both of these files can be found in the root of your Drupal installation. (See the .htaccess file for more details about request rewriting.) If the URL has GET parameters in the form ?q=admin/ user, the final URL that is given to index.php will be http://www.yoursite.com/index.php?q=admin/ user (you don't see this happening, though). If you have clean URLs enabled and the original URL is http:// www.yoursite.com/node/1, it will get rewritten to http://www.yoursite.com/index.php?q=node/1. In every case, the request will have the parameter q with some sort of path information behind it, and the entire request is directed to index.php. It is this path information, represented by the q parameter, that Drupal uses to decide which page to serve.

One of the first things done during a page request is the building of a menu map. The menu map is a hierarchical list of all the types of pages Drupal has available and the path to each type. Drupal builds this menu map by asking the modules which paths they support and by polling the database to see which paths have been defined by the administrator. (For performance reasons, paths that do not change are cached to reduce the work that needs to be done for building the menu map.) Drupal takes the q parameter from the HTTP request and splits it on the forward slash (/). Then, using these pieces of path information, Drupal starts searching the menu map for the entry that matches it, finally settling for the map entry that matches the most parts from left to right. After finding the most complete match, Drupal can decide which page to serve , and any additional unmatched parts of the q parameter are passed along as separate parameters.

The following are four paths that exist in your Drupal system, which you can access if you are logged in as the administrator.

Default Drupal URL

http://www.mysite.com/ ?q=admin

http://www.mysite.com/ ?q=admin/access

http://www.mysite.com/ ?q=admin/access/roles

http://www.mysite.com/ ?q=admin/access/rules

Clean URL_

http://www.mysite.com/admin

http://www.mysite.com/admin/ access

http://www.mysite.com/admin/ access/roles

http://www.mysite.com/admin/ access/rules

Path_

admin admin/access admin/access/roles admin/access/rules

For example, Drupal will handle the URL http://www.mysite.com/?q=admin/access/value1/ value2 as follows:

1. Extract the q value (admin/access/value1/value2).

2. Split the value into separate values on the /.This results in an array {admin, access, value1, value2}.

3. Find the entry in the menu map that exactly matches the most values from left to right. In this case, it will match admin/access.

4. Call the function associated with admin/access and make value1 and value2 available to the function.

Error Handling

Whenever your Drupal site receives an HTTP request that it either cannot handle (because it is asking for a page or resource that doesn't exist) or will not handle because of access restrictions, it will return an error page instead. Drupal provides built-in default pages for each of these cases, but you can define alternate pages to be used instead. Other errors that can occur include PHP errors, which arise when Drupal can't perform the requested operations. You can configure how these errors are handled and recorded through the Error Handling section of the site settings page. The settings here include those for Default 403 and Default 404 pages, error reporting, and discarding logs.

Default 403 (Access Denied) and Default 404 (Not Found) Pages

Drupal has an access system that determines what content a site visitor is allowed to see and which actions that visitor is allowed to execute. When visitors attempt so see content that they are not entitled to see or execute an action for which they do not have the necessary permissions, Drupal returns a page with the HTTP header 403 Access denied. The default behavior is to print a page that says "Access denied - You are not authorized to access this page." If you want to elaborate on this or present a different message, you can do so by creating a Drupal page and entering the Drupal path to that page in the Default 403 (Access Denied) Page field.

■ Note Drupal path refers to the part of the URL that comes after the ?q= in the URL, such as admin/access or node/4/edit.

Similarly, when Drupal receives a URL that cannot be mapped to an existing page or resource, it prints the message "Page not found." If you wish to expound on this, perhaps by offering some suggestions of popular content on your site, you can create a Drupal page and enter its path in the Default 404 (Not Found) Page field.

For example, you might want to create a different page to handle the 404 Not Found errors if you had pages or resources on your site that no longer exist but still get requested. Perhaps you used a dedicated blogging tool or a specialized bulletin board system on your site before deciding to switch to Drupal, and you notice from your server logs that people are still requesting URLs that point to the old, nonexistent system. You would want to make a Drupal page explaining that the resources have moved, with instructions on how to find them, and use that page's Drupal path as the value for the Default 404 (Not Found) Page setting.

Error Reporting

Sometimes, even high-quality code like Drupal runs into situations at the PHP level that cause errors. For example, when no mail server is configured and you attempt to create a new user, a process that involves sending mail, a PHP error will occur. By default, these errors will appear at the top of the page before any of the Drupal-generated HTML. A typical error might look like this:

warning: mail(): Failed to connect to mailserver at "localhost" port 25, verify your "SMTP" and "smtp_port" setting in php.ini or use ini_set() in C:\Apache2\htdocs\drupal\modules\user.module on line 374.

This is important and useful while setting up your site, as it helps you find the places where things are going wrong. On a live production site, however, this is not exactly the type of information you want to serve to your audience. Fortunately, Drupal offers the choice of reporting this error information to either both the screen and logs or to just the logs. Clearly, you'll want to have this set to the first option during development and the second after the site goes live. You can see all of the error information in the Watchdog logs (Drupal's logging system is called Watchdog) from the Administer page (admin/logs) at any time.

Discard Logs

The Discard Logs option lets you decide how long you want your log messages to be kept. The setting you choose depends on how much site traffic you get and whether there are size limits on your database imposed by your hosting company. You will want to be aware of how large the Watchdog table is and adjust this setting accordingly, so that you keep only as much log information as is useful to you.

Cache Settings

Drupal does everything its developers can think of to be efficient and fast. This is important for sites that receive high traffic. It saves on server costs by allowing a server to handle more requests and allows smaller servers to handle bigger sites.

One of the crucial elements in making Drupal efficient and fast is the cache system. By default, Drupal automatically caches the variables, menus, and filters that it uses internally to build pages. These elements are cached automatically and require no configuration or action on the part of the administrator. The main decisions left to the administrator are whether to cache pages and the minimum time that a cached page should be kept. These decisions are made with the Cache Settings options on the site settings page (admin/settings).

Page caching takes the final HTML output of each page, including the headers, exactly as it is sent to your browser and saves it into the cache database. Then, the next time that page is requested, the server only needs to look into its cache to see how that page should be built. This saves immense amounts of work for the server in terms of executing PHP code and making database queries, as the entire cached page can be served with a single query.

Cached pages are served only to anonymous users, never to registered users who are logged in. A crucial question arises, however, concerning how and when to rebuild the cached pages. In terms of performance, keeping cached pages as long as possible should be the goal, because they generate the least overhead. The problem with this becomes apparent on sites where the content is updated often, as the cache might prevent anonymous visitors from seeing changed or new content immediately. This problem is addressed with the Minimum Cache Lifetime setting, which specifies an amount of time that a cached page must stay in the cache before it can be replaced with new or updated content. When choosing this setting, try to balance the need for speedy page delivery with the inconvenience of having a lag time before new or updated content appears for anonymous users. Authenticated users will always see the newest version of content, no matter how the cache is configured.

File System Settings

Drupal offers two types of file downloading methods:

Public downloading: This means that the job of serving uploaded files to the browser falls on the underlying web server, which will serve them directly. Web servers are carefully optimized to be able to serve static resources like files in a very efficient way. This will always be the fastest method for offering downloads. The ramification is that the files must reside in a directory that is visible from the Web. Putting files in a Web-visible directory prevents you from having any control over who can download the file. Hotlinking— the practice of offering the URL to images or files on another server—will be possible, and depending on your goals, may not be desired. While some of these problems are addressable at the server administration level, it will never be possible for Drupal to control on a file-by-file basis whether or not a particular registered user can download something. To get that level of control, you will need to enable the private downloading method.

Private downloading: For the private downloading method to be effective, the files must reside in a directory that is not visible from the Web. The directory needs to be readable and writable by scripts, however, as PHP code will be responsible for putting the files into it and reading them out of it. In this scenario, the web server is never asked to serve the file directly. Instead, through use of a special URL, a PHP script is engaged to read the file in chunks and send the stream to the browser. Since the download is happening at the PHP level, code can be written to check if the current user actually has the permissions necessary to access the file. With greater control comes the cost of more server processing overhead and slower downloads.

The Download Method field in the File System Settings section determines which downloading method is to be used. Currently, you cannot combine these two methods, and changing methods on a live web site that already has uploaded content will break the existing links and is therefore strongly discouraged.

The File System Path setting is the path to the directory where uploaded files and images will be saved. How to address this directory depends on what setting you choose for Download Method. If you decide to use public downloads, you can use the standard files directory in the root of your Drupal installation. In this case, the value that you provide for the File System Path field is simply files. If you choose to use private downloads, you must provide a directory somewhere on your server that isn't visible to the Web, set the appropriate ownership and permissions on the directory so that it can be accessed via scripts, and provide the absolute or relative path to this directory.

The Temporary Directory setting is the path where uploaded files will be stored before they are handled by PHP scripts. This is typically /tmp on Linux machines.

Image Handling Settings

Drupal needs to know which image handling library it should use to deal with images that are uploaded to the system. The most common operations that are needed are resizing large images to make thumbnails and other, smaller versions of the original. The Image Handling group of settings will display all of the available options. This will typically include the GD2 library (http:// php.net/imagegd2), which is included in all versions of PHP starting with 4.1.0. Drupal will issue a warning message if the GD2 library is unavailable; at which point, you need to check your PHP version and find out whether the library can be enabled.

Drupal also supports the ImageMagick library (http://www.imagemagick.org/script/ index.php). For that library, you will need to install the image.imagemagick.inc file, which is part of the Image module. Refer to Chapter 4 for details on installing modules.

RSS Feed Settings

The settings for your site's RSS feeds are straightforward, enabling you to determine the maximum number of items that will be listed in your feeds, as well as to choose the format for the individual feed items. The format choices include Title Only, Titles Plus Teaser, and Full Text. These settings will apply to all of the RSS feeds that your site is capable of generating.

Date Settings

Drupal's date and time settings allow you to customize your site to best fit your audience's geographical profile. The two issues at hand are how your site will deal with time zones and the formatting of dates and times.

Time Zones

First, set the default time zone for your server. This is not necessarily straightforward and requires a decision on your part. Should the default time zone for the server be the time zone where the server is physically located, the time zone where the site administrator resides, or the time zone of the site's target audience, if this can be determined? Whichever time zone you choose will be used by default to display times and dates on your server. The different time zones appear in the Default Time Zone selection box and are represented by the number of hours offset from Greenwich Mean Time (GMT). For example, +0000 is GMT, +0100 is Central European Time, and -0500 is Eastern Standard Time.

If you want your site's users to be able to set their own time zone and view the dates and times adjusted accordingly, enable the Configurable Time Zones option. This will allow users to adjust their time zone on their user profile page. If they don't do this, all dates and times will be shown localized to the default time zone.

While it is true that Internet sites are by nature international, as anyone across the globe can access them, some sites do cater to an audience or a topic of interest for which a single time zone makes sense. For example, if your site covers news and events for a city or a region, you will probably want everything to be displayed in terms of local time, so you should therefore disable the Configurable Time Zones option. This would also be a common choice when you're using Drupal to power a site on an intranet.

Date and Time Formatting

Next, set the short, medium, and long date formats. Some date formats, like 2/28/2006 - 9:18 PM, are geared toward an American audience, and some formats, such as 28/02/2006 - 14:45 (day/ month/year, 24-hour clock), are more familiar to a European audience. Choose the format that best reflects the preferences of your largest user group and also prevents any possible confusion. One suggestion is to use the following:

• Medium date format: February 28, 2006 - 10:50am

• Long date format: Monday, February 28, 2006 - 10:50am

This leaves no room for confusion about which comes first, day or month, or whether 9:00 means AM or PM.

The First Day ofWeek setting mostly influences calendar views. The only module in the core modules that offers a calendar view is the Archive module. The first day of the week shows up on the far left in the calendar.

String Handling

Drupal handles and stores its textual data in the UTF-8 character encoding format in order to support the many written languages of the world. (See http://www.unicode.org/ for more information about Unicode encoding.) Not all versions of PHP support this encoding fully without added extensions. To address this problem, the preferred solution is to install the mbstring extension to PHP available from http://www.php.net/manual/en/ref.mbstring.php. If the mbstring extension is not available, iconv (http://php.net/iconv) or GNU recode (http://www.gnu.org/software/recode/recode.html) must be installed.

The String Handling group exists to show you the status of Drupal's string handling on your server. If Drupal is able to use UTF-8 encoding using an available library, this will be indicated. Otherwise, you will be prompted to install one of the three libraries mentioned in the previous paragraph, preferably mbstring.

The Seo Wars

The Seo Wars

Discover the real search engine optimization mind tricks that will get you dominating the searching engines, faster than you can say, Luke, I am your father! If you've ever tried to get high search engine rankings you probably realize that it can be an incredible task to try and rank highly without paying for the ranking.

Get My Free Ebook


Post a comment