Out of the box, Drupal 7 performs all of the standard functions of a web-based content management system. Visitors can view published information on the site, navigate through menus, and view individual pages, complete with images. Users can create accounts and leave comments. Administrators can manage the site configuration and control the permissions levels of users. Editors can create content, preview it, and then publish it when it is ready. Content can be syndicated to RSS, where feed readers can pick up new articles as they are published. With several built-in themes, even the look and feel of the site can easily be changed.
As fantastic as these features are, they will certainly not satisfy the needs of all users. To that end, Drupal's capabilities can be easily extended with modules, themes, and installation profiles. Take a look at Drupal's main website, http ://drupal.org, and you will find thousands of modules that provide new features, and thousands of themes that transform the look and feel of the site.
The fact that almost all aspects of Drupal's behavior can be intercepted and transformed through the module and theme mechanisms has lead many to claim that Drupal isn't just a Content Management System (CMS), but a Content Management Framework (CMF) capable of being re-tooled to specific needs and functional requirements.
Whether or not Drupal is rightly called a CMS or a CMF is beyond our present interests, but it is certain that Drupal's most tremendous asset is its extensibility. Want to use a directory server for authentication? There's a Drupal module for that. Want to export data to CSV (Comma Separated Version) files? There are several modules for that (depending on what data you want to export). Interested in Facebook support, integration with Twitter, or adding a Share This button? Yup, there are modules for all of these too—all of which are available at http://drupal.org/.
Want to integrate Drupal with that custom tool you wrote to solve your specific business needs? There may not be a module for that, but with a little bit of code, you can write your own. In fact, that is the subject of this book.
The purpose of this book is to get you ramped up (as quickly as possible) for Drupal development. As we move chapter by chapter through this book, we cover the APIs and tools that you will use to build custom Drupal sites, and we don't stick to theory. Each chapter provides working, practically-oriented example code designed to show you how to build code. We follow Drupal coding conventions and we utilize Drupal design patterns in an effort to illustrate the correct way to write code. While we certainly can't write the exact code to meet your needs, our hope is that the code mentioned in this chapter can serve as a foundation for your bigger and better applications.
So let's get started with a few preliminary matters.
Many books of this ilk will begin with a chapter on installing the platform. We have decided not to follow this pattern for a few reasons. First of all, Drupal is incredibly well documented in this regard. The
README file included with Drupal's download should meet your needs. Secondly, our experience has been that such chapters are unnecessary. Software developers rarely need step-by-step guides to installing a system as simple as Drupal.
However, what we do want to start with, is a quick overview of the technologies utilized in Drupal.
Drupal is written in the PHP programming language (http://php.net). PHP is a widely supported, multi-platform, web-centric scripting language. Since Drupal is written in PHP, this book is largely focused on PHP development.
One specific piece of information should be made explicit: As of Drupal 7, the minimum PHP version is PHP 5.2 (as of this writing, the current version of PHP is 5.3.3). Prior versions of Drupal included PHP 4.x support, but this is no longer the case.
Another thing worth mentioning is the style of PHP coding that Drupal uses. While many PHP applications are now written using Object Oriented Programming, Drupal does not follow suit. For many reasons, some historical, some practical, Drupal is largely written using p rocedural programming. Rather than relying strongly on classes and interfaces, Drupal modules are composed of collections of functions.
Before anyone jumps to conclusions, though, we would like to make a few qualifications on what we've just said:
Drupal frequently uses objects
Drupal does have certain subsystems that are object-oriented
Many Drupal modules are substantially object-oriented
Drupal makes frequent use of design patterns, for it is certainly the case that procedural code can use design patterns too
While the majority of this book uses procedural coding strategies, you will encounter OOP here and there. If you are not familiar with object oriented conventions and coding styles, don't worry. We will explain these pieces as we go.
In the past, Drupal has supported two databases: MySQL and PostgreSQL. Drupal 7 has moved beyond this. Drupal now uses the powerful PDO (PHP Data Objects) library that is standard in PHP 5. This library is an abstraction layer that allows developers to support numerous databases including MySQL, PostgreSQL, SQLite, MariaDB, and many, many others. While Drupal does testing on only a few specific databases (namely, MySQL, PostgreSQL, and now SQLite), it is possible to move beyond these to SQL Server, Oracle, DB2, and others.
However, for the sake of size and readability, we have focused our examples on MySQL. We believe that our SQL should run on MariaDB, PostgreSQL, and SQLite without modification, but we have not made any attempt to test against other databases. If you find a bug, we'd appreciate hearing about it. Packt Publishing tracks errata on their website (http://packtpub.com), and you can submit errors that you find through the form you find there.
Drupal provides a database API along with some SQL coding conventions (such as "don't use LIMIT in your SQL"). The intent of these is to combine code and convention to make it as easy as possible to write portable code. Thus, we not only illustrate the API throughout this book, but we also focus on writing SQL statements that comply with standard Drupal conventions.
The de facto web data format is HTML (HyperText Markup Language) styled with CSS (Cascading Style Sheets). Client-side interactive components are scripted with JavaScript. As Drupal developers, we will encounter all three of these technologies in this book. While you needn't be a JavaScript ninja to understand the code here, you will get the most from this book if you are comfortable with these three technologies.
The Internet thrives on change, it seems, and there are many other web technologies that have become common. Here and there, we will mention technologies such as RSS (Really Simple Syndication), XML (eXtensible Markup Language) , XML-RPC, and others. However, these are all of secondary importance to us. While Drupal offers support for many of these things, using them is not integral to module or theme development.
Apache has long been the predominant web server, but it is by no means the only server. While Drupal was originally written with Apache in mind, many other web servers (including IIS, LigHTTPD, and nginx) can run Drupal.
We do not explicitly cover the web server layer anywhere here, primarily because development rarely requires working at that low level. However, Drupal expects a fair amount of processing from the web server layer, including handling of URL rewriting.
Note
Windows, Linux, Mac OS, BSD. These are terms that spark modern online holy wars. However, we don't care to take part in the argument. Drupal will run on most (if not all) popular server operating systems, including Windows and many UNIX/Linux variants.
In the interest of full disclosure, the authors of this book work primarily on Linux and Mac OS X systems. However, our code should run on any Drupal system. Again, if you find examples where our code does not run because of the operating system, submit an erratum on Packt Publishing's website. Drupal strives to be cross-platform, and so do we.
With these preliminaries behind us, let's move on to Drupal's architecture.