Drupal started as a content management system, and that's what its core is all about. Since its inception in 2001, the Drupal environment has attracted thousands of users and developers who have improved all aspects of the environment.
There are many industrial-strength Drupal installations built on shared and custom code. This chapter discusses the Drupal core and modules that are commonly used.
If you are reading this book, you probably have some experience with Windows programming and perhaps are familiar with content management systems that run in a Windows environment. I'll mention a couple of these in this chapter and take you though the path that led me to Drupal. Perhaps you've had a similar journey.
Version 7 of Drupal marks an important direction for the framework. It is probably the most significant major release because it propels Drupal into the enterprise by abstracting the database layer and providing richer role-based administrative functionality. The user interface has also been streamlined to keep up with the other products in the marketplace.
We've had content management systems for decades. If you have information, you probably have some kind of system to manage it. At one time, systems that manage textual information were called "document management systems." At one end of the complexity scale are file-directory-document-naming systems. How many times have you seen a directory with document names like "Chapter1.doc", "Chapter1–v2.doc", and "Chapter1–v2-reviewcopy.doc"?
While such systems can work in a small office with limited participants, they get unwieldy when more authors or reviewers are involved.
Moreover, documents increasingly began to have rich content added to them, which gave rise to a new issue—how to manage this rich content apart from the words of the document. That's when vendors began calling these systems "content management systems."
At the complex end of the market are systems designed to store rich content types and allow authors to collaborate on content across the enterprise, with the final intent of publishing the content externally or using it internally to run the enterprise. These systems make use of technologies such as SGML, XML, scanning, and OCR, as well as translation bridges to move data between different electronic formats.
These content management systems are widely used in large enterprises. Microsoft is putting a lot of effort into establishing its SharePoint Server as the content management tool to use in large enterprises.
In the realm of the World Wide Web, however, content management has entered a new era with new challenges. The person in an enterprise who likes to dictate content guidelines and formatting tools will be very frustrated with the relative anarchy of the Web. In this environment, tools that help manage the chaos will be the winners. That's where the new generation of content management systems comes in.
I like to think of the new generation of content management systems as third-generation web-site building tools.
First, there was HTML. In the beginning of the World Wide Web, programmers created most sites by hand-coding files using HTML markup. But it didn't take long for the people who built these pages to tire of the verbose markup that HTML requires. Plus, those static pages were...static. For information that changes often, or sites that have lots of similar information, such as catalogs or personnel information, creating a static page for each item is exceedingly tedious.
The second generation of web-site building involved attaching a custom database. This type of site used a server-side scripting language, such as Microsoft's Active Server Pages (ASP), that allowed developers to programmatically connect to a database or other resources and build a page on the fly. Sites using this type of technology were flexible and could be built in a robust way depending on the skill of the programmer.
The downside to such an approach is that this type of technology creates "one-off" solutions. That is, a programmer would create a site according to some requirements, and then move to the next project and build a site from scratch using new requirements. If he was lucky, the programmer could reuse some components from previous sites.
I've built plenty of sites using both of these approaches. They're great if you're being paid by the hour, but not so good if you need to create sites cheaply or if you have a backlog of sites to build with limited budget resources.
Many programmers started to see the problems with these approaches, engendering a rash of projects where programmers would take the code they developed for a particular site and make it available to some community of programmers, who would, hopefully, take it from there, fix the problems, and extend it. This would propel the original designer into the programmer equivalent of "rock star" and it would be easy street from that point on.
That gets us to what I consider the third generation of web site development: community-supported content management systems. These are development frameworks that usually start as someone's personal project, and then are expanded into something more stable as others work with it.
In the .NET world, the most popular such system is DotNetNuke (see Figure 1-1), which has evolved into a framework for building content-rich sites in a Microsoft .NET environment.
There are other content management systems for Windows. The grandfather is Microsoft's SharePoint, which is mainly used by large enterprises to manage content behind their firewall. It has great support for integrating with other back-end systems such as SQL Server and BizTalk, but it is very expensive. And, while it has an extensive API, it is not very friendly for programmers building customer-facing web sites.
Another content management framework that intrigued me is Sitefinity (see Figure 1-2), which, unlike tools written by volunteers and available for free, is a commercial product and comes with a price tag and support. Sitefinity was written by Telerik, a Bulgarian-based company that makes a great toolkit for .NET programming. I'm a fan of Telerik's toolkits as they have saved me a lot of programming time over the years. But Sitefinity's $900/year license fee and relatively closed environment were a problem. Moreover, the fact that they've been promising version 4 for more than a year lowered my trust of this framework.
Some friends had been using Drupal and liked it a lot. They talked about how easy the platform was for creating sites and yet how it was also programmer-friendly, allowing customization to any level of granularity. They also pointed out the size and quality of the community and the sheer number of add-on packages available. This sounded exactly like what I was looking for, so I embarked on a research mission.
In the open source content management space, three systems seem to come up in research: WordPress, Joomla, and Drupal (see Figure 1-3). WordPress seems to have the largest market share because it is easy to configure and get a site up and running quickly. But it is designed mainly for end-users, who generally use it to write and maintain blogs; the programmability is just not there at this point. Joomla looks slick out of the box and can be customized to some extent, but doesn't seem to have been designed as a foundation for large-scale customization and integration. Also, it doesn't have the sizeablecommunity that Drupal has, particularly in my geographical area. Your results may vary.
Figure 1.3. WordPress, Joomla, and Drupal compete for various types of content management solutions.
But my main problem with all of these systems is that they don't use the .NET Framework. And, with Drupal in particular, that it's written in a language I've never used, PHP. Instead of .NET, Drupal runs on a LAMP stack. Still, it seems to have all of the functionality you'd expect from a third-generation web-site building environment and a large, active support community. Perhaps I could look to this community for support as I learned these new technologies.
Drupal, like many open source web tools, runs under a set of tools known as the "LAMP Stack" (see Figure 1-4). LAMP stands for Linux/Apache/MySQL/PHP. The server is where the stack is, and a browser accesses the site through a call to the web server, Apache. Let's look at the individual pieces.
Linux: The operating system on which all of this goodness runs. Depending on where you're running the stack, this could be a server-oriented flavor of Linux for production sites, or a development-oriented flavor of Linux with a GUI for development work.
Apache: The web server that runs on the operating system and fields calls from web browsers in order to build pages and send them back. Apache invokes various engines to build parts of the page as required by the request. This is the functional equivalent of Internet Information Services (IIS) in the Windows environment.
MySQL: A SQL database that stores all data and configuration information for the web site. MySQL started as a basic open source SQL database and has evolved into an industrial strength platform for relational data storage. I don't think it is as evolved as Microsoft SQL Server or Oracle, but you can't beat the price. Oracle recently acquired MySQL when it bought Sun Microsystems, so there is some concern in the open source community about the fate of MySQL.
PHP: A language for creating web pages. Actually, PHP is a general-purpose language for doing almost any kind of programming, but it is used mainly to build web pages. It is similar in functionality to Active Server Pages in the Microsoft world. Unlike Visual Basic or C#, PHP is interpreted as the page is being created, and so suffers from performance issues. I'll talk more about that, and how to get around such problems later in the book.
All of these pieces are free and community supported. They are open source and are quite robust and secure. All are almost infinitely configurable, which is good, though it can also make tuning seem daunting. Fortunately, you'll find a lot of people who have been there and done that to help with any aspect of configuration.
Since this book is for Windows developers, the first thing we are going to do is to replace the "L" in LAMP with "W" for Windows. It is possible to replace the "A" with "I" for Microsoft's Internet Information Server, but I refuse to work on a system called "WIMP."
So we'll stick with Apache for now. In Appendix A, I'll show you how you can install Drupal to run on IIS and use Microsoft SQL Server as the database. At that point, I guess you'd have a WISP stack.
Drupal is centered on a set of functions that handle basic bootstrapping, database access, error reporting, and other essential services. These programs are called modules and form the system known as the Drupal core.
Core modules provide a significant amount of functionality out of the box:
IP Address Blocking: Access to the site can be managed by restricting IP addresses (see Figure 1-5).
Access statistics and logging: You get information about page accesses so you can determine the popular areas of your site. Logging reports various levels of activity, including unauthorized access attempts and database errors (see Figure 1-6).
Node Access: Any content can be restricted by various parameters, such as the type of user.
Site Status Report: You get a single overview of any problems detected for your installation, as Figure 1-7 shows.
Advanced search functionality: Every piece of every page can be indexed, and searching can be configured to allow your site visitors to find the information they need (see Figure 1-8).
Blogs, books, comments, forums, and polls: The most popular page types are included by default (see Figure 1-9).
Caching: A lot goes into building a page in Drupal. The cache is an important feature for improved performance under load (see Figure 1-10).
Descriptive URLs: Normally, a page in Drupal is numbered based on its identity in the database. Any page can also be given a custom URL for easy access and sharing (see Figure 1-11).
Multi-level menu system: You'll find several menu buckets that can be used to help users navigate the system. Menus can also be customized and access-restricted by user role (see Figure 1-12).
Multi-site support: A single Drupal installation can host many different sites. This makes the process of creating new sites relatively straightforward.
New release update notification: All Drupal modules are updated by their maintainers for bug fixes and security patches. A core module interrogates each module's project page on drupal.org for updates and notifies the administrator when a module has been updated (see Figure 1-13).
Multi-user content creation and editing: Users are assigned one or more roles, which can be configured to allow access to certain content types (see Figure 1-14).
OpenID support: Drupal has its own user logon system but also supports OpenID for users who already have an OpenID account elsewhere (see Figure 1-15).
RSS Feed and Feed Aggregator: The Drupal core has a module that allows RSS feeds from other sites to be used as a content type (see Figure 1-16).
User profiles: Drupal has a rich user-management framework that lets administrators assign roles and permissions to users. This framework is available to programmers so they can integrate user management into their code. See Figure 1-17.
Workflow tools: Certain actions taken by users can trigger events in unrelated modules. For example, creating a blog entry can trigger an e-mail that notifies the administrator of the addition (see Figure 1-18).
Drupal has security built in at the lowest levels of the core code, and the team that maintains the core takes security very seriously. There is also a security team that provides assistance to programmers writing core modules and contributed modules as well.
The security team pays attention to current threats and hacking attempts. It maintains http://drupal.org/security, which reports security advisories for core and contributed modules. In this way, breaches are communicated to module developers so they can issue a patch, in many cases on the same day.
The security team provides information for various purposes:
Site administrators running Drupal sites can find out how to harden their servers against attacks.
Module programmers learn the importance of sanitizing text inputs and formatting outputs safely.
The Drupal core has many security features built in that makes writing secure code relatively painless. Of course, it is up to the module developer to use these features.
Since Drupal is all about content, it's not surprising that it comes with several useful content types. Each piece of content in Drupal is considered a "node" and so all are treated pretty much the same by the database. Understanding the Drupal node is crucial to understanding Drupal itself. Regardless of the content type, the fact that every piece of content has certain things in common with every other piece makes it possible to leverage content in ways that are useful for building a site. For example, the indexing subsystem will create the index database for all content types, and provide that to the search engine, which will return all content. Of course, by now you probably realize that this is also totally customizable—by the administrator in most cases, and the programmer in all cases.
It is in the modules and theming that different contents types might be treated differently.
Out of the box, Drupal makes available the following content types:
Blog Entry: A journal or diary that is kept by a user. The Drupal Blog module lets your site's registered users create their own blogs, which usually consist of a number of blog entry nodes (see Figure 1-19).
Book Page: A content type that's designed to be part of a collaborative book. It is enabled by Drupal's Book module. A collaborative book might be documentation for a programming project or some other ongoingendeavorthat has multiple participants. See Figure 1-20.
Comment: Virtually any piece of content can have comments, which are added by users in reaction to a published piece of content. Comments aren't actually nodes, so they aren't technically a "content type" (see Figure 1-21).
Forum: Drupal's Forum module defines a topic for a forum discussion. Users can reply to the forum topic by using comments. Figure 1-22 shows an example.
Page: Typically, the Page content type is used for static content that can (but is not required to) be linked into the main navigation bar (see Figure 1-23).
Poll: Polls provide a way to ask a multiple-choice question of the site's visitors, and let users vote. Users can answer and see other people's answers to questions. (See Figure 1-24.)
Story: A story is generally used for information whose relevance decreases as time passes (such as a news item). By default, newer stories are typically placed higher on the page than older stories. (See Figure 1-25.)
Field UI: You can also create your own content types with your own fields. This is a very powerful feature as it allows administrators to create data structures and capture information without any programming. (See Figure 1-26.)
In addition to the core modules, an administrator of a Drupal site can add any number of modules contributed by members of the community. These modules supply a dizzying array of functionality and features. In Drupal parlance, these are called contributed modules. There are a certain contributed modules that administrators of most systems install by default because they are so useful. I use a number of these modules in virtually every Drupal site I create. Here are some of the most valuable.
Views: So you have all of this information in your database, how do you expose just what is needed to your users? The Views module is basically a graphical interface for creating SQL SELECT statements to access data. It provides a way to access your data by establishing relationships between records (think JOIN), filtering by content (WHERE), and sorting the results (ORDER BY). Views also provides various presentation hooks you can use later when you are theming the page. (See Figure 1-27.)
Commerce: Drupal was originally designed as a content management system but, given its popularity and extensibility, it was only a matter of time before people started demanding some sort of e-commerce capability. Drupal Commerce is a fork of the popular Ubercart module that has everything you need in a shopping cart system. It provides a cart, payment gateways, inventory tracking, reporting, and other goodies to manage your e-commerce site. Plus, there's a rich API for integrating it into the rest of your site. (See Figure 1-28.)
WYSIWYG: By default, you enter content into Drupal using simple HTML text boxes. The user can be limited to certain HTML tags to do specific things, or the administrator can allow full HTML in this text box. Either way, it's a pain. Isn't this what we did two generations ago? Luckily, the WYSIWYG module allows the installation of a number of different editors that let users edit rich text in a way that's more like modern word processors. I'll pass you the Geritol if you remember watching Flip Wilson's drag persona, Geraldine, on Rowan and Martin's Laugh-In in the late 1960s. For the rest of you, it was Geraldine who popularized the phrase, "What you see is what you get, honey!" (See Figure 1-29.)
Drupal for Firebug: A lot goes into creating a page in Drupal. As a developer, you might want to get a snapshot of certain events as they happen. There's a debugging module for developers that tracks things as they happen and makes them available to the browser. A browser add-on, Firebug was originally developed for Firefox but is now available for Chrome as well. (See Figure 1-30.)
There are hundreds of modules that users have shared with the community to do many different things. These range in quality from excellent in functionality, updating, and support, to fairly useless for most applications. If you are looking for a particular functionality, it's helpful to ask a more experienced person, though some people like to just start downloading the modules and checking them out for their purposes.
Since all of the modules are delivered in PHP source code, you can see exactly how they work and make any changes you need. Changing them is discouraged because you are essentially creating a branch from the main development effort, but if you don't expect to update your customized module, it's not really a problem.
One nice thing about the contributed modules is that they range in price from free to free. Note, however, that some ventures might charge for a particular service. For example, Mollom is a service you can set up on your site to blocks spam from certain forms. The module for doing this is free, and there is a free service that is limited in its protection. However, for more protection and high availability, Mollom offers a monthly subscription. This service is quite popular, which shows that there are people making money by giving away Drupal software.
Once a page is created using Drupal's module engine, it must be formatted and delivered to the user. That is the job of the theming engine. You can do some processing work in your theme, but the main purpose is to get a page to your user. (See Figure 1-31.)
The theming engine receives all of the artifacts of a page that have already been processed. This includes snippets of content (nodes), images and other non-text objects (as file pointers), and other information that might be handy, such as the current user and permissions settings.
You can think of the modules as doing the data portion of the page, and the theme doing the visual part. You can use themes to change the graphical and typographical look and feel of the site, but you can also use them to provide some client-side processing, like AJAX/AHAH server communication and jQuery display automation.
A theme can have a few or many regions where content can be placed. Such pieces of content are called "blocks," and they form one of the basic Drupal object types. (See Figure 1-32.) The block subsystem provides a graphical way to place content in various regions on the page.
Figure 1.32. Themes can use predefined regions for placing blocks of content. (source: shireproduce.com)
Using a theme can be anywhere from zero-effort simple to very complex, depending on what you want to do. Drupal 6 comes with several different themes, and literally hundreds more are available on the Drupal site. We'll discuss themes in Chapter 7.
The Drupal engine is based on a series of hooks. I've heard this referred to as "sorta like object-oriented." Don't believe it. If you fall into the Drupal-is-sorta-like-OO camp, you'll miss the point and end up thinking of Drupal as something it isn't.
Rather, every call to a Drupal site starts at index.php. The PHP code creates a list of modules that have been registered using calls to the database. It then opens each of those modules' PHP source code files and looks for carefully crafted function names. If it finds a function that matches the particular hook the system is looking for, it will execute that function.
That hooked function can, in turn, call other functions that have asked to be hooked to it.
As a .NET programmer, I thought at first that this method was wasteful and redundant. I mean, opening source code files on a production site and scanning for strings? How primitive! How insecure!
But as I started using Drupal, I found that the hook model is quite elegant and is not burdened with the overhead of the huge, albeit pretty well-tuned, .NET framework. Performance is acceptable right out of the box, though it tends to slow down significantly as you add modules because each page is looking for hooks on every page in all registered modules.
Fortunately, you can take advantage of a lot of experience in optimizing the speed. Drupal has an excellent caching subsystem that bypasses the entire hook-searching process for static pages or parts of pages. Plus, there are things you can do to streamline your system once it is ready for production. To be assured that Drupal is designed for high performance, all you need to do is look at some of the high-profile, high-traffic sites that use Drupal.
The Drupal page lifecycle is discussed in Chapter 2.
All data is stored in a central repository. As I mentioned earlier, this repository is MySQL by default. But Drupal 7 comes with a database abstraction layer that decouples the dependency on MySQL, and opens the door to using other databases. And a group at Microsoft has created a SQL Server driver that takes advantage of PHP's data object interface (PDO). I cover this in Appendix A.
Warning
Before you get too excited about cross-database support, you should know that Drupal's support for SQL Server is not so straightforward.
Drupal's core development team is committed to writing to the PDO layer, and the Drupal core is compatible. However, one of the great advantages of Drupal is its community of module contributors. While database abstraction is recommended, it is not possible to force all module authors to adhere to the new standard. The committed users in the community will put pressure on module authors to adhere to the new standards, but until this threat of ostracism is in place, you should realize that you might miss out on a module or two, or be prepared to upgrade your modules to use the database abstraction layer.
Having said that, I am heartened to see that the most popular modules are being written to support the new data abstraction framework.
You'll find core functions that do much of the database access, including the node_load()and node_save() functions that will retrieve a node by its node identifier and store nodes with all of the necessary data.
In addition to specific data access functions, there's also a more generalized data abstraction layer that provides a safe interface to the database and allows for efficient processing of record sets returned. The data abstraction layer is described as being engine-agnostic, but as long as people write SQL code directly in their modules, the database engine is tightly bound.
The data abstraction layer is good for parsing SQL query strings to help guard against SQL injection attacks and other techniques that might lead to an insecure system.
Whenever you need to get some information from a user, you typically use the HTML <form> element. This element contains all of the text fields, check boxes, pull-down lists, and other components that web users are familiar with. And, of course, it has the necessary "Submit" button to post the information back to the web site. (See Figure 1-33.)
Drupal abstracts the form with an engine that can be extended with hooks. The Drupal form engine will take arrays of fields that you pass to it and build the form along with hooks that allow theming of the form. Then you create a couple of callback functions that first validate the information from the form, and then do something useful with it.
A significant amount of thought has been put into making the core secure. There are also guidelines for module developers to assure that they create modules that can't be easily hacked. For example, scanners for SQL code can help prevent SQL insertion attacks. (See Figure 1-34.)
Since Drupal sits (usually) on top of the Apache web server, it can take advantage of Apache's security layers, including file access permissions, compartmentalized execution space, and SSL access.
In addition to best practices for securing code, the Drupal core has built-in safeguards, like user password protection and role-based permissions for all users, e-mail confirmation for new user registration, and stateful session tracking. And that's just in the core.
There are myriad contributed modules that address various security aspects:
Various CAPTCHA techniques using images, math problems, even grammar challenges ("Knives can ____ butter." reflect? heat? play poker with?). I'm not sure I'd pass this one. (See Figure 1-35.)
User access techniques, like ACL (access control lists), LDAP integration, login using OpenID, and modules to blacklist by IP. (See Figure 1-36.) There are also modules for managing the complexity, age, and expiration of passwords.
Legal issues like terms of use, privacy policies, and age validation.
You'll also find modules to check that you're adhering to security policies in your code, and that pages that should be accessed with SSL are redirected to HTTPS.
When we talk about menus in Drupal, we mean more than just a set of clickable links that load pages. There are three such standard menus in Drupal, two of which, Main menu and Secondary menu, are created by an administrator. I usually set the Main menu to standard pages like "About Us," "Contact," or "Home," and the Secondary menu to various interesting pages that may be on the site or may point to external partner sites. (See Figure 1-37.)
Figure 1.37. Two special administrator-created menus are included in Drupal, but you can create any number of specialized menu structures .(source: cdevolution.org)
A third menu, Navigation, is built by the system based on who you are, the role you play on the site, and other, possibly personal, options. All of these menus can be placed in blocks on the page and rendered by the theming engine.
The path of a page is really just an abstraction and does not point to an actual "page" that sits on a server. As I mentioned earlier, all processing starts at index.php. The path is passed to the page processing engine, which interrogates the database to figure out what to display to the user.
For example, http://adoptacrat.com/cratomatic/details will pass "cratomatic/details" to the engine, which will parse it and pass it along to any modules that have registered an interest in dealing with the page. At some point, someone in the chain of hooks will recognize the path and start to build the page. Once it's built, the content is passed to the theme engine, which might also do something with the path string before sending the completed page back to the browser.
Note
You might notice I said that everything starts at index.php, but then I showed a URL that doesn't include index.php. Which is the lie?
Neither, actually. Drupal takes advantage of the "rewrite url" functionality of the web server (both Apache and IIS support this through external modules). The rule for rewrites will turn the example URL above into http://adoptacrat.com/index.php?q=cratomatic/details by the time it gets to the Drupal engine.
What good is a site that doesn't have users? This reminds me of something I overheard at Sears. Two tired sales clerks were talking behind the cash register and said, "This would be a great job if it weren't for the customers!"
When you create your site, the setup subsystem asks for the site administrator. This is a special user who has access to absolutely every aspect of the system. If you like, you can set up other users who have almost as much control as the super user.
Every user has one or more roles. When a person first accesses your site, she is considered "anonymous" and given a role of "anonymous user". Drupal has a rich, extensible permissions framework that gives the administrator the flexibility to grant virtually any permission to any role. And as a programmer, you can plug into the permissions subsystem and provide whatever granularity of access for your module you feel appropriate.
Drupal is a third-generation web development engine that provides content management, forms management, and a rich platform for custom development. The Drupal community of users and developers is vast, and seasoned developers are eager to help new users get started.
The amount of contributed code is so extensive that there's a good chance that whatever you need to do, a "module for that" probably already exists. And if a contributed module doesn't do exactly what you need, you can rest assured you can get help to create your own module or customize an existing one. In the next chapter, I'll walk you through the lifecycle of a page as it is rendered through Drupal's engine and point out how it differs from the ASP.NET page lifecycle.