Now that you have seen an introduction to Drupal (in Part I) and an in-depth look at Drupal’s socializing and communication tools, including e-commerce (in Part II), it is time to focus on building your site. This part deals with the nuts-and-bolts issues of choosing a theme for your site, working with panels and pages, using menus, and other overall site issues.
In this hour, you prepare for creating and deploying your site. You gain some basic housekeeping information—everything from how to manage terms of service (TOS) and protection from bots on your Drupal site.
You have experimented with Drupal, and you may have set up more than one site. Now, it is time to do it for real. Think about the problems that you have had, and come up with a plan for the production site (or, if possible, the production and development sites). Many problems arise with shared hosting, but they generally are solvable. (For example, you may be limited to a certain number of installations.)
Go back through the basic settings for roles and permissions and come up with the final version that you will use for production. You also may have experimented with custom content types that might be useful or might need to be consolidated. If at all possible, start by creating your new site from scratch.
One critical point to remember is that the first user you set up has complete access to the site and database. You normally do not run under this account, but you may need it to run update.php and some other maintenance tasks.
Many people use a password that they know well for this account. If you have done so, come up with another one. Although, in general, it is a bad idea to share accounts and passwords, the password for the primary user account must be sharable (so, it cannot be your bank PIN). You will need to share this password when you go on vacation or if you move on to another Drupal gig. It can always be changed, but it is very risky to be in a situation in which you and only you can change the password to something nonsensitive before it can be given to someone else.
Treat this account password as very secure, but secure in a different way than your private passwords.
Unless your site is behind a firewall on a private network, you will soon find traces of unauthorized visitors. If you review the log, you will see login attempts by bots; these are often recognizable by the users list. You will see a user who registered a week (month or year) ago, and who has never returned. This is quite possibly legitimate, but it may not be. Malware is now able to recognize forms on websites, register for them, and even send messages. This may be malicious or just frivolous (or both—it can be a dry run for a soon-to-come malicious attack).
You may want to protect your site with software such as CAPTCHA that can distinguish between a person and a bot. Other modules are available, but many people use Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA). Download, install, and enable it, as shown in Table 17.1. (reCaptcha, which is described later in this section, is a web service version of CAPTCHA. You may want both.)
There are now several versions of CAPTCHA; they all build on the CAPTCHA base. The idea behind all the CAPTCHAs is that they present a problem that cannot be solved by a computer bot. Only a person can solve the problem. This can be a problem that involves arithmetic and logic—“What is the third word of this sentence?”) or one that involves recognizing text that has been distorted to prevent bots from reading it.
Figure 17.1 shows examples of the various types of CAPTCHAs. The final one (reCAPTCHA) is one of the most frequently used. This is partly because it is fast and efficient, but it is also chosen by a number of webmasters because of what is happening behind the scenes (see the sidebar “How reCAPTCHA Works”).
You need to download code from the reCAPTCHA site so that the reCAPTCHA module can call back. The code can be downloaded from recaptcha.net/plugins/php/index.html in an archive file. Expand the archive and install the folder inside the reCAPTCHA module folder.
When you have installed the reCAPTCHA module, it will be located at .sites/all/modules/recaptcha. The downloaded and expanded files are placed inside that folder in their own folder, which is also called recaptcha. You can check that the installation is correct by looking for recaptchalib.php. It should be located at .sites/all/modules/recaptcha/recaptcha/recaptchalib.php.
After everything is downloaded and installed, go to Administer, User Management, Captacha (admin/user/captcha). You will see all the forms on your site, and you can choose which form of CAPTCHA (if any) is used for each, as you see in Figure 17.2.
If you have downloaded and installed reCAPTCHA and it does not appear, make sure that it is enabled and permissions are properly set both for CAPTCHA and reCAPTCHA. Go to admin/user/captcha and click the reCAPTCHA tab. You will find fields to enter the public and private keys you have obtained from http://recaptcha.net/api/getkey.
You may be launching a site that is larger and more complex than any other site you have been involved with. You should think about two areas of legal issues.
Depending on the type of site you are developing, you may need a number of legal notices. These are the most common:
• Copyright notices— The conventional wisdom used to be that you should protect your site and its contents from unauthorized use and copying, and that the simplest way to do that was to stick a copyright notice on each page. Things are much more complex now. For example, if your site contains open source content, its terms of use may prevent you from copyrighting it again or may require you to continue to post the original copyright or license terms. (Drupal is open source software, but this section applies to your site’s content, not its software.) In addition, you may not be able to copyright your site’s material. (This applies to government sites in the United States.) The new conventional wisdom is twofold: Know what your copyright status is, and then post the appropriate notice.
• Terms of Use— You may impose limitations on how your users can use your site. This may be phrased as “by using this site, you agree to...” or it may be a formal document that the user must accept, as described in the following section.
• Terms of Service— Whereas terms of use refer to how users can use your site, terms of service typically refer to what you will provide to the user. If you are allowing users to update the site, create blogs, and post content, you will be providing a service to them.
• About Us— This page on the site can be simply informative, but it may need to have credits and notices. This is particularly true for nonprofit sites where grants and even public funding may support the site. The terms of the grant or funding may include notifications you must post.
Several modules let you administer legal options.
The Terms of Use module (project/terms_of_use) lets you implement agreement with terms of service on the account registration form. If the user does not check the I Agree box (you can change the wording), the user cannot register. You can specify the text of the terms so this module works for both terms of use and terms of service.
In the last part of this hour, you will find some references to modules you can use for advertising on your site. That brings up a critical issue for you to consider: How do you find and evaluate new modules for the site?
In Hour 4, “Administering Drupal, Themes, and Modules,” you saw how to download modules and find them on drupal/org/project/modules. In the best of all possible worlds, you would have three Drupal installations: your production version, a development version, and a disposable version for module and theme tests. The difference between those last two versions is that a development version should be pretty much a copy of your production site with all the modules installed. The disposable version can be just that—a fresh installation into which you can install a module you want to evaluate. Not having other modules there is beneficial so that you can focus on the new one. If you are pleased, you can install it into the development version and then take down the disposable version.
From the listings on Drupal.org, you can look at comments and at the number of users. As noted previously, very small numbers are not necessarily adverse. When you go looking for specific types of modules (for example, modules to support wish lists), look at the usage numbers. You will probably find several modules with roughly similar numbers. You will get an informal sense for what the number of users of a module in this category should be. (You would not expect it to be less than 10 or more than 30,000, although those numbers are appropriate in other categories.)
Experiment with the module as you would want to use it. Now that you have more experience with Drupal, look for implementations that could use built-in Drupal functionality but that do not do so (rules, taxonomies, CCK, and so forth). These may be indications of a module written some time ago that has been maintained but not structurally updated.
For many websites, advertising is a critical source of revenue. In fact, as is the case with many print publications, advertising may pay for the support of the site. (In the case of print, there frequently are dual income streams: revenue from advertising is supplemented by revenue from subscribers and purchasers of single copies.)
As the web has grown, advertising revenue has been critical. The economics of the web (very low cost of delivery and presentation along with potentially very large audience numbers) have meant that only highly automated ad delivery services can succeed in many cases. There are Drupal interfaces to Google’s AdSense, along with others.
In addition to these networks, a parallel advertising world has grown up on the web. It consists of everything from an ad on a website offering a T-shirt with the company’s logo to ads specifically promoting websites (rather than the purchase of goods). The next section looks at both areas.
These programs all function in basically the same way. You create an account with the company and are assigned an ID. Your pages are configured to be able to retrieve dynamic ad content based on either a user’s search or the content of the page. That dynamically created ad is placed on your site along with your ID. You are reimbursed based on the responses to those ads.
Do not confuse Google AdSense (in which you earn money) with Google AdWords (in which you pay to place ads such as these on other sites). In its simplest form, an advertiser can pay to have an ad placed on pages with a keyword such as dog bed using AdWords. If you have a page related to dog beds, Google AdSense may place the ad paid for by the AdWords user on your page; you are then paid for displaying the ad.
Typically, your account with the ad service provides extensive statistical reporting. If you are already using an ad service, find out if they have a Drupal module implementation.
By the Way: AdSense and Generated Ads
The AdSense terms of service and other documentation envision a process whereby you manually create an ad and paste it onto a page. As more people generate pages dynamically with tools such as Drupal, this idea of copying and pasting an ad is a quaint relic of the past. There is more on the project/adsense page.
This module (project/adsense) implements Google AdSense on your site. It can be integrated with Drupal roles so that ads are displayed (or are not displayed) only for some roles. This can provide you with an implementation for a subscriber role where the user pays a fee for add-free content. The code for the ad is generated on-the-fly in accordance with Google’s formatting.
This module (project/amazon) implements the Amazon e-commerce APIs. This is a somewhat different approach from Google AdSense because the revenue that is generated is not generated by the ad. Rather, if someone clicks through to Amazon with the customized link on your website, purchases earn a commission that is credited to your account. Thus, the revenue is based on sales, not advertising.
Rather than having ads served up by a service that pays your account for the displays you provide, you can create and place your own ads. (This includes publishing ads that are provided to you by your clients.) Modules supporting this functionality typically provide their own statistical reporting.
This powerful and popular module can be found at project/ad. It can be a good module to experiment with if you want to get started, in part because of its extensive reporting features that help you understand how the ads are working on your site.
This hour covers some of the issues you need to consider as you start to launch a live site. You have seen how to protect against spammers and bots using CAPTCHAs and their derivatives. You have also seen how to find new modules and, specifically, how to deal with legal notices and the opportunities for earning money from ads on your site.
Q. What is the best way to find the legal requirements for my site?
A. Look at comparable sites (in the same government jurisdiction). If your site is part of an existing business or organization, use trade group resources to find out how laws apply to you and your site.
Q. What legal liability do I have (or receive) if a contributed module does not work properly?
A. In most cases, you assume all the responsibility. Do not think that this is an artifact of open source software. Reading the license for a commercial product is not for the faint of heart.
1. Does Drupal work with Google’s AdSense?
2. What is the difference between terms of service (TOS) and terms of use (TOU)?
3. Can I sell advertising directly on my Drupal site?
Quiz Answers
1. There is a bridge module available (as for eBay, Amazon, and more).
2. TOS refers to the service you provide; TOU refers to what users can do with that service.
3. Yes. You do not have to use an intermediary such as AdSense, but you may find it easier not to do your own advertising marketing.
This hour provided a jumping-off point for the last part of the book. Go for it and set up (if you can) three sites: production, development, and disposable. Use the process as part of a learning and training program. If several people are working on the project, it can be a good idea not to work together. If each of three team members puts up the three sites, together you have put up nine sites and you should have created a fairly strong institutional knowledge. This is one case in which working together can be detrimental. By working together, it may turn out that no single member of your team is comfortable setting up a Drupal site from scratch.