A lot of basic concepts from Drupal 6 are still present in Drupal 7, but there have also been lots of changes in the new version. The Drupal 7 release cycle was the longest to date, which gave developers a lot of time to pack in a ton of new features as well as make some significant changes to existing features. For those people coming from Drupal 6, we’ll take a look at some of the biggest changes and note any “gotchas” to look out for.
Let’s start off with things that are new in Drupal 7 core. Some of these are brand-spanking-new, while others are features that used to be in contributed modules for Drupal 6 that have now been integrated into core. These are the biggest items from a long list that you will notice right away and will have an impact on your new sites.
The first thing that many people will be struck by with Drupal 7 is that it looks quite different when you first install it. There is a new default core theme, named Bartik, shown in Figure D-1. Bartik was written from the ground up as a new, modern design that also provides a guideline for theming best practices. Bartik offers many more regions for structuring the site than Drupal 6’s old default theme, Garland. Like Garland, it also has “Color module integration,” which lets you recolor sections of the theme, such as header background and links, in the appearance settings.
To help visually separate Drupal’s backend and frontend, Drupal 7 also ships with a new theme called Seven, pictured in Figure D-2. Seven is a theme designed specifically for use in Drupal’s administration section, to help provide a visual cue between tasks that only privileged users can perform (i.e., everything under the admin/ URL and, optionally, the node edit forms), and the frontend of the site that all visitors will see.
The final new theme in Drupal 7 is called Stark. This theme isn’t designed to look pretty, but rather is intended to be a tool for theme authors. When you enable Stark, you will see the bare-bones default HTML and CSS that Drupal core creates, as shown in Figure D-3. Stark provides only minimal CSS of its own—just enough to provide a basic layout so sidebars show up in the correct place. You can use Stark as a starting place for creating your own CSS-only themes. Stark shows you the raw HTML so you can dive straight into the fun of styling with CSS.
Another thing that looks very different out of the box is the entire administrative user interface (UI) for Drupal 7. In addition to the new Seven theme, there are five new modules that have been added in order to make Drupal easier to navigate and less overwhelming. These modules are all enabled by default when you do a fresh installation of Drupal 7, but if you are upgrading from a Drupal 6 site, you’ll need to enable them yourself:
- Toolbar module
This new module provides a menu of all the main administrative links across the top of the screen. It allows you to have handy access to all administrative tasks as you move around the site, without affecting the design or layout of the underlying theme.
Note
For more advanced users and site builders, the “Administration menu” module (http://drupal.org/project/admin_menu) provides a more fully featured toolbar with drop-downs for subnavigation and additional helpers.
- Shortcut module
While the toolbar provides links to all administrative functions, often an individual person’s duties on the site will be limited to just a handful of frequently accessed links. Enter the Shortcut module, which provides a second toolbar for your own most-often-used administrative links. An administrator can provide default shortcut sets, or users with the proper permissions can create their own. If the Toolbar module is being used, the shortcuts will appear in a bar under the main toolbar navigation. There is also a Shortcuts block available, which can be placed in a page region, just like a regular block.
Figure D-4 shows the Toolbar and Shortcut modules being used together.
- Dashboard module
This module adds a Dashboard landing page, pictured in Figure D-5, which provides a drag-and-drop interface for placing blocks. This allows you to create a nice overview page of common things you want to keep track of on a regular basis.
- Contextual Links module
If you hover over a piece of content or a block, you will see a small gear icon with a drop-down list of administrative actions you can take that pertain to that specific item, as shown in Figure D-6. This functionality is provided by the new Contextual Links module, which makes getting to the place you want to go to do work much faster since you don’t have to remember or drill down to the menu in the administration panel that contains it.
- Overlay module
The Overlay module, pictured in Figure D-7, opens a lightbox-style pop up for performing administrative tasks, instead of taking you to a new page. This system works particularly well with contextual links, as it allows you to click a link on the frontend to be taken to the appropriate administrative section, make your changes in the overlay window, and when finished, close the window to return to the original frontend page without losing your context.
All of these features can be enabled and disabled individually, as you see fit. They do not depend on one another, but they have been designed to work well together to create a more productive administrative environment. An overview of these new modules is available in Chapter 2.
In addition to a whiz-bang new look and handy administrative tools, Drupal 7 offers some significant new site building features as well. The Content Construction Kit (CCK) was a top module in Drupal 6, used on almost all Drupal sites. Most of the functionality of CCK has now been incorporated into core as the Field module.
The field functionality in Drupal 7 also improves upon CCK in the following ways:
Fields can not only be applied to content, but to anything in Drupal that declares itself as an “entity”: users, taxonomy terms, and comments are supported out of the box, with many more options from contributed modules.
The storage for fields is also swappable. By default, field values are stored in an SQL database like Drupal itself. However, additional modules can save field data to external services, such as Amazon S3 or Mongo DB.
Core comes bundled with a large list of field types, pictured in Figure D-8, and like CCK, ships with Text, List, Number, and Options (select lists, radios, and checkboxes) modules. Just like in Drupal 6, you can extend this list further with contributed modules.
You may notice that a few of the “core” CCK field types that were provided in Drupal 6 are not in this list. These are now provided by contributed modules in Drupal 7:
The Node Reference and User Reference features are now provided by the References module.
Content Permissions is now provided by the Field Permissions module.
Fieldgroups are now provided by the Field Group module.
The Content Copy module does not have a direct replacement per se, but the Features module for Drupal 7 will allow you to export and import fields and content types.
There is a Drupal 7 version of the CCK module, but its main purpose is to provide an upgrade path from Drupal 6 CCK to Drupal Field. It also provides a few helper functions for special features you may have used with your Drupal 6 CCK fields, like using PHP within the field.
For an introduction to using the core Field module along with a few contributed fields, you should review Chapter 3.
Another group of contributed modules that has made its way into Drupal core relates to images. In Drupal 6, there was a common contributed module recipe for adding images to your content, since core did not provide any image handling. This recipe included the Filefield, Imagefield, Imagecache, and Image API modules. These are now all in Drupal 7 core itself:
Filefield is now the core File module, which provides a “File” upload field. The File module replaces the old core Upload module.
Imagefield is now the core Image module, and this provides an image field that can be attached to content types, users, and so on. It relies on the File module for uploading the images.
Imagecache is now known as Image Styles in core, pictured in Figure D-9. Image Styles lets you automatically manipulate images that have been added to the site.
Image API has been incorporated directly into the core’s image handling code. It isn’t visible in the UI, just as Image API was not.
Figure D-9. Image Styles provides automatic image manipulation effects such as cropping and resizing
You can read more about how to use the new core image handling features in Chapter 4.
A brand-new, exciting feature in Drupal 7 is the ability to update your modules and themes from within your Drupal administrative interface instead of having to dig into the server’s filesystem. The new core Update Manager, pictured in Figure D-10, will let you know which of your modules or themes have updates available, then install the updates directly through the UI.
Figure D-10. Update Manager allows users to install and upgrade their modules and themes from the administrative interface
You can read all about the update process and using the Update Manager module in Appendix A.
There are a few other interesting things that have been added in Drupal 7, although you aren’t likely to see or directly interact with them very much:
- Minimal installation profile
During the installation process, you now have two profiles to choose from: Standard and Minimal. Most people will use the Standard profile, but if you want to install Drupal without any features turned on, you can use the Minimal profile instead. This way, you don’t need to turn off lots of things that Drupal would normally install for you.
- RDFa
Using the new Resource Description Framework (RDF) module, Drupal now outputs machine-readable metatags in site output, embedded in the HTML. Various services on the Web, such as Google, can then use this metadata to provide more context around the information, as well as tie your content to other information sources on the Web. Basic RDF is included in core now, and if your theme is using Drupal 7 theme best practices, you will have RDFa tags added to your content HTML without having to do any extra work. You can read more about RDF and Drupal at http://drupal.org/documentation/modules/rdf.
- cron out of the box
cron is a way to run scheduled tasks on your site. This is important to keep things such as old error log entries tidy and provides functionality for things that don’t necessarily happen immediately, such as content search indexing. Normally, you run cron by having your server trigger a script within Drupal, but it can be complicated to set up, and is a step often forgotten. In Drupal 7, a method fashioned after the Poor Man’s Cron module allows cron to be triggered in the background at set intervals when visitors load pages on your site.
- Increased security
Drupal 7 includes a number of security improvements over Drupal 6, including requiring users to enter their current password in order to change it, limiting login attempts to prevent brute-force password attacks, adding a new permission for running the update.php script, and providing much stronger encryption to user passwords stored in the database.
- Better private file handling
In Drupal 6 and below, the decision to use private or public files was a one-time choice that you had to make at the beginning of the site creation, and applied to all file uploads on the entire site. In Drupal 7, private and public files are stored in separate places, so they can be used interchangeably and you can decide on a per-file field basis whether uploads should be private (in the case of sensitive documents) or public (in the case of product thumbnails).
In addition to brand-new features in Drupal 7, a few things that have been around for a while got an update.
The most notable change is obvious when you look at the administration navigation. If you go to the main administration page (admin), you will see that things are organized differently than they were in Drupal 6, in addition to some terms being changed. This reorganization and renaming is also apparent in the Toolbar module’s list of top-level links for handling administrative tasks. There was a large user experience (UX) project for Drupal 7 called D7UX that brought a fresh look to how Drupal’s administrative interface is organized. The reorganization is designed to guide a new administrator intuitively by using terminology and categorization that is more accessible to the average person. For instance, you will find administration tasks for creating and managing users and permissions on the site in the People section.
While this new interface takes some getting used to, it’s now much more task-oriented than before, so hopefully you’ll find your way around quickly!
As we mentioned previously, Drupal 7 now comes with an internal way to trigger the cron script. The preferred method to run the cron script, though, is to have a server trigger it. This is a more reliable method, and reduces the amount of work your Drupal site must do. In Drupal 6, you just needed to point the server cron to the cron.php file, and it would fire it off when scheduled. You could also just type the URL (http://example.com/cron.php) into any web browser and trigger the cron that way. In Drupal 7, more security was added to the cron URL so that not just anyone can fire the cron script on your site. When using cron in Drupal 7, you need to get a special URL for the script by going to the administrative toolbar and clicking Reports→Status Report (admin/reports/status), and then you will see the external link in the “Cron maintenance tasks” section of the report.
Input formats, renamed to “Text formats” in Drupal 7, got a major revamp in this release. You can now provide default text formats for different roles by reordering them on the administrative screen, so anonymous users can default to Filtered HTML, while editors default to Full HTML. Access to text formats is now controlled on the Permissions page, along with all other access permissions, for better consistency. And finally, a new “Plain text” format is available as a fallback for all users if no other formats are accessible.
As things progress in the world of the Web, there are also some things that inevitably get left behind. Drupal core tries to be very focused on providing features that a majority of people would need for their sites, leaving the contributed world to add on lots of bells and whistles. This means that a few outdated features have been removed from core. Many, but not all, of these features have new modules in contrib, so you can continue using the feature it provided in core. If a feature you rely on is not fully upgraded to Drupal 7 yet, you should consider helping out in the issue queue by either supplying patches or helping to test and review the work that the developers are doing. The following modules have been removed from Drupal core:
Blog API has been made into a contributed module. This module allowed desktop blogging software to post new content to, and edit existing content on, a Drupal site. The development has been slow, and so at the time of this writing the module is not fully functional in Drupal 7, nor is there an upgrade path for this feature from Drupal 6 to 7.
The Ping module functionality, plus more, is already provided by the existing contributed Multiping module. The work for upgrading this module to Drupal 7 has started, but at the time of this writing there is no working version available yet.
All of the core themes were removed from Drupal 6 except for Garland. The Bluemarine theme, Pushbutton theme, and Chameleon (and Marvin) themes are all now contributed themes, and they all have Drupal 7 versions available.
The Profile module has been removed from new Drupal 7 installations (the module still exists for legacy purposes), and there are two ways to achieve the same features in Drupal 7, depending on which ones you are looking for in particular. Drupal core fields can be added to any entity, not just nodes, so you can easily add fields to a user (and the user registration form) by just using core fields. The contributed Profile 2 module provides more features, like private fields.
The Upload module has been replaced by the core File module in Drupal 7, which provides a file upload field that can be attached to nodes, users, and so on. The Upload module has been fully deprecated.
The Throttle module, which turned off certain site functionality in the event of a traffic spike, was deprecated due to the much better caching options that have been added to Drupal core in the last few releases. There is no contributed module to explicitly replace this feature, and it is recommended that you use Drupal’s caching settings instead.
In addition to these changes in Drupal 7, there are literally hundreds of other changes under the hood. Here are some of the big ones. Although these will not affect site builders particularly, they are good to know about nonetheless:
- New database abstraction layer
Drupal 7 includes a new, object-oriented database abstraction layer, nicknamed “Database: The Next Generation” (DBTNG). This functionality provides support for many new database types in Drupal, including SQLite, Oracle, and Microsoft SQL Server. It also provides support for advanced database features such as transactions and master/slave replication.
- Automated tests
The core Testing module provides an interface for running the more than 30,000 automated tests that ship with Drupal 7. These tests are code that checks to see that Drupal’s code is working, and cover functionality ranging from content creation and user registration to security filtering and more.
- User interface effects
Drupal 7 ships with all kinds of new user interface enhancements for developers to use in their modules. jQuery UI now ships with Drupal core, providing drag and drop, accordions, and other visual effects. Additionally, Drupal ships with a revamped AJAX framework and new JavaScript “States” system, which allows for dependent drop-downs and other eye candy.
- Improved file handling
Drupal 7’s file and image API was completely revamped in Drupal 7, and is much more robust than before. Files can now be saved to and served from external services such as content delivery networks, and other modules can react when events happen to files such as saving, deleting, and downloading.
- More granular theming
Thanks to the new Render API, themers now have much more control over placement of page elements, and now have access to perform cosmetic alterations without hassling a module developer.
The following resources provide more detailed information on the changes between Drupal 6 and Drupal 7:
The CHANGELOG.txt file in the Drupal root directory talks about high-level changes between Drupal versions.
Look at http://www.unleashedmind.com/en/blog/sun/more-than-50-drupal-modules-moved-into-drupal-7 for a list of all Drupal 6 modules that are either moved to core or deprecated by functionality in Drupal 7.
See http://drupal.org/update/modules/6/7 for a list of all developer-facing changes between Drupal 6 and Drupal 7.
See http://drupal.org/update/themes/6/7 for a list of all themer-facing changes between Drupal 6 and Drupal 7.