This chapter walks through the process of adding links to the contextual drop-down widgets new in Drupal 7. It also shows how using menu autoloaders can help simplify the code that you write in your page callback function since you won't have to do extra checking on the data.

As a note, if you are wondering why we started our function with an underscore (_), naming functions with an underscore in front of the name is a common convention in Drupal that sort of implies that "this function is for internal use by this module only" and shouldn't be called by itself. It's also a nice way to ensure that your internal functions are not colliding with the namespace of a hook or another module. Here's a good blog post about naming things.

This chapter goes through the process of passing a wildcard variable to a function via an argument from the URL. It creates a MENU_LOCAL_TASK tab on the node which inverts the text to display upside down. It uses a page callback function that is included within a separate file in order to save on how much memory is used.

Provides a overview presentation for how Drupal's menu system takes care of incoming requests via the index.php. Then it walks through the process of implementing a simple module that hooks into Drupal's menu system at the path of /magic. It then executes a page callback function of menu_magic_basic(), which outputs some simple markup text.

Additional resources

hook_menu() documentation

This screencast shows how you can use Rules to alter the presentation of your Drupal site, such as:

• Enabling, disabling and moving blocks around
• Setting HTML title element and also on-page titles
• Setting body classes
• Setting the active menu item (using Menu Position)

Some bigger questions about using Rules for altering presentation is also discussed:

• Using Rules for presentation altering is relatively heavy. (It consumes about 2.5 MB more PHP memory than Context, and has about the same loading times – judging from a first, rough comparison.)
• Using Rules for presentation altering gives a more complex UI than the interface use for modules made for more particular use cases.
• It is possible for modules to provide alternative user interfaces to Rules.
• Rules allows reusing actions in many different situations, between different modules.
• Rules (and Entity API) provides generalized data handling.

Additional resources

Rules guide (Drupal.org)

This screencast shows some functionality included in Rules Bonus Pack, as an example of how to make Rules integrate with other modules on your site. In particular it shows some Views and CTools/Page manager integration.

• Condition: Check the number of results from a view.
• Action: Load the sum of a Views column as a number. (Currently only D6!)
• Action: Load the first result in a view into Rules.
• Action: Clone a full node object.
• Action: Convert a number into a date
• Event: Trigger a rule when a custom page is rendered.
• Special: Allow Rules condition components to be used as CTools access plugins.

Additional resources

Rules guide (Drupal.org)

This screencast shows some more settings in the Rules Link module:

• How to use the visibility conditions in Rules Link.
• That the entity the link is attached to is always available as a parameter.
• That you can add more variables to the Rules Link by passing them in the URL – and that you need to set up the parameters settings to tell the link how to interpret the data.
• That each link is available as a field in Views.
• That you can add parameters to links displayed in Views.
• That there is a bug preventing links for non-node entities to be displayed in Views.

Additional resources

Rules guide (Drupal.org)

This screencast shows the Rules Link module, and some basics in how to use it. It covers:

• That Rules Link adds links to entities (and that you set up each link separately).
• That these links triggers rule sets.
• That the links may be displayed as links on (for example) comments and nodes.
• That Rules Link is useful when you previously used Flag, but didn't really need the 1/0 data that Flag provides (but rather just the Rules trigger effect).
• That access to each configured link can be controlled using the standard permission system.

All of this is demonstrated by adding a "block spammer" link to comments, allowing administrators to block the comment author and delete all comments written by him/her.

Additional resources

Rules guide (Drupal.org)

This screencast quickly shows the events, conditions and actions that Flag exposes to the Rules module. It covers:

• Event: Flagging and unflagging entities
• Condition: Flag is set on an entity (by a particular user)
• Condition: An entity has at least a number of flaggings
• Action: Load the list of users flagging an entity
• Action: Set or remove a flag (for a particular user)
• Action: Remove all flaggings (for a particular user) – or save a particular number of flaggings

Additional resources

• Flag project (Drupal.org)
• Rules project (Drupal.org)
• Rules guide (Drupal.org)
• Flag module documentation (Drupal.org)

If you're reading this message, you use Open Source software. The last fifteen years has seen the meteoric rise of tools like Linux, Apache, Firefox, WordPress, Drupal and more; simplyusing Open Source is old hat. When it comes to building your company's web strategy around open source tools, though, the decisions can be fuzzier. The best-known arguments for Open Source are often ideological rather than pragmatic, and fail to account for the different needs of different projects and businesses.

In this Do it with Drupal session, Jeff Eaton will explain the no-nonsense pros and cons of Open Source, covering the big wins as well as the tradeoffs and common pain points. Whether your business is testing the Open Source water, betting the farm on community-maintained software, or open-sourcing its own creations, you'll learn how to avoid common pitfalls and set yourself up for success.

This chapter describes how Drupal modules are able respond to specific events through the hook system. A couple of example hooks are implemented in order to see how this process works. This video builds on the demo module we created in the previous chapter.

Walks through some of the basics elements that are required and common for all Drupal modules. Then we create a simple demo module to see how it works.

This screencast shows “how you can use multiple-parameter Rules components in VBO and get the additional parameters as action configuration,” which translates to:

• If you have more than one parameter for a Rules component, you can still use it with VBO.
• Any additional parameters will be displayed as action configuration, meaning that the person executing the VBO gets to choose parameter value.
• Sadly, you can’t access data from the view item being actioned – you’ll have to stick with fixed input values. (If you want to use data from the processed item, you could actually do this inside the Rules component!) This is an issue being worked on.
• If you have complex parameters – such as taxonomy terms instead of just an integer – you can (mostly) use entity ID in the direct input mode.
• You can, by coding, change the form elements used for input. It is probably better to target the Rules data widget than doing a standard form_alter, but both will work.
• You could, for example, use this for changing comment settings on nodes, or adding selected tags to nodes. (Both examples shown in this screencast.) You could also use it for, say, sending customized messages or something. Or cloning existing nodes with changes specified in parameters.
• Bonus: If you add an entry to a multiple-value field in an entity, Rules won’t pick up that the entity has changed – make sure to add a “save entity” action in the rule.

Not mentioned in this screencast but still good to know:

• You can have Rules components without any parameters as well. No sweat.
• You can use Rules components without any parameters matching the View type too. In that case, you’ll have to specify all the parameters manually.
• If you have a component with several parameters matching the view type, the first one will be auto-populated by VBO – the rest you have to set manually.

Additional resources

Rules guide (Drupal.org)

This screencast shows the awesome functionality of loading entity lists into Rules with help of VBO. As an example, a rule is set up that, once a day, removes any stick front page content that is older than one week. To do similar cools stuff yourself, the following steps may be useful:

• You need a view that lists the entities you want to work on in Rules. Note that you don’t need a display of the view – and it might even be better not to have one if you don’t want the view to be displayed somewhere.
• However, you need one bulk operations field. The type of bulk operations field determines what entity type will be sent to Rules. Note that you don’t need any actions enabled for the field – it is enough that it is present.
• You need a rule that, as an action, loads entities from a VBO. (This is available under the “Views bulk operations” group.) All view displayes with at least one VBO field will be selectable.
• The action provides a list of entities, that can be used just like other lists in Rules. Combine with loops, actions and Rules Scheduler to make awesomeness happen.

Additional resources

Rules guide (Drupal.org)

This screencast shows how you can use Rules components in VBO, allowing much more complex and flexible actions than comes out of the box with VBO. The episode covers:

• How to create a simple Rules component.
• How component parameters are used by VBO – in particular that it is useful to have a single node as parameter if you want to use a component with a node view.
• Some words about what the provided variable option for Rules components means.
• An example showing how to use VBO to close (and hide) comments using VBO + Rules in combination.
• Some comments about creating more complex Rules components.

Additional resources

List operations with Views (Drupal.org)

This screencasts presents some of the settings available when configuring a bulk operations view. It covers:

• Controlling access to your VBO, and why that is important.
• Showing actions as buttons rather than a select list.
• The new cool option for selecting all items on all view result pages.
• Turning check boxes into radio buttons.
• Showing or hiding the result of the bulk operations.
• Showing action configuration on the view page.
• How to skip the confirmation page.
• How to give your actions customized labels.

Additional resources

Views Bulk Operations (VBO) guide (Drupal.org)

In this video you'll learn how to use api.drupal.org the canonical source for information about Drupal's hooks, APIs, and code documentation in order to find out information about implementing a particular hook, making use of a particular function or library of functions, and even gaining a better understanding of some of the big picture concepts behind Drupal's code and APIs.

This video walks through the handy devel module from http://drupal.org/project/devel and demonstrates the tools it provides for debugging, inspecting and analyzing the code and SQL queries happening on your site. In this video you'll also learn about some of the helper functions built into the devel module that make it simpler to inspect the large nested arrays that you'll commonly come across when writing code for Drupal.

You may not have heard of the function dsm() before now. It is a legacy function and dpm() is the newer name. The two functions are identical since dsm() is just a wrapper for dpm().
The idea is that dsm() was a poor name for the function, it's short for drupal set message, but what was later decided that drupal print (as in print_r) message was better.

The difference between those two and kpr() is that dpm() does a permissions check to make sure the current user has permission to view devel's output, and then puts the krumo'd variable dump into the message queue via drupal_set_message(). This means that dpm() will work and let you see the output even if you're redirected. Great for debugging forms. kpr() just krumo's and dumps the value right here, right now. No permission check, no regard for where the content is being spit out.

In this video Joe Shindelar provides a quick overview of the minimum set of tools you'll need in order to get started with module development. Some kind of web server to host your development site on, an editor that allows you to edit PHP files (preferably one with syntax highlighting), a MySQL client, and Drush. Learn about how these essential tools fit in the module developers tool belt and then download and install a bare bones copy of Drupal to start tinkering with.