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.
dsm($node); in an appropriate place in your code, assuming you have the Devel module installed.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.