drupal 7

I'm a big fan of fighting with Drupal's inefficiencies and bottlenecks. Most of these come from contrib modules. Everytime we install a contrib module we should be ready for surprises which come on board with the module.

Drupal Views offers us a cool feature: ajaxified pagers. When you click on a pager, it changes the page without reloading the main page itself and then scrolls to the top of the view. It works great, but sometimes you may encounter a problem: if you have a fixed header on your page (the one that stays on top when you scroll the page) it will overlap with the top of your view container thus scroll to top won't work preciselly correct and the header will cover the top part of your view.

If you have a fieldgroup in a node, you may want to hide it on some conditions. Here's how to do that programmatically.

At first, we need to preprocess our node like this:

There are situations, when you or other modules alter username via hook_username_alter() and this can change username dramatically: for example, you can alter username into a combination of First and Last Name, etc.

There are loads of modules that can do this for you, but why to install one more module if you can do this with one string of code? The best thing is that approach below does a redirection even if you login from user login block.


Just put the following code into your custom module:

/**
 * Implements hook_user_login().
 */
function module_name_user_login(&$edit, $account) {
  // Don't redirect on password reset.
  $current_menu_item = menu_get_item();
  if ($current_menu_item['path'] == 'user/reset/%/%/%') {
    return;
  }
  // Redirect user to profile page after the login.
  $_GET['destination'] = 'user';
}

You can find this snippet at dropbucket.org here: http://dropbucket.org/node/746
UPDATE 03/08/2013: Added several lines to prevent redirection during password reset.

While working with Migrate and Migrate 2.6 beta 1 I stumbled upon several undocumented "surprises" which are hopefully going to be documented, but so far, you can spend lots of time trying to figure out what may be wrong. Here's roundup of my findings:

1. There is one correct way of registering migrations and handlers

You should do this in hook_migrate_info(), your register code may look like this:

When you import data with Migrate (http://drupal.org/project/migrate) it is nice to have ability to update already imported data if source has changed. To track updated data Migrate uses highwater marks (more on this: http://drupal.org/node/1223936). Highwater mark is a column of a source data which has timestamp of the last data change. However, the problem with highwater mark is that you don't always have such "time tracking" enabled on source's page.

Hi everyone, hope some of you had/having a great time at DrupalCon Portland. Since I could go I decided to do something useful and apply to Dropbucket Drupal Snippets Repository some new ideas I had in my mind. Long story short, last night I rolled out an update which brought the follwing:

"How to find form id in Drupal" is one of the most popular questions, especially for the beginners.

More experienced developers know that to find form id you need to either look into the DOM source code or to create your own hook_form_alter() function like this:

function YOUR_MODULE_NAME_form_alter(&$form, &$form_state, $form_id) {
  dpm($form_id);
}

This post is a quick addition to my previous tutorial: Loading Only One Field From An Entity or Node in Drupal 7. The tricky part there was what to do with node's field data and how to properly display it? Well there are lots of approaches there, but I see three which are of “Drupal Way” kind:

Pages

Subscribe to drupal 7

You are here