I've had some clients not wanting the uber cool password strength checking in Drupal 6. Well, here's a very short tip how to disable this.
Just add the following in some javascript (your theme, your module, ...)
<script language="javascript">
// disabling password security check
Drupal.behaviors.password = function(context) {
return;
}
</script>
Hooray for behaviors!

This is a quick tip for people running scripts (or cron) with a lot of node_load.
If you call node_load, it does some static caching keeping the node object for the duration of the script to save some calls to the database.
<?php
function node_load($param = array(), $revision = NULL, $reset = NULL) {
static $nodes = array();
if ($reset) {
$nodes = array();
}
// loading the node...
return $node;
}
?>
If you have a lot of those node_load calls, this needs a lot of memory. Megabytes.
But node_load was built with a reset option. So if you run it with the $reset parameter set to TRUE, it will clear its static cache. And your code is no memory hog anymore.
Drupal has it's own system to handle "Page not found" errors. It uses a simple function, called drupal_not_found to set the correct headers, etc. That function calls theme_page to do its rendering.
The catch here is that it calls theme_page with the $show_blocks argument set to FALSE. This means blocks in the left and right columns won't be shown here.
// To conserve CPU and bandwidth, omit the blocks.
print theme('page', $return, FALSE);
In some cases, you might not want this behavior. You might have your navigation in one of these sidebars and you want to give your visitors some way out of this page. The navigation might get the person back on track.
How can we fix this? Very simple. Put the following code in your page preprocessing function.
function phptemplate_preprocess_page(&$variables) {
// show all regions if page not found
$page_not_found = strpos(drupal_get_headers(), 'HTTP/1.1 404 Not Found') !== FALSE;
if (!$variables['show_blocks'] && $page_not_found) {
global $theme;
// Populate all block regions.
$regions = system_region_list($theme);
// Load all region content assigned via blocks.
foreach (array_keys($regions) as $region) {
// Prevent left and right regions from rendering blocks when 'show_blocks' == FALSE.
if ($region == 'left' || $region == 'right') {
$blocks = theme('blocks', $region);
}
// Assign region to a region variable.
isset($variables[$region]) ? $variables[$region] .= $blocks : $variables[$region] = $blocks;
}
}
}
This will only render the left and right blocks, the other ones are already rendered by Drupal core.
This is a follow up of an earlier post. You should read this one to understand this one fully: Improve Drupal's performance by not executing block logic on page templates with no regions.
As I told there in the final paragraph, it was possible to generalize this technique to work on multiple templates with a different combination of blocks. This is a general solution to solve this.
As you know, you can have multiple page templates in PHPTemplate by settings $vars['template_file'] in theme_page. We add this variable in _phptemplate_variables for the 'page' hook.
function _phptemplate_variables($hook, $vars) {
if ($hook == 'page') {
$vars['template_file'] = phptemplate_get_template();
return $vars;
}
return array();
}
Note that we moved the logic for deciding which page template we use in a seperate function, which implementation is here. This is the only function you need to adjust to your context. The other code you can just copy-paste and reuse in your own templates.
function phptemplate_get_template() {
static $active_template;
if(isset($active_template)) {
return $active_template;
}
if(drupal_is_front_page()) {
$active_template = 'page-left';
} else {
$active_template = 'page';
}
return $active_template;
}
We also define a mapping to specify what regions are used on what templates.
function phptemplate_get_template_regions($region) {
$map = array(
'page' => array('content', 'left', 'right'),
'page-left' => array('content', 'left'),
);
return $map[$region];
}
As told in the previous article, the core logic of the block was executed on demand of the block_list function. This function was called from the theme_blocks function.
We don't want to run the block_list function on regions that don't appear in our page template, so we put a wrapper function around the core function.
function phptemplate_block_list($region) {
if(!in_array($region, phptemplate_get_template_regions(phptemplate_get_template()))) {
return array();
}
return block_list($region);
}
And now we override theme_blocks to call this function:
function phptemplate_blocks($region) {
$output = '';
if ($list = phptemplate_block_list($region)) {
foreach ($list as $key => $block) {
// $key == <i>module</i>_<i>delta</i>
$output .= theme('block', $block);
}
}
// Add any content assigned to this region through drupal_set_content() calls.
$output .= drupal_get_content($region);
return $output;
}
And we're done!
To apply this to your own themes, just copy all these functions and change my implementation of phptemplate_get_template and phptemplate_get_template_regions to your situation. If you already have your own _phptemplate_variables, add my logic to yours.
Quick note to people who have page caching on on their site:
If you move your site to a new url, don't forget to flush your cache_page table after moving the site since Drupal uses the full url (including the domain name etc.) as the cache key.