I needed to do some custom validation of fields on a form. So, I decided to use #element_validate. One of the fields I was validating appeared a bit strange to me, though. When I displayed its $form_state['values']['field_face_palm'] information I saw that it looked like:

$field_face_palm['und'] = 'you_knucklehead'

instead of like:

$field_face_palm['und'][0]['value'] = 'you_knucklehead'

I was having trouble getting a feature to enable correctly. It wasn't creating all the fields for the content type it defined. It built some of the fields but not others. I was pretty certain that it was working fine on other sites. But, I couldn't imagine what was different about the environment in which I was having trouble. I finally found the culprit when I took a closer look at my directory structure.

I was writing custom forms that needed a validate handler and a submit handler. So, I followed the standard approach of

  function my_module_menu(){
    $items = array();
    $items['my/module/custom-form'] = array(
      'title' => 'I am a doofus',
      'page callback' => 'drupal_get_form',
      'page arguments' => array('my_module_custom_form'),
      'access callback' => TRUE,
      'type' => MENU_CALLBACK,
    );
    return $items;
  }

Note: My access callback is just to simplify this example.

What's that feature: the #attributes key.

Perhaps you have written your own javascript code to determine that an empty textfield does not have focus, and in such a situation place some placeholder text in the field. If you are using the FAPI there is an easier way. You can do this:

What's that File (layout)?

There are many different ways to figure out what information the node table contains.

1. You could use dsm($node); in an appropriate place in your code, assuming you have the Devel module installed.
2. You could also use a poor man's version of dsm, a la drupal_set_message('<pre>' . print_r($node, 1) . '</pre>');.

What's that Feature?

When your code executes a variable_get what actually happens is that Drupal inspects the $conf global array variable to see if it contains an index with the variable name. It does NOT actually query the variable table.

I was writing an extremely simple custom module (for a D6 site) to make use of hook_block. Every time I enabled the module the blocks no longer displayed on the pages. Since it had been a long time since I had done any work in D6, I figured there must be something I was overlooking in how I wrote the function. If I disabled the module (or even just commented out the hook_block) function then the blocks reappeared. So, I spent a fair amount of time looking over how I had written the hook. But, I couldn't see anything wrong with it.

I am running a Drupal 7 site on AWS with an EC2 micro instance and RDS on Ubuntu 12.04. When I navigated to the URL patterns for Pathauto admin/config/search/path/patterns I was getting a nasty white screen with an error along the lines of PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away. As it turns out, this is not the fault of Pathauto. The solution to this problem was to increase the max_allowed_packet value in the mysql server configuration.

From the Rules project page:

The rules module allows site administrators to define conditionally executed actions based on occurring events (known as reactive or ECA rules). It's a replacement with more features for the trigger module in core[.]

Okay, so you are ready to start customizing your Drupal installation. Before you get started, there are some things you should know and follow.

• Drupal provides a directory structure that is designed to be used in a certain way. Notice the subdirectories below your Drupal root:
  • includes
  • misc
  • modules
  • profiles
  • scripts
  • sites
  • themes