drupal 7

By default Search API (Drupal 7) reindexes a node when the node gets updated. But what if you want to reindex a node / an entity on demand or via some other hook i.e. outside of update cycle?

Turned out it is a quite simple exercise. You just need to execute this function call whenever you want to reindex a node / an entity:

I had a case recently, where I needed to add custom data to the node display and wanted this data to behave like a field, however the data itself didn't belong to a field. By "behaving like a field" I mean you can that field at node display settings and able to control it's visibility, label and weight by dragging and dropping that field.

So, as you may have undestood, hook_preprocess_node / node_view_alter approach alone wasn't enough.

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:

Yesterday, during a meeting with my Drupal friends, I showed them some Python magic including Fabric () and how it can be used to make your Drupal dev life easier. My friends been blown away ;) I promised to share my regular fabfile.py for a Drupal project, please see it below, just a note: this is really beginner's code and I'm not responsible for any damages or losses it can bring. Okay, here it is:

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.

Pages

Subscribe to drupal 7

You are here