Hệ thống Drupal 7 phức tạp hơn Drupal 6

Every major release has introduced significant changes to the core API. There's no backwards compatibility between major Drupal releases; you can't run Drupal 7 modules on a Drupal 6 site, for example. In fact, if you tried you'd likely end up with the white screen of death. This willingness to let go of past thinking and old code has allowed Drupal to be as awesome as it is today.

For theming, fortunately, the changes have usually been rather incremental — a short checklist of minor changes to themes to get them working in the newer Drupal. And none was as radical or challenging as the change from Drupal 4.5's xtemplate theming engine to the phpTemplate engine that emerged around Drupal 4.6 and became part of Drupal 4.7's core. That "upgrade" actually required total reimplementation. You simply could not just tweak an xtemplate-powered theme into a phpTemplate-powered theme. Thankfully, since then it's been a much easier road for theme upgrades.

That is, until now.

Many Drupal themers will be daunted by the changes in Drupal 7. But we're excited about the new power.

50 (or so) drops make for an ocean of changes

Drupal 7 represents just about as big of a theme refactoring as possible, without replacing the core phpTemplate theming engine. I won't say this upgrade is harder than the xtemplate-phpTemplate migration. No, we're still working with the same basic concepts, same general approach — in theory, anyway. But the changes are still enough that anyone looking at doing a theme upgrade from Drupal 6 to Drupal 7 might seriously consider simply rebuilding it from the bottom up, rather than trying to apply this change here, that change there … for 50-something changes.

At my Drupal theming presentation at DrupalCon San Francisco, I touched upon some of the big things that D7 theming is introducing. There's video on the DCSF site. Here are my slides:

But a more detailed rundown of the changes are (mostly) detailed at drupal.org/update/theme/6/7.

There are 49 changes documented so far, as I write this (with Drupal 7 still in alpha), and a few others to boot. In fact, some changes are not documented there yet — or are actually incorrect. (See bottom of this post for links to issues where I and others are working to correct some of these.)

So without trying to be comprehensive, here is an introduction to some of the Drupal 7 theming changes that will make Drupal theming even more powerful:

html.tpl.php

As I write this, nothing about html.tpl.phpis documented in "Convert 6.x themes to 7.x" in the Drupal.org handbooks (and this is something I'm working to change). html.tpl.php is now the new page wrapper for your theme. Here you have the DOCTYPE declaration, the info, and page closer.

modules/system/html.tpl.php contents

Here's a marked-up image of what you find in html.tpl.php:

The html.tpl.php template in Drupal 7 takes over the webpage container duties previously managed by page.tpl.php in Drupal 6. In Drupal 7, the latter template contains pretty much all of what you see on the screen; the , and tags, as well the DOCTYPE declaration, are all moved to the html.tpl.php file. The page.tpl.php template is actually called from within the html template. Note: You can always find the base templates Drupal is sending your way by finding the *.tpl.php files within Drupal core's modules' folders, and in most of the contributed modules.

As you can see, this template has taken up the markup and renderings for pretty much all of the meta wrapping around the actual page that gets displayed, including new items $page_topand $page_bottom. page.tpl.php gets called this way:

This template is pretty straightforward, and something most themers won't even have to deal with. But if you forget this template, you're going to run into some problems. So remember to include it. But if you include it for the purposes of override, be careful or you could run into problems. [Thanks to Pasqualle's comment for correcting me on this!]

More: api.drupal.org documentation on html.tpl.php and an issue for documenting html.tpl.php implementation and changes.

region.tpl.php

Regions templates contain the content area, sidebars, footer, etc. By default, they follow Drupal core's region.tpl.php template.

Yes, regions now have templates. The active code Drupal 7 core provides for region.tpl.php is this:

As usual, you declare your regions in the theme's .info file. If you don't declare regions, you will get these by default:

• header
• help (yes, help is now a region of its own)
• highlight (this replaces $mission)
• content (which is required in all themes)
• sidebar_first (whose naming reflects a generally more semantic approach to Drupal theming)
• sidebar_second
• footer

The various regions are called out and rendered by code in the page template, page.tpl.php, by using a syntax identifying the region as a variable, e.g.:

Of course, to conditionally print the region only if it has stuff to display, it might look something like this:

More: api.drupal.org documentation on region.tpl.php.

Hidden regions

This is a neat little one. It's a way to define regions that are available for modules but are not available in the blocks administration area. Why would you want to do that? The Drupal.org Handbook's theme update page explains a use case:

The page_top and page_bottom regions are hidden, which means they will not show up on the blocks administration interface. When doing site-specific themes, it might also be useful to add more hidden regions (to provide ways for modules to add output to more places in the theme without defining blocks showing up on the blocks interface), you can do that via the regions_hidden[] .info file array which is new to Drupal 7:

theme .info file extract:
regions[content] = Content
regions[help] = Help
regions[page_top] = Page top
regions[page_bottom] = Page bottom
regions[indicators] = Indicators
regions_hidden[] = indicators

In this above example, the region named "indicators" is additionally defined as a hidden region.

Two ways of hiding elements with CSS

Speaking of hiding things, there are now two standard ways to hide content using CSS:

1. .element-hidden— to hide an element from all users. ("An example would be a collapsible fieldset that will be expanded with a click from a user. The effect of this class can be toggled with the jQuery show() and hide() functions" — handbook.)
2. .element-invisible— to hide an element visually, but keep it available for screen-readers. ("This class should be used for information required for screen-reader users to understand and use the site where visual display is undesirable.... This class must not be used for focusable elements (such as links and form elements) as this causes issues for keyboard only or voice recognition users" — Ibid.)

It's extremely handy to have these predefined, especially as browser-viewed design patterns get increasingly complex and specific to particular use cases. All themers have to recognize that they are implementing an application interface, not a "web page" as conceived by many since the advent of Netscape in 1994.

All titles in templates get prefix and suffix

Thusly:

Why?

One reason is to generate contextual links — such as a handy block edit link right there where the block is displayed, visible to and accessible by users with appropriate permissions.

Granular display of $contentinfo in node.tpl.php

Now this part is really cool. It no longer requires preprocess to break apart node $contentoutput. Of course, you could print each field on its own, but what a pain in the ass!

But in Drupal 7, you now have two new functions for printing out content in a node or user profile:

• render()
• hide()

Let's look at an example taken from node.tpl.php:

// Then we print the links and comments separately

.

What this means is that you can pull components or fields out of your template's big $contentblob and display them in a more controlled way — e.g., to split them out of the "content" div, as illustrated above.

Fields are in core

With fields now in core, if you weren't CCK-prolific, you have more theme components to account for by default.

This isn't so much a theming-specific thing, but it's really cool! The field.tpl.php template is pretty straightforward:

In there, like in Drupal 6's filefield module template, it's pretty clear where the