Welcome to Social Networking with Drupal 6! During the course of this book, we are going to learn how to use Drupal 6, a content management system, to create a social networking web site. We will install and configure Drupal, take a look at its features and see how it works. By using a combination of existing features, modules, and some simple custom development, we will enable user interaction, user contributions, and communication with our users.
In this chapter, you will learn:
What social networking is
About social networking concepts
What a content management system is
What Drupal is
Why Drupal is an excellent platform for social networking
How to install and configure Drupal
We will also discuss the social networking web site—which we will create during the course of this book—DinoSpace! a social network for keepers of pet dinosaurs.
Social networking and social network services seem to be taking the Internet by storm, moving from large services such as Facebook and MySpace to simpler services such as Twitter and FriendFeed. But what exactly is social networking and what does a social networking service (like the one we will create in this book) do?
One of the fundamental concepts of social networking is building connections with other people. These connections and their connections build up a network of social links between users. With a network of contacts, it becomes easier to contact new people, perhaps someone who is a friend of a friend, or contact people you have lost touch with, such as old classmates. Obviously, using a social network to reconnect with people who you know or have known physically would require either a large social network (such as Facebook or MySpace) or a niche social network such as our DinoSpace scenario (why not reconnect with people you met at a recent dinosaur care conference?).
Let's take a look at how these networks of contacts are built up.
The network representation above shows the connections between contacts. Contacts of a contact can be easily discovered, making it easy to build up your own contacts to communicate and collaborate with new people.
There is another side to social networks, and that is the community, contribution and collaboration aspect. Social networking sites generally allow interaction between users in a way that expands the social networking site itself, by contributing to the content of the site, communicating via discussion forums and blogs, making the site grow organically and become the product of all its contributors. Let's look at the collaborative and communicative features available on most social networks:
Discussions, normally by means of a discussion forum
Photograph galleries, allowing images to be shared with contacts, and in some cases associated with the people in them
Custom profiles that allow users to share information about themselves with others
Personal messaging and personal contact forms that allow users to communicate with each other directly
Many social networks also have the ability to work with information from other web sites and services, allowing you to bring together your information from other sites (such as tweets from your Twitter feed, photos from your Flickr stream, links from your del.icio.us profile, and so on), and to help find friends already on the web site using contacts from your email address book.
These features are just the tip of the iceberg. If you are already familiar with social networking services such as Facebook and MySpace, then you will know that they provide a wealth of features and services for their users. If you are not familiar, why not sign up to a few services and have a look at what they offer; it might help you while planning for your own social network. There are also some less popular social-networking-type sites such as Twitter (www.twitter.com) and FriendFeed (www.friendfeed.com) which particularly work well with building friendships between people who don't actually know each other, whereas Facebook and MySpace are designed with "real life" friends in mind.
Improve business—A social network can allow businesses to interact informally with customers, gathering feedback and in some cases giving value to the customer. One particular instance of this is that of radio stations advertising their web sites as social-network-type web sites, where listeners can get in touch, connect with other listeners, request songs, share photographs, and so on.
Improve communications—Communicate with users informally, easily and cheaply.
Provide a service—With the site we are going to create throughout this book, we will be providing a service through the exchange of knowledge and information relating to owning pet dinosaurs and having our own social network provide a fantastic platform for sharing and expanding this knowledge.
They are fun! Social networks break down the barriers of time and distance, and are a good way to meet new people in a relatively safe way.
Let's look into some of the reasons I've just listed which will answer why we should create our own social network, as opposed to using an existing one.
Existing social networks do allow us to improve business, because we can tap into their existing user base, which is great; but where it falls short is in providing extra enhancements. If we look at Facebook, additional features are created by third-party developers, and embedded as applications. Some of these applications add business functionality, for instance the one that allows users to make reservations for a local restaurant. The problem with such applications is that users are prompted for permission before the application gets any of their information (rightly so, as they are hosted by the developers who write them, and are different from Facebook). With the rise in the number of available applications, and the amount of "invitation spam" inviting users to add applications, many users are more careful and reserved when it comes to using applications within Facebook. With our own social network, we wouldn't need to worry about this. We would host all the information, and can provide exactly what we need—a streamlined social network (without adding extra features, bloating the web site).
Social networks are designed to enable and enhance communication. We have no physical barriers to communication (as being in a country different from another user isn't relevant). So, both an existing social network, and our own would improve communications. The advantage of having our own site is that we are less restricted in how we can communicate with our users. We can easily contact them and display information to them via any area of the web site, email, personal messaging and possibly via mobile devices too.
Many web sites and social networks provide services relevant to the social network, or to the target audience, such as linking with Amazon to show books a user has read, or a knowledge base of information.
Services provided through other social networks, either via standard functionality they offer, or via third-party plug-ins (such as Facebook applications) would be restricted in a number of ways—firstly, by the terms and conditions of the social network, and later by how additional functionalities can be added. For instance, if we were to create a knowledge base for taking care of pet dinosaurs as an application in a social network, it relies on being promoted within the social network's web site (as it is difficult enough to try and promote a web site to new visitors, let alone a particular part of a web site). Its functionality and design is also limited to the provisions made by that social network for third-party plug-ins.
It really comes down to the nature of what you want to offer the end users. If you want a social network to fill a particular niche, then creating one is probably the best bet. If you want to create a generic social network or a specific social networking feature for a generic audience, then utilizing an existing social network would be more productive, as you could harness their system and their user base.
Throughout this book, we are going to create our very own social networking web site using Drupal. This web site is called DinoSpace!, and it is aimed at the owners of pet dinosaurs (yes, I know, nobody really owns a pet dinosaur…it would be too expensive and impractical) to interact with one another. In particular, the web site aims to:
Connect owners of pet dinosaurs and allow them to build and maintain friendships with other users
Allow owners to share stories about their pets
Help in promoting dinosaur-friendly places to visit
Provide interactive help and support to fellow dinosaur owners
Allow owners to chart their activities with their dinosaur
Of course, the web site needs to enable more than just user-to-user interactions. It also needs to provide other content, and allow communication between us, the managers of the web site, and our users to keep them up-to-date.
We are going to create our own social networking web site. To do that, we are going to use Drupal, an open-source content management system (CMS). So, let's look at exactly what a CMS is, and what Drupal is.
Most web sites available on the Internet involve a degree of complexity, be it large web sites with a lot of content, or those dealing with dynamic user interactions, or those involving a number of different people updating different sections. Even small web sites can be complicated to manage, particularly if the design needs a change, or a particular piece of information needs a change on every page.
One of the key features of a content management system is that it separates the design of a web site, the content of a web site and its business logic and features, making it easy to change any aspect of the web site independently without affecting the rest of the web site.
The diagram above shows the separation of these key layers. It shows that when a visitor to the web site requests a page, the content management system takes the design template and the content from the database, combines the two along with some logic (such as seeing if the visitor is logged in, in which case it may display a username too) and then sends the result to the visitor's web browser.
Generally, content management systems have the ability for users to do the following through their web browser:
Edit, delete and manage content
Provide and restrict access to content, and to enable editing of content by the user's role within the web site
Allow multiple users to easily edit and control different areas of a web site simultaneously
Separate the design, content, and logic layers of the web site
Manage different versions or drafts of content (referred to as revisions in Drupal)
The project was started by Dries Buytaert, and is now assisted in development with a large community. One particular advantage with Drupal is its modular framework, which allows additional features to be plugged into it, in the form of modules. The Drupal web site maintains an extensive list of modules and themes (custom designs), which can be used for free.
The Drupal web site address is www.drupal.org, and it contains the downloads, news and updates on Drupal, information relating to many of the modules, and themes which can be downloaded to enhance Drupal and discussion forums.
Because of the way Drupal is structured, it is very flexible in adapting to the needs of a wide range of different web sites. Permission to perform various actions such as creating content, writing a comment, writing a blog post and so on can all be assigned to different roles within Drupal, be it the role of an administrative user or the role of a standard user who is logged in. This means we can grant the permissions to contribute and help in managing the content of the web site to the users of the web site.
Many socially-oriented features are included in Drupal "out of the box" (without the need to download extra files or modules) including:
Collaborative content via the book module and also via permissions allowing users to edit different types of content, such as pages
Drupal's modular framework, which I mentioned earlier, allows new features to be installed at a later time. There are many modules available, which are designed to enhance Drupal's ability to work and act like a social network. It also means that once our site is up and running, we can easily expand it at a later date with new modules to add extra functionality. Such modules include:
With Drupal being a content management system, we also have the advantage of having our site controlled and managed by ourselves, as is typical of most web sites, while the community can contribute to the other areas.
We know what Drupal is, we know what social networking is, and we know what we are going to create during the course of this book. So, let's get started! The first thing we need to do is install Drupal. This section contains some detailed technical information regarding the requirements and installation of Drupal.
For most of the book, we will be working with Drupal installed locally on our own computers (see Appendix, for setting up a development environment if you don't have web server software installed on your own computer) as we build up our site. We will move it across to a live web site later.
If you already have a development environment set up, which differs from the one detailed in Appendix, then you may need to make some adjustments to take into account the server requirements for Drupal. If you went through the process in Appendix, you will find that everything is set up and ready, and compatible with Drupal.
Web server (Apache recommended, and used during the course of the book; IIS is also supported. However, other web servers have had limited testing)
PHP 4.3.5 or greater (5.2 or higher recommended; this will be the minimum requirement once Drupal 7 is released)
Database Engine: Either MySQL (4.1 or 5) or PostgreSQL (7.4 or greater). MySQL is assumed during the course of this book.
To make use of friendly or clean URLs,
mod_rewriteand the ability to use
.htaccessfiles is required. However, it is optional.
PHP's XML extension may be required to utilize certain XML-based services. This is also optional.
The Drupal handbook contains more details on the requirements, http://drupal.org/requirements. There are also some guidelines on setting up your own development server environment on the Drupal web site at http://drupal.org/node/260. However, in this book we are assuming the setup given in Appendix.
We can download a copy of Drupal from the download page on the Drupal web site http://drupal.org/download. There are a number of download areas on the Drupal web site. But this one is specifically for the Drupal project (that is, the content management system itself), which is exactly what we want. The version we want to download is one from the 6.x range (at the time of writing, 6.5). So let's click the download link and download Drupal!
Extract the Drupal files
Create a database
Run the Drupal installer
The file we have downloaded is a compressed file containing all the individual files that make up Drupal. We need to extract this into the web folder in our development environment (see Appendix) using an unzipping program (such as WinZip, PowerArchiver or Windows' built-in "Compressed folders" system, or the default program for handling compressed files on your computer).
Technical Installation Details
There are more technical installation details available in the
INSTALL.txt file, which is in the folder we have just extracted.
We need a database for Drupal to store information such as the web site's content, details of our users, settings, and so on. PHPMyAdmin is a web-based tool for administering MySQL databases. Most web hosts provide access to it, and we have a copy on our local machine too.
Let's log in to phpMyAdmin and create our database. Our local installation is located at
http://localhost/phpmyadmin/. We will need to have our database username and password to hand (see Appendix A, if you are using that development environment). Most of the development environment software such as WAMP, XAMPP, and so on have a default username of
root without a password.
Once logged in there, we have the option to create a new database. Let's call it
Keep a note of the database name, as well as the database username and password, as we will need it in a minute when we run the Drupal installer.
Now that we have our database, we can run the installer. To do that, we just need to visit the folder where we installed Drupal, using our web browser. This should be at
http://localhost/drupal-6.2/. Since we haven't installed Drupal yet, visiting this page will take us straight to the installer, which initially asks us which language we would like to install it in.
We shouldn't need the advanced options. However, there may be times when we'd need it for some shared hosting providers. It allows us to set the server on which the database is stored (for us, it is our local machine, which is
localhost; this is the value which is already set), the port the database uses (which can normally be left blank) and a prefix for the database. If you want to have more than one installation of Drupal from the same database, you need to enter a unique prefix for each of the installations. For our local installation, we don't need to worry about them. So let's click Save and continue.
The installer then sets up the database, which would take a couple of minutes.
Now that the database is set up, we need to provide some basic site information, the details for our administrator user account and a few server settings.
The basic site information we need to provide is the name of the web site and the email address to be used by the web site when sending emails.
The next section is for the details of our administrative user account. This user account will have permissions to manage and control the entire site. To create the account, we need to supply a Username, an E-mail address, and a Password (which needs to be confirmed).
I've entered Michael for the Username and my email address of [email protected] for the E-mail address, followed by my Password. You should enter a Username, E-mail address and Password of your choice.
Drupal analyzes the Password you type in to check its security and suitability for use. Because this Administrator account can control the entire site, having an insecure password can leave the site vulnerable to the Administrator account being hacked into. If you enter a Password which Drupal thinks is too insecure, it gives you some tips (as shown in the following screenshot) to make your Password more secure.
Here are some guidelines I generally follow when creating passwords which I feel is worth pointing out:
Finally, we have the server settings options. The only options required are the Default time zone, Clean URLs and Update notifications options. The Default time zone option is to determine the dates and times used throughout the site. So if we were to post an article on the web site, it would use the time zone set here when displaying the date and time the article was posted. The Clean URLs option makes the URLs generated by Drupal more user-friendly, and more search-engine, friendly too. This setting depends on the servers' setup. Some web servers cannot support clean URLs because of the way the pages are generated. However, Drupal does a quick test to see if our server supports them. The final option, if set, will notify us about the new versions of Drupal when they are available.
This is very useful, particularly from a security perspective, where some vulnerability in security may have been reported and fixed in a newer version. This will alert us to the availability of this version.
The default time zone picked up should be the one set on our computer, and shouldn't need to be changed. We can enable Clean URLs, assuming our server supports them, and we should check the updates checkbox.
Time zone and Clean URLs
If you are installing Drupal direct onto a web hosting server, the time zone will be that of the server, which if located in some other country, may need to be set to match the time zone you prefer. Clean URL support may not be available; you should contact your web host if you are unsure about it or you need support.
Once we are done, we need to click the Save and continue button to complete the Drupal installation!
We are now presented with a confirmation screen informing us that the Drupal installation is complete. You might have a few errors on this page relating to Drupal's ability to send email.
This error message is expected, because we have installed Drupal on our local computer, and our computer probably does not have a built-in email server (although if you are running a Linux computer or a Mac, you may have one built-in, depending on your setup). This isn't something we need to worry about, as we won't need it to send emails until we deploy our web site live on the web!
Clicking the your new site link takes us to our brand new Drupal installation.
Since we have just set up Drupal, and created our user account, we are now logged into our new web site. On this front page, we have a link to the configuration section where we can configure our installation.
The customize and configure link takes us to the Site Configuration page, which contains various sections of the options we can configure.
Let us take a look at these options and what they allow us to do, and configure them for our DinoSpace site.
Actions are tasks which Drupal can perform, such as unpublishing a comment, making a post sticky, or sending an email. These actions can be performed by some of the modules within Drupal when triggered by a certain event. For instance, we could automatically set posts or comments containing links to the competing web sites to be unpublished.
On their own, these actions won't do anything, they need to be triggered. However, triggers are not enabled by default, different modules and custom development may introduce the need for actions and triggers later.
A Theme is a collection of files, which make up the design, layout, and style of our Drupal web site. New themes can be added, modified, and applied to change the look of our site. In Chapter 8, Designing our Site, we will look at themes in detail.
Since we don't know what these different themes look like, we can't yet make a judgement on whether we would prefer a different one for administering the site. The advantage of this is that if we were to have a very stylish image-heavy design for our site, we may opt for a simpler design for the administration options to make it easier and faster to administer the site, while keeping the site itself more visually appealing. There is also the option to use the Administration theme when editing and creating content, which is generally done outside the Administration section.
We have already set the Clean URLs option, when we installed Drupal. But this section allows us to change this, and enable or disable the Clean URLs at any time, should we need to. We don't need to; so, let's leave this as it is.
The default time zone (which we set on installation).
User-configurable time zones (to allow users to set their own time zones, which adjust the display of dates for them). This is already enabled, and makes a more enjoyable experience for users in another time zone, as it may be difficult for users to find out what time something was posted or replied to.
The first day of the week, used for calendar views.
Format of the short representation of a date.
Format of a medium length representation of a date.
Format of a long length representation of a date.
The formatting settings are primarily a personal choice, I'm happy with them as they are, so I'm going to leave them at their defaults. Why don't you explore these options and adjust them to your personal taste.
We haven't actually created any pages yet. So we can't redirect our users. However, we will come back to this in Chapter 2, Preparing Drupal for a Social Networking Site.
The other option on the page is with regards to displaying technical error messages generated by Drupal. The two options available are Write errors to the log and to the screen and Write errors to the log. These error messages are useful when developing and creating a site. However, displaying them to visitors can confuse them, as they will be technical, and can pose a security risk by revealing information on our site's setup. Let's change this to Write errors to the log. If we do encounter any problems, we can always check the log.
If you wish to leave it as it is, don't forget to change it to just the log when you put your site live on the web!
Once we have made those changes, we can click on the Save configuration button, and then return to the configuration options by clicking the Site configuration link near the top of the page.
File system path—this is the location on the server where the files will be stored.
Temporary directory—where uploaded files are stored during previews.
Download method (either public or private)—Public downloads mean that anyone could gain access to the files as they are stored in a web accessible folder, whereas the private method would require Drupal to generate the download for the user. The Private method is useful, if we don't want guests to be able to download the files and only want registered users to access them.
Changing the download method on a site which is in use can cause problems with the existing files. So now is the perfect time to change this if we need to. For DinoSpace, there is no reason to have the files tagged private, so let's leave these options as they are.
Changing the download method, and a note on the temporary path
If you do change the download method, you should change the file system path to reflect a location which isn't accessible via the Internet, that is, outside your web site's root directory. The temporary path is generated automatically based on your server's settings; change this only if you know what you are doing. When working on a live web site in a hosting environment, your web host should be able to instruct how you should configure the file system path and the temporary directory settings, should you wish to change them, or use the private download method.
Many web servers provide options for manipulating images, the most common ones are the GD image library and ImageMagick. We have the GD library installed (from Appendix A). However, we could remove this, or use the ImageMagick library instead. These libraries provide options for tasks including things like:
Changing the size of an image
Cropping an image
Converting the format of images
The Image toolkit settings provide settings specific to the image library (or toolkit as Drupal refers to it) we have installed. With the GD library, the only setting is related to the quality of images which are manipulated by Drupal.
By default, this is 75%, which means if we were to upload an image and we set Drupal to generate a thumbnail, the thumbnail image would only be 75% of the quality it could be. This option weighs the quality of the image over the size of the image. If we increase the quality of the images, uploaded images will be of a larger size, which may take longer to download, whereas if we reduce the quality of the image, we get lower file sizes, however, the quality of the images is reduced.
Let's adjust this to 85%, as we want to use high-quality images on our site. If this becomes a problem, we can always change it later. You may find it useful to adjust this setting letter if the additional bandwidth is not an issue for you, or the quality of the image is too poor.
Then we need to click Save configuration and return to the Site configuration page.
Please note that this section is a little more advanced than the other settings pages, as it requires a little more technical understanding.
The two formats available are:
HTML tags are used to structure a web site, for instance, a paragraph would be contained within
</p> tags, and a hyperlink would be contained within the
</a> tags. Different tags do different things and pose different risks.
The roles column in the table of Input formats indicate which users can use which format. By default, only administrators can use full HTML (although it says no roles may use it, anyone who can administer the input formats can also use them all). Let's look at the configuration options for Filtered HTML, which will be the input format our users will use, and see what we can configure. The configure link allows us to configure the input format.
Users are grouped into roles; by default, there are anonymous user roles (users who are not logged in) and authenticated user roles. The roles define the permissions for those users. However, the administrator user created when installing Drupal has permission to do anything on the site.
Configurable options include the roles which can use the format, and the filters which the format has. We can't adjust the roles, because this is the default format. So all roles must be enabled for this format.
Currently, any web addresses entered by our visitors will be turned into a hyperlink to that site. Unchecking this may help prevent spam. However the
<a> tag is still allowed, so links could still be created.
Instead, let's enable the spam link deterrent option. This option is found by clicking the Configure link at the top of the page, which also allows us to edit the specific HTML tags that are not allowed by this input format.
These configuration options allow us to set:
The maximum length of text in a link (longer links will be shortened)
How tags should be filtered
Tags that are allowed
Whether help on HTML should be shown
The Spam link deterrent option adds a special bit of code to all the links that are submitted, which tell the search engines that we don't have editorial control over the content. This prevents the search engine from penalizing our search engine rankings if that link turns out to be a spam link.
Let's enable this option by checking the box, and then click the Save configuration button to save the change.
The next setting is for Logs and alerts, which currently only contains options for database logging. This sets how many logs should be retained, and by default, is set to keep the last 1000 log entries. These logs are viewable from the administration area. For the cut-off limit to work, we need to set up a scheduled task, called a Cron job, which we will look at in Chapter 9, Deploying and Maintaining our Site. Until then, changing this option won't do anything. So, let's leave it for now.
Logs include actions such as creating content, updating content and performing administration tasks. It is important to keep some of these, as it may help in keeping tabs on other administrators, or in investigating why a user had a problem doing something with the site. But the system stores logs for lots of different things, and it can soon build up and clog the database; so we don't want to keep too many of these for too long!
Next, we have Performance settings. These settings allow us to optimize the performance of our Drupal installation, which is particularly useful when we have lots of visitors to our web site. The Normal caching mode is recommended for production sites, but we are still working on our site. So we will need to remember to change this when we deploy our site.
Page caching prevents Drupal from loading and processing pages every time they are requested. Instead, it stores a copy of the processed page (known as a cached version) and when anonymous users visit the site (who are less likely to use dynamic elements that require processing, Drupal serves them the cached version of the page. With web sites under a lot of strain, caching is very useful in reducing unnecessary load on the server from many visits. The Minimum cache lifetime setting prevents Drupal from processing the page too frequently. This ensures that the cached version is used for at least a specific time period, before a new, more up-to-date copy is processed, and the cached version is updated. This setting is more suited for very busy sites.
Every time a user visits our site, data is transferred from our web server (well it will be when we have it deployed; for now, it is stored on our local computer, and is not being transferred) to the user. This data transfer is usually within a specific bandwidth limit set by hosting companies or service providers. Very busy sites can use lots of bandwidth, which can in turn cost the web site owners a lot of money. Drupal has some basic Bandwidth optimizations available for us to reduce the amount of data transferred.
We are not anticipating a large number of users to our social network, at least, not right away; so let's leave those Disabled for now. We can always keep an eye on our bandwidth usage and enable it later if we need to.
Site name—The name of the site, which in our case is Dino Space! This was set when we installed Drupal
Site e-mail address—The email address from which automated emails from the web site will be sent; this was also set at the time of installation
Slogan—A motto or tag line for the site
Mission—A mission or focus statement
Footer message—A message to be displayed at the bottom of each page, in the footer
The names of anonymous users
The page which will act as our front page
We already have our name and email address set at the time of Drupal installation; so let's set the other options.
The final configuration option is the Site maintenance settings. This allows us to take our web site offline, so that only administrators can access it and display a message to visitors trying to get in. This would be useful when making big changes, which could interfere with what our visitors are doing on the site at that time. So during these updates, we would take the site offline to prevent any problems.
When we put our web site online, we will need to tweak some settings before they become usable. So, let's set a message now saying something along the lines of the site currently being configured for use. That way, when we put the site online, we can put it into maintenance mode, and it will display the message we have set now.
We have looked into what social networking is and at various social networking concepts, and also seen why we may wish to create a social network. We then looked at Drupal, and have now become aware of what it is, and how it can be used as a social networking platform. Finally, we installed Drupal onto our local development environment, examined the configuration options available and made some basic configuration changes to the default Drupal installation.
The next stage is to start preparing our site to become a social network!