Select language

Finally, Drupal delivers the content:

■ Q: Which page? A: Serve up the page.

This is the sweet spot, the place where most (but not all) of the hook magic happens.

Hooks are little blocks of functionality, called functions, that contain PHP code.

These blocks of code run when they are called upon. During the bootstrapping process, especially when the final “which page?” question is asked, hooks are called. Whenever an event happens in Drupal, like deleting a page, hooks are called. Inside those hooks, there is code that alters functionality, and it runs as soon as the hook is called. Almost anything you want Drupal to do has a hook doing it.

Drupal relies on naming conventions to call hooks when the time is right for them to run. While building the menu, Drupal looks for hooks with “_menu” in the name. When a page is deleted, hooks FEATURE Drupal Is a Framework

WWW.LINUXJOURNAL.COM / SPECIAL DRUPAL ISSUE / 29

with the name “_delete” are called.

Drupal modules override existing hooks or add new ones. For example, if I want to change the way a form is displayed, I put the code for that change inside a function called mymodulename_form_alter.

When the form’s page is built, Drupal will look for any “_form_alter” function to see if there is more to do. I also can create new hooks in custom code that can be called by other hooks, mymodulename_myhook.

Hooks don’t just govern behavior. The theme, which is the collection of files specifically dictating the site’s look and feel, also includes hooks. The front end of a Drupal site (the presentation rather than the behavior) is not simply painted on; it relies on hooks as well, all being called when Drupal delivers a page.

Remember our three original questions:

how long will this take, how much will that cost, and can my site do [insert cool new thing]? The answers, and

whether something is easy (quick, cheap and already possible) or hard (time

consuming, expensive and innovative), depend on hooks. “I would like my site to do X. Is that easy or hard?” The scale from easy to hard looks like this:

■ Drupal already does what you want it to do because the necessary hooks, with the necessary code, run by default.

■ Drupal provides an administrative interface for you to turn it on or change it.

■ A module or theme already has been written, calling or adding the hooks (with the necessary code inside them) that you need.

■ Custom code must be written (using or creating hooks and adding code to them). The time and effort required here varies widely, from three quickly written lines of code to months of programming, creating multiple contributable modules.

■ Custom database tables must be created. At this level of complexity, the code still will rely on hooks but begins to run outside of what Drupal does natively; therefore, it is (sometimes) more complex than adding code alone.

■ Necessary data comes from other Web sites, or your site’s new feature requires communicating with other sites (for example, credit-card

processing). The time and effort to do this also varies widely and can be as easy as adding a module (that already handles this communicating) or as hard as writing a separate application that runs when the appropriate

LJDrupalSupplement.indd 29 9/15/12 9:58 AM

hook is called. What your site will do with the data and the load it puts on the system greatly influences the complexity as well.

■ Your tasks can’t run on page load, a special process has to be written to accomplish them. Sometimes, this is a quick addition (a simple cron job using hook_cron), and sometimes this is complicated. Often, this approach is used when data processing would slow page load down (or take down the site), so it is handled out of sync and saved (cached), serving the cached version when the page loads and the question is asked.

Does Drupal already include the necessary hooks running the necessary code and does it provide an admin interface to set up what you want to accomplish? Easy! Do you need to get mega-amounts of data from elsewhere, process and save it out of sync with page load, and create new database tables that interact with existing data? Hard!

Drupal core and many contributed modules are primarily designed to manage content, to power a CMS—

which is why it is right to say, from one point of view, that Drupal is a CMS. Out of the box, users can create any content type imaginable—book reviews, recipes, scholarly paper submissions, press

releases, blog posts and so on. An admin interface in Drupal 7 makes creating nodes (the foundational content type with a title and body) and adding fields of related data to them, like the author and publisher in a book review, a code-free task. Creating book reviews that include a cover image, author, publisher, publication date and a link to Powell’s City of Books is quick. Adding a five-star rating to each review involves adding one contributed module and turning it on.

How hard it is to make the review look like the design depends on how much the design varies from the way Drupal presents the content to the page.

If the author, publisher and so on will be displayed in the order it was created administratively and styled according to the site’s general style guide, creating the look and feel involves adding some CSS to the theme’s CSS file(s). Easy! But if the page will distribute the fields in a unique order or include custom behavior (like also displaying other books the user has rated), custom work needs to be done. Hooks in the modules and in the theme enable this work to happen, allowing the page load process to be interrupted and edited.

Ironically, the fact that Drupal enables the creation of a book review content type is also what makes it a framework.

In the words of Larry Garfield, Drupal core contributor and member of the FEATURE Drupal Is a Framework

WWW.LINUXJOURNAL.COM / SPECIAL DRUPAL ISSUE / 31

Drupal Association Advisory Board:

What Drupal is today is a tool for building a content management system for a variety of different needs. That’s an important distinction for someone

looking to build a Drupal site to understand. Drupal is not a CMS. It is the framework with which you build your own CMS, to your specifications, to suit your needs. It is a Content Management Framework.

Diving into the syntax of hooks does require programming knowledge and is, in my experience, where the discussion between developers and product owners should end. My developer cohorts

and I discuss the technical aspects of implementing hooks: which to use, where to put them, when to call them, how to simplify the code they run, performance issues and caching plans, the decision to use contributed code or write my own. Once the decision to, for example, pull in feeds and display them is made, the “how” discussions begin.

(Node.js anyone?) Communicating the issues that arise as the “how” is being

implemented and making collaborative decisions with site owners is the fine art of managing development, the place where the conversations begin again.

This process is made easier, every time, when everyone involved understands how Drupal works (framework!) and trusts the easy/hard assessments made by the development team.

Hooks create, define and override the Drupal tools used to build information architecture—associating content with other content and creating navigable structure. Nobody wants a Web site to

spit out all of the content in one big blob.

The primary tools to build information architecture are content types, menus, blocks, taxonomies and views.

■ Nodes, content types and fields give structure to the content. Fields (like author or publisher) make for easy content creation and visual continuity for the user.

■ Menus enable navigation by creating a structure of associations. Menus create a content geography and reveal the paths for exploring it without getting lost.

Nobody wants a Web site to spit out all