Drupal 6: Deploying a site with language translation hostnames and resolving hard coded hostname database records
Sometimes there’s no escaping hard coded hostnames being stored in your Drupal database. If you have ever setup language translations (i18n) in production, and then deployed the site to a development environment (with a different hostname), you’ll know exactly what I am talking about. The first thing you’ll notice in your dev site is that all your urls are linking back to the production site, and you may even have a hard time logging in.
If you query the languages table, you’ll see the following:
At first I thought it would make sense to write a module or a hook_update_n() function to resolve this problem when deploying to another environment, but this method seemed rather clunky, repeatedly running the same revision of a module’s update script. In the end, I decided to simply write a PHP script to run via Drush. The following code fetches your default language and all records in the language table, loops through them, and updates the hostname records to match your new hostname:
I dropped this script (named: fix_env.php) in the root of my Drupal site, and then executed it via Drush using the following shell command:
The “–uri” flag allows you to specific a hostname for multi-site environments, and the “scr” flag allows you to specify a php script to execute.
NOTE: I’m in the habit of never using sites/ericlondon.com, because it’s a real PITA if you ever try to move your site into a multi-site configuration ^_^
After running the script via Drush, my hostname database records have been corrected to match my development environment: