It's finally here! After nearly three years of development, Drupal 7 is now available for use on production sites! Drupal 7 is loaded with tons of great new features aimed at novice as well as experienced website administrators.
If you have been reluctant to try Drupal because you thought the learning curve would be too difficult or that it would be hard to install Drupal, you will be pleased to know that the installation process has been streamlined and the administration interface has been made more usable and easier to learn. Several commonly-used features have now been included into the base Drupal installation, so they are easily available to everyone.
Power users of Drupal will also rejoice at new time-saving improvements to make it easier to build custom modules and themes. Experienced users will also benefit from improved organization in the new administration interface as well as other new, built-in features included in Drupal 7.
When development on Drupal 7 first started, there were several goals that Dries Buytaert, the founder of Drupal, laid out. They are as follows:
Better media handling: Make it easier to add images, Flash, Flex, and so on to websites built with Drupal.
Custom content types in core: Integrate portions of the CCK module into core to allow site administrators to apply this functionality more easily.
WYSIWYG editor: Incorporate a What You See Is What You Get HTML editor into core, so editors can add formatted text to their sites more easily.
Better performance and scalability: Make sites built on Drupal leaner and faster to load, improve performance for users that are logged into the site, and make it easier for Drupal to be used on sites that get lots of traffic.
Better tools to structure/organize content: Make it easier to create a meaningful site structure to hold all content in a way that makes sense for both administrators and visitors.
Automatic upgrade functionality: Allow site administrators to download and install updates to Drupal, contributed modules, and contributed themes without needing to download and unpack tarballs and then manually deploy them to a site, making Drupal as easy to upgrade as your operating system.
Improved node access system: Improve control and permissions for who can access which nodes and what they can do to each node.
Better internal APIs: Make it easier to maintain Drupal and add custom modules for site-specific functionality.
Better external APIs: Make it easier to import data into a site and export data from a site. Improve functionality allowing administrators to consume and expose web services.
Usability: Reduce the learning curve for new users and make common tasks faster and easier to get to for experienced users.
These primary goals were taken from a poll conducted on the official Drupal website (http://drupal.org), and are reflective of the opinions of over a thousand people in the Drupal community. The goals for Drupal 7 also reflect a stated plan of focusing more on the end user and larger websites.
As with any project, not all of the initial goals were completed and several additional features were incorporated that weren't part of the initial plan. Let's look at the key functionality that did make it into Drupal 7.
The first thing you will notice if you are installing Drupal 7 for the first time is the new installation routine. The new routine is designed to make it easier for new Drupal users to set up Drupal. The new installation offers two types of install—the regular installation and a minimal installation.
The Minimal installation is similar to previous versions. The new Standard installation automatically enables commonly-used functionality during the installation to save time after setup. The installation also automatically performs common startup tasks, like building an administrator role. Finally, the new installation system also allows for command-line installation of Drupal.
We will explore installation and updating in more detail in Chapter 5.
After installing or upgrading to Drupal 7 you will immediately notice the new administration toolbar (shown in the following screenshot) that appears on all pages if you have the permission to administer the site:
The toolbar groups commonly used tasks together making it easier for new administrators to learn how to configure Drupal and making it quicker for experienced administrators to get to commonly-used functionality.
Selecting an option from the toolbar will open a new overlay window, so you can change configuration options without losing your place on the site.
An example of the overlay panel is shown as follows:
Power users can disable use of the overlay window either by removing permission to use the overlay panel or disabling the overlay panel.
We will review the dashboard and new administration interface in detail in Chapter 3.
A big, but welcome, change for editors is the redesigned and updated interface to create and edit content. A sample of the interface is shown in the following screenshot:
The redesigned screen makes it easier to quickly navigate to specific sections within the content. It is also a more intuitive interface. We will dive into creating content in depth in Chapter 2.
In Chapter 2, we will also explore the new, more intuitive, interface for building content types, which is shown in the following screenshot:
The interface for creating content types has been redesigned to keep all of the options in a smaller space so navigation is easier and all information can be quickly accessed.
A welcome sight to many Drupal administrators and editors is the inclusion of the Field API in Drupal core.
The Field API was built from the Drupal 6 CCK (Content Construction Kit) contributed module. It allows site administrators to add additional attributes to a node type. A field can have a variety of different types and be displayed in many different widgets (user interface elements). The Field API also supports translatable fields to allow for multi-lingual sites. We will explore the Field API in detail in Chapter 2.
Building on the new Field API, Drupal 7 offers two new types of fields that will be useful on many sites—the file field and the image field. The file field allows editors and users with proper permission to upload files and attach them to nodes. The file field also gives administrators a wide range of configuration options to control the type and size of files that can be added, where the files are stored, and how the files are displayed within the node.
The image field builds on the file field to add functionality specifically needed for images. Image fields can be added to content types and configured much like any other field.
After adding an image field to a content type, you can control how the resulting image is displayed on the site through a series of simple configuration options on the field. Users with proper permissions can upload images directly to the site and Drupal will take care of resizing the images to generate thumbnails for proper display on your site. Drupal 7 also has new functionality to allow rotating and applying various other effects to images.
We will explore all of the new file and image features in Chapter 2.
Filters allow administrators to control what can be inserted into text fields. For example, an administrator can only allow basic formatting like bolding and italicizing text to be inserted into content. Or, they can allow more advanced functionality like linking to images and inserting tables. An administrator can even allow PHP to be inserted within a text field. Drupal 7 renames Input Filters to Text Formats and adds some additional capabilities including the ability to assign text formats to different roles using the permission system. We will explore text formats more in Chapter 2.
Translators and administrators of multi-language sites will love the new contextual information for messages. In prior versions of Drupal, one of the issues translators faced was messages that were used in different situations and therefore had different meanings. The problem was worse with short messages consisting of only a few words because the meaning could be more easily confused. Drupal 7 adds an optional context for the translation to allow developers and themers to make translatable strings less ambiguous. Because the context information is optional, performance is not negatively impacted. We will touch on translations throughout the book as appropriate, but most of the information on translations will be found in Chapters 2 and 3.
Many site administrators will be pleased to see the inclusion of a new cron system for Drupal that does not rely on running cron from the Unix cron system. In previous versions, this could be one of the most confusing and difficult configuration steps for a new site administrator. Now, it is a simple matter of selecting how often you want cron to run. The mechanism used is similar to the one used by
poormanscron except that it runs from an AJAX request rather than delaying the response time of the page triggering cron. We will explore the new cron functionality more in Chapter 3.
Security is always important to site administrators and Drupal 7 will please security-conscious administrators with several important new security enhancements including:
Cron is now secure and requires a key to be run from remote sites. This can help prevent denial of service attacks and overloading the server processor
Improved password protection including a new pluggable password system and stronger password hashing
Limiting invalid login attempts to prevent brute force attacks
Improved IP address blocking
Chapter 3 will cover these and many more security changes in detail.
While we talk about security and improvements to administration in Chapter 3, we will also cover the brand new plugin manager. The plugin manager allows automatic updates of your Drupal installation. The plugin manager will automatically download the appropriate updates from the Drupal website via FTP and place the downloaded packages on your site in the correct locations. The module has appropriate permissions to ensure that the update process is carefully controlled so the administrator knows exactly what is occurring.
A common complaint of Drupal administrators in previous versions was the look of the administration interface and that it could be difficult to tell when you were in the administration interface, since it used the same theme as regular content by default. To fix this, Drupal 7 has added a new administration theme called the Seven theme that is enabled by default.
The Seven theme uses a single column layout with muted colors and is an obvious contrast to the default blue colors of the default user themes. The following are a couple of samples showing how it appears on different pages (with the overlay disabled):
The Garland theme is still used by default when viewing content. Drupal 7 preserves the ability to modify the administration theme to be any theme you want or to set the administration theme to always be the default site theme.
Drupal 6 added the ability to add and modify variables to be rendered in a preprocess hook before the variables were rendered in a template. This functionality has been enhanced with the addition of a process hook that is invoked after all preprocessing is done. Drupal 7 also allows hook functions to define preprocess and process hooks, so they can manipulate variables as well. We will review these API changes in more detail in Chapter 6.
Several core Drupal 6 themes, which were not widely used and served mainly as examples, were removed in favor of the new Stark theme that is designed to make it easier to learn how to build a custom theme. The Stark theme should not be used on its own since it is not very attractive. However, it serves as a reference point for understanding the default HTML that Drupal emits as well as the default styling that Drupal provides. This information can be used to help identify problems with custom themes or to identify conflicts with modules that have been enabled. We will use the Stark theme in Chapter 6 as we review changes to Drupal's default themes and styles.
Arguably the biggest change in Drupal 7, at least for developers, is the new database layer, also called DBTNG (short for Database Layer: The Next Generation). DBTNG is a big change for developers since it changes how modules interact with the database. We will explore DBTNG in great detail in Chapter 7, but here are some of the highlights:
Includes a new database layer built on PDO (PHP Data Objects). PDO provides a consistent lightweight interface for accessing a wide variety of databases including MySQL, PostgreSQL, SQL Server, and Oracle. More information about PDO can be found at: http://www.php.net/pdo.
Adds a query builder to handle creating
DELETEstatements. The query builder is designed to make accessing the database easier, more extensible, and more secure.
Provides support for replicating databases in master/slave and master/master configurations.
Improved support for connecting to multiple databases at a time.
Support for transactions when using transactional databases, with proper fallback when not connected to a transactional database.
There are many other exciting changes in the DBTNG layer that we will review in more detail later.
Several changes have been made to the underlying node access system to improve the granularity of permissions, improve security, and make it easier for developers to properly maintain restrictions to nodes.
The first major change is the splitting of the administer nodes permission into two permissions, administer nodes and bypass node access. This allows administrators to give users the ability to administer only nodes to which they normally have access. We will discuss this further in Chapter 4.
The next major change is the ability for custom modules to influence the access to nodes even if they did not define the original access rules for the node. This gives developers more control over the logic needed to control access to information and functionality of the site. We will review these new APIs in Chapter 7.
Another change is a one step function call when using the DBTNG layer that instructs DBTNG to add node access restrictions to the query. This will make setting up proper security restrictions much easier to include and it will be easier to detect potential node access bypasses during code reviews. We will cover this API in more detail in Chapter 7.
Lastly, Drupal 7 adds additional restrictions for who can access unpublished content. We will review this change primarily in Chapter 3, but we will also touch on it in Chapter 7.
Eventually, most websites find a task that takes a long time to perform and can't be optimized enough to be completed before the web browser times out. To take this situation into account, Drupal 7 adds a Queue API to manage long-running tasks. In general, any task that takes more than 30 seconds to a minute would be an excellent candidate for the Queue API. We will walk through the Queue API in Chapter 7.
Drupal 7 adds a comprehensive test framework called testing that allows developers and site administrators to run tests against an existing Drupal installation to ensure that it is behaving properly. Developers of custom modules can create their own tests to ensure that their module works properly and that the functionality does not regress when new versions of Drupal are released.
Portions of the test framework were back ported to Drupal 6 as the
SimpleTest test framework, so you may already have some familiarity with it. We will look into the Test framework in more detail in Chapter 7.
A key concept of Web 3.0 sites is the use of Semantic Web technologies that allow sites to provide additional information about the meaning of the content provided within the site. One of these technologies is RDF (Resource Description Framework), which adds metadata to a page to give additional contextual information about the information on the page. Providing RDF information can help search engines and other applications to better understand your content, which may lead to improved search engine positions and more site visitors. Drupal 7 allows RDF information to be attached to entire nodes as well as fields within a node using the RDFa specification.
Like any major development project, there are always a few things that you would like to implement but couldn't complete for various reasons. For Drupal 7, there were two initial goals that were not completed.
Initially, putting a WYSIWYG editor into Drupal was desired to help content editors to edit their sites more easily. However, this effort was postponed from Drupal 7 due to the lack of a standard WYSIWYG editor that could be included and the need for more design to create a solution that will work for a majority of users. Although there is not a full-fledged WYSIWYG editor in core, a number of changes have been made to core to help future integration efforts. We will review these changes more in Chapters 2 and 3. Much of the work that was done for Drupal 7 is now available in the contributed WYSIWYG module (http://drupal.org/project/wysiwyg). We will review the WYSIWYG module in more detail in Chapter 4.
The other main goal that was not realized was the inclusion of Views within Drupal core. This is primarily due to the complexity of Views and determination of whether or not the entire functionality of Views should be included in Drupal 7 or if only a subset of the functionality belonged within Drupal 7. However, several concepts that originated from the Views interface have migrated into Drupal core and the new DBTNG API makes it easier for developers to create complex queries of the Drupal database.
An important attribute of the Drupal development process is the concept that changes need not be backwards compatible with previous major versions. This allows Drupal developers to make changes to the underlying structure of the code making it more robust, easier to maintain, easier to extend, and faster. Sometimes these changes are transparent to site administrators, developers, and themers. In other cases, you may need to make changes to your site, module, or themes to take advantage of this new functionality or make it compatible with the changes.
We will explore these changes in detail in future chapters, but here are some of the major changes that may affect your sites, modules, and themes:
The footer message and mission statements have been removed and replaced with a simple custom block. Old sites will be upgraded during the installation process if they used the footer message or mission statement.
A new default region called help has been added in addition to the default regions: header, left, right, content, and footer.
The content region is now required and the main text of a page is rendered as a block to allow other blocks to appear before it in the content region.
.infofile. Similarly, all code files must be identified in a module's
.infofile. This will help to improve overall performance since Drupal will not need to constantly scan for which files to include.
The search box no longer needs to be rendered by the theme. It is now part of the block system and can be rendered in any location using standard block functionality.
The Taxonomy API has been reworked to make it easier to use and to make it more consistent with other APIs. We will cover this in more detail during Chapter 2.
Several APIs have had parameters added, deleted, or renamed. Some functions have been renamed or removed entirely. We will cover these in detail during Chapter 7.
In addition to these changes, several other modifications have been made to Drupal's core functionality, which we will explore throughout the remainder of this book.
The developers of Drupal adhere to the principle that simpler is generally better. Therefore some of the functionality that existed in the Drupal 6 core has either been removed entirely, moved into a contributed module, or removed in favor of existing contributed functionality. Here are some of the functionalities that have been removed as well as some suggestions for replacing that functionality if you relied on it in a Drupal 6 site:
Blocking of IP addresses using ranges has been removed. You can block single IP addresses within Drupal. However, blocking by range should be done at the operating system or firewall level.
Removed Bluemarine, Chameleon, and Pushbutton themes and made them contributed themes. These can be accessed at:
Removed per-user themes. Users can no longer select which theme they want to use in the default Drupal installation. There are several contributed themes that contain similar functionality and either allow users to change their entire theme or select between various color variations to customize the site.
mime_extension_mappingvariable that allowed files to be remapped to different file types. This can now be done using the
The footer message and site mission settings have been removed and can be recreated with a custom block.
The Blog API module has been removed and replaced with a contributed module. (http://drupal.org/project/blogapi). There are also several other contributed modules that perform similar functionality.
Removed the Ping module that broadcasted a message to other sites when your site was updated. There are several other contributed modules that have similar functionality.
Removed the Throttle module that disabled site functionality when the site became busy. The Throttle module was removed because it was less effective than other methods (like aggressive caching) at improving performance, and because it was not widely used. Administrators interested in this module should consider using other caching techniques to improve performance.
One of the major problems when moving from Drupal 5 to Drupal 6 was the slow rate of migration for many of the modules and themes that were contributed to the Drupal project by Drupal community members. If a site relied on a module that had not been updated, they had to delay upgrading their sites, assist in conversion efforts, find an alternative solution, or rebuild the existing functionality themselves. Thankfully, this should not reoccur with migrations from Drupal 6 to Drupal 7. A large number of module maintainers pledged to have full releases of their modules available the day that Drupal 7 is released. This list includes several key modules that are used by many sites.
We will look into some of the contributed modules that have Drupal 7 releases in Chapter 4, with information about changes you may need to make if you are using them in your Drupal 6 site.
Implementing all of these features does require some upgrades to other software on your server. Drupal 7 now requires PHP 5.2.0 or later to run the Drupal code. You will also need one of the following databases to run Drupal 7:
Most hosting companies will already have these installed, but if your server is a little out of date, now is the time to update.
As always, you can use either Apache HTTPD or Microsoft IIS for a web server, but Apache is recommended for best performance and community support.
In this chapter, we covered the most important changes and new features of Drupal 7 at a very high level. I hope that we have piqued your interest in Drupal 7 and that you are ready to dive into Drupal 7 in more detail. We will start our in-depth investigation by thoroughly reviewing changes and new functionality related to the content management system of Drupal 7.