Catálogo de publicaciones - libros

I n this chapter, we’ll give you an overview of Drupal. Details on how each part of the system works will be provided in later chapters. Here, we’ll cover the technology stack that Drupal runs on, the layout of the files that make up Drupal, and the various conceptual terms that Drupal uses, such as nodes, hooks, blocks, and themes.

I n many open source applications, you can customize the application by modifying the source code. While this is one method for getting the behavior you desire, it is generally frowned upon and considered a last resort in the Drupal community. Customizing code means that with each update of Drupal, you must perform more work—you must test to see that your customization still works as expected. Instead, Drupal is designed from the ground up to be modular and extensible.

W hen you write a module, you often want to let the web site administrator change a module’s behavior by choosing different module settings. This chapter details how to make a module appear on Drupal’s administration page, present a settings form to the user, and store module-specific settings.

D rupal’s menu system is one of those dark places where few have the courage to tread. Put on your armor—we’re going in!

D rupal depends on a database to function correctly. Inside Drupal, a lightweight database abstraction layer exists between your code and the database. In this chapter, you’ll learn about how the database abstraction layer works, how to use it, and even how to write your own driver. You’ll see how queries can be automatically modified by modules to restrict the scope of these queries. Then you’ll look at how to connect to additional databases (such as a legacy database). Finally, you’ll examine how to create, populate, and even delete tables when a module is installed, updated, or disabled, respectively.

U sers are the reason for using Drupal. Drupal can help users create, collaborate, communicate, and form an online community. In this chapter, we look behind the scenes and see how users are authenticated, logged in, and represented internally. We start with an examination of what the $user object is and how it’s constructed. Then we walk through the process of user registration, user login, and user authentication. We finish by examining how Drupal ties in with existing authentication systems such as Lightweight Directory Access Protocol (LDAP) and Pubcookie.

I n this chapter we introduce nodes and node types. We’ll show you how to create a node type in two different ways. We’ll first show you the programmatic solution by writing a module that uses Drupal hooks. This approach allows for a greater degree of control and flexibility when defining what the node can and can’t do. Then we’ll show you how to build a node type from within the Drupal administrative interface and briefly discuss the Content Construction Kit (CCK), which is slowly making its way into the Drupal core distribution. Finally, we’ll investigate Drupal’s node access control mechanism.

C hanging the HTML or other markup that Drupal produces requires esoteric knowledge of the layers that make up the theme system. The theme system is an elegant architecture that’ll keep you from hacking core code, but it does have a learning curve, especially when you’re trying to make your Drupal site look different from other Drupal sites. We’ll teach you how the theme system works and reveal some of the best practices hiding within the Drupal core. Here’s the first one: you don’t need to (nor should you) edit the HTML within module files to change the look and feel of your site. By doing that, you’ve just created your own proprietary content management system, and have thus lost one the biggest advantages of using a communitysupported open source software system to begin with. Override, don’t change!

B locks are snippets of text or functionality that usually live outside the main content area of a web site, such as in the left or right sidebars, in the header, in the footer, and so on. If you’ve ever logged in to a Drupal site or navigated to a Drupal administrative interface, then you’ve used a block. Block permissions and placement are controlled within the administrative interface, simplifying the workload of developers when creating blocks. The block configuration page is located at Administer ➤ Site building ➤ Blocks (http://example.com/?q=admin/build/block).

D rupal 4.7 and later feature an application programming interface (API) for generating, validating, and processing HTML forms. The form API abstracts forms into a nested array of properties and values. The array is then rendered by the form-rendering engine at the appropriate time while a page is being generated. There are several implications of this approach: • Rather than output HTML, we create an array and let the engine generate the HTML. • Since we are dealing with a representation of the form as structured data, we can add, delete, reorder, and change forms. This is especially handy when you want to modify a form created by a different module in a clean and unobtrusive way. • Any form element can be mapped to any theme function. • Additional form validation or processing can be added to any form. • Operations with forms are protected against form injection attacks, where a user modifies a form and then tries to submit it. • The learning curve for using forms is a little steeper!