If you've missed DrupalCon Prague 2013 or, maybe, you want to relive once again this great party go and see all videos from the event on this page: all DrupalCon 2013 Prague videos. Or use the playlist embed below. There you'll find 4 days, 7 hours long video material (104 videos)!

The easiest way to do this is to set up your script as a manage.py subcommand. Here's how to do that:

from django.core.management.base import NoArgsCommand, make_option
 

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.

I often get emails from beginner Drupal developers asking "Where to learn PHP for Drupal or Drupal PHP?". Actually, "Drupal PHP" is an interesting term, that in the language of beginners means "how to learn writing custom modules and do customizations and understand Drupal internals" that equals to learning and understanding Drupal API.

"Woa, what a long title", you must say. Yes it is and it deserves that for sure. But at first, please answer this question: "How many times you've been forced to work on client's server, because of the fact that there are services, that work only with remote server's localhost and can't be exposed to the outer world?". It could be a case with SOAP server or DB (in my case it was MSSQL) which accepts connections only from remote server's localhost.

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 TimOnWeb RSS