Let’s say you have to make a multilanguage Drupal website… Besides English it also has to be available in Chinese and Japanese. Drupal makes it really easy for you to set up the basics. Using the Locale and I18n module, most of your site can be translated with a few clicks of your mighty mouse.

The problems come when you are trying to use pathauto in combination with placing the node title ([title-raw]) as path. You will be ending up with Chinese and Japanese characters in your URL. Most modern browsers do support this, but it’s still not a pretty sight and who knows what software/OS does not support it yet.

A solution might be typing Pinyin (for the Chinese version) in your paths… But this can be a long and tedious job (not to mention how many times your client will screw up or forget!).

Pathauto offers a relatively easy solution for our problem. We can “force” Drupal to use the original node paths for the translations too. This will not cause any conflicts as all translations are prepended with their ISO code. Just add the following code to one of your custom modules!

/**
 * Because we want to use our original paths, prepended with the language identifier
 * We are going to assume the default language is english!
 *
 * @param $alias
 * @param $context
 */
function mymodule_pathauto_alias_alter(&$alias,$context) {

	if($context['module'] == 'node' && $context['language'] != 'en') {

		$node = node_load($context['entity_id']);
		if($node->tnid > 0 && $tnode = node_load($node->tnid)) {
			$alias = $tnode->path;
		}

	}

}

Drupal is an awesome product, we all know that. But we also know that not everything works as we expect it and that any software might have it’s quirks. Here at Drupal Hacker, I try to smooth out these problems by providing patches to unmaintained modules or to ignored bugs. Last… don’t take all the sarcasm too seriously!

http://www.drupal-hacker.com

Tip #1 Caching expansion

There are several good caching modules out there. Some are unstable or neglected by the Drupal community, others are just not worth the hassle installing. Personally I prefer using Advanced Cache module. The advanced caching module is mostly a set of patches and a supporting module to bring caching to Drupal core in places where it is needed yet currently unavailable. These include caching nodes, comments, taxonomy (terms, trees, vocabularies and terms-per-node), path aliases, and search results.

This module will give you your first performance boost, even if you’re using standard Drupal cache to support it. There are also two (minor?) downsides when using this module. First one being that you have to hack Drupal core and second one is that it hasn’t received a lot of feedback for Drupal 6.

Also download the patches I have contributed to ensure *everything* is being cached correctly and that the patches work on the latest Drupal release.

• http://drupal.org/project/advcache
• http://drupal.org/files/issues/node_102.patch patch #1
• http://drupal.org/files/issues/taxonomy_56.patch patch #2
• Patches for advanced cache – topic

Tip #2 Memcache

Memcache is probably the easiest performance improvement you can get. No patching required, you just need to set up a memcached daemon and you’ll be on your way.

You will want to split your caches up into several bins. This will reduce the impact of a cache rebuild on your server. You can find all the information on how to set up and install this module on it’s project page.

• http://drupal.org/project/memcache
• Download memcache on nix/windows

Tip #3 Proxy caching

Using a proxy to cache your static files is a good idea. And caching dynamic pages too is an even better idea! But… aiii… again, this involves hacking Drupal core.
You can choose between varnish, squid or apache’s mod_cache. They all work the same and none of them has proven me to be a “better option”.

Tip #4 Alternative search solution

The Drupal search will cause a very nasty load on your database server if you get a few requests at the same time. But don’t panick, there are several options available to lighten the load.

Currently, apache SOLR is considered the Drupal way to go if you’re looking into an alternative search solution. Admitted, this module does get more support and has more options than any other. On the other hand, it will put strain on your web an database server while doing indexing & re-indexing. The maintainers of the Apache SOLR module are looking into ways to improve this.

Anyway, untill they have fixed the module, I’d suggest using the Sphinxsearch module. It has fewer options, but Sphinx is able to index your website without using the Drupal API or PHP.

• http://drupal.org/project/sphinx
• Sphinx search

Tip #5 Minimize the use of the views module

The views module must be one of the greatest things since sliced bread. It allows you to easily set up new aggregations of nodes, users, …
Too bad we can’t say the same about it’s performance. When you use this module, you have to know that you’re on thin ice. A wrong decision in your admin cp can easily cause a slow query to be generated and that’ll affect your whole site.
My advice here is to hard code as many views as possible. It’ll take a bit longer, but it’ll save you pain in the long run.

The problem here lies in the views module. This module makes a call to the t() function which calls a theme function which eventually has to call init_theme() to check which template it should use. Once the init_theme() funcion has been called, the global variable $theme will be set and any other calls to init_theme() will be . Being called so early in time, the init_theme() function has no idea it still has to switch to a custom theme defined by the blocks module.

The fix involves killing a kitten… also know as hacking drupal core. Fire up your favorite editor, open up includes/theme.inc.php and find the following lines of code.

function init_theme() {
  global $theme, $user, $custom_theme, $theme_engine, $theme_key;

  // If $theme is already set, assume the others are set, too, and do nothing
  if (isset($theme)) {
    return;
  }

and replace it with

function init_theme() {
  global $theme, $user, $custom_theme, $theme_engine, $theme_key;

  // If $theme is already set, assume the others are set, too, and do nothing
  // patchy patchy!
  if (isset($theme)) {
  	if(isset($custom_theme)) {
  		if($theme == $custom_theme) {
  			return;
  		}
  	} else {
    	return;
  	}
  }