Tag Archives: Drupal

Installing Drupal on Windows Server 2003 – Relevant Links

Recently I have needed to setup a Windows 2003 IIS server to run Drupal, the catch though is that it already runs an ASP.NET website and does not have MySQL, PHP, or even FastCGI installed. So, it must not affect the existing website at all. Working on a development server, I’ve been trying to get this to behave correctly. It is out of my area of expertise, so I’ve been doing a lot of reading up on it. The links I’ve used are mostly all below, mainly for my future reference and for anyone else that may need to do the same:

The easiest way to set Drupal up on Windows should be with Microsoft’s installer. It uses their WebMatrix with the Web Platform Installer and looks like it should automate the process and configure everything that needs to be configured. The problem with it though is that it uses IIS Express, which can’t run alongside IIS, and the installer cannot run with IIS, which means I can’t use it for this situation.

So far, I’ve tried the IIS Aid PHP installer, which seems to work for the most part, however, I’m having FastCGI errors left right and centre with it crashing constantly. Unfortunately the IIS Aid installer doesn’t seem to work when using ISAPI instead of FastCGI, so I’m not up to installing and configuring PHP manually using FastCGI, and if it’s still unstable, ISAPI.

Another option is to look at running Apache on a different port to IIS, but I would rather not go down this route if I can avoid it.

It’s a real pain. If you have any experience with this, tips or advice would be appreciated!

Finding The Path To Your Drupal Theme

Ever needed to reference a file in your Drupal theme? For example, an image from your page.tpl.php file, or a JavaScript file?

You can hard code the path, which might be something like:


Or, with a little bit of PHP, you can use Drupal’s built in path_to_theme() function. This function will print out the path to your Drupal theme from the root directory.

So, in your theme you might have this image, but instead of writing:

<img src=”/sites/all/themes/mytheme/images/myimage.jpg” alt=”My Awesome Image” />

You could write:

<img src=”/<?php print path_to_theme(); ?>/images/myimage.jpg” alt=”My Awesome Image” />

At first glance it is slightly longer and might seem like more effort to do. Think of it a bit differently though. What if you want to rename your theme, or use your theme on a different domain name? You will need to change the hardcoded path. By using Drupal’s path_to_theme() function, it will dynamically figure out the path to your theme directory for you.

We can then take this a bit further with Drupal’s base_path() function. This particular function returns the path to the base Drupal installation. If you have it installed in the root directory of your hosting account, then this will simply be a /.

The real benefit of this is if your Drupal installation is in a different directory. For example, /drupal. If this is the case, then your hard coded path would be /drupal/sites/all/themes/mytheme/images/myimage.jpg the path_to_theme() function will still only return /sites/all/themes/mytheme though, and the browser will not be able to find your image. The reason for this is that it only determines the path from the base installation directory of Drupal. So, to make sure your theme is truly dynamic and capable of dealing with this, you would use something like this:

<img src=”<?php print base_path() . path_to_theme(); ?>/images/myimage.jpg” alt=”My Awesome Image” />

Now if you have Drupal installed in a sub-directory called Drupal, this would actually return the full path we need: /drupal/sites/all/themes/mytheme

One thing to remember if you use this is that the path_to_theme() function doesn’t put in a trailing / or start off with a / so you will need to put these in before adding in the rest of your files location. Comparatively though, base_path() does add a / both before and after the path. So if you use it, you will not need to prefix it with a /.

This works in Drupal 5 and 6, and I believe is going to continue to function the same way in Drupal 7, so your themes will be all set to work on any server without needing to adjust the file paths. Give it a try!

You can also have a look at these functions in the Drupal API documentation:

Applying Patches to Drupal or Modules on Mac OS X

I’ve had to run a number of patches to Drupal modules before, and I’ve always done them on my Windows machine simply because that is what has the most instructions available to do so. At the moment though I am away on holidays and only have my Macbook Pro, so when I needed to run a patch I debated going to the effort of doing it through a Windows virtual machine that isn’t set up for it, or set up Eclipse and run it through their software. After much debating, I decided to look up the instructions again and see if there was a recommendation. While I was hunting around, I noticed two very, very useful things:

  1. Apple’s Xcode suite allows you to run Drupal patches.
  2. You can patch files using the OS X terminal without any need to install special software such as what I needed to do to run patches through the Windows Command Prompt. You don’t even need to have Xcode installed!

I already have Apple Xcode, as does every Mac user (if they choose to install it from their OS X disc), so that seemed like it would potentially be the easiest option, then I saw the instructions to patch a Drupal module using the OS X Terminal. It is so easy I can’t believe I didn’t start patching on my Mac sooner!

The process to patch a Drupal module on Mac

  1. Place both the original module file and the patch in the same folder.
  2. Make sure that they have the same name, with different extensions, so you would need my_module.patch and my_module.module.
  3. Open up the Terminal application. Either search for Terminal in Spotlight, or go to Applications > Utilities > Terminal.
  4. Navigate to the folder containing your files using the Terminal cd command. By default Terminal will start in your user directory, so if your files are in a folder called patch/my_module inside your user directory, you would type: cd patch/my_module. A little trick here to save yourself some trouble is just type cd and then drag the folder into the Terminal window. OS X will auto-fill the folder path for you.
  5. Run the patch using the patch command: patch < my_module.patch

That’s it! Simple as that.

If you would like to take a back up of the original patch file, type: patch -b < my_module.patch and a backup file will be created for you entitled my_module.module.orig

If you are patching Drupal core, the process is slightly different, you need to use the -p0 attribute to stop patch from asking you what file to patch, so you would do this as: patch -p0 < my_module.patch

Those are probably the main things you’ll use, but for more information, here are some other references:

One other thing to note is that if your .patch and .module files don’t have the same name, then Terminal does sometimes have issues with it. I’m not sure why exactly.

Hope that helps! If you’ve got any other tips for patching on OS X I’d love to hear them!

Using the GMap Module with Drupal’s Private File System

If you use the GMap module with your Drupal installation, something you may not realise initially is that a file is created in your Drupal file system called gmap_markers.js.

By default this file goes in sites/default/files/js/gmap_markers.js and is not the same file as the gmap_marker.js file in the Drupal module directory.

When the Drupal private file system is enabled, you cannot directly access a file in the sites/default/files directory, this means that when the the gmap_markers.js file is looked up, Drupal doesn’t allow access to it. Fortunately, GMaps provides a way around this.

Change the location of gmap_markers.js

The first thing you need to do to resolve this issue is to change where the gmap_markers.js file is located. The next thing you need to do is to tell GMap where to find it.

  1. Pick a location outside of the Drupal file system. For example, files/js/gmap_markers.js instead of sites/default/files/js/gmap_markers.js
  2. In your Drupal administration section, go to your GMaps settings and below the “Google Maps API Key” text box, there will be an option to specify the path to gmap_markers.js from the Drupal root directory.
  3. Enter the path.
  4. Save the changes.
  5. Click the “Regenerate” button in the “Regenerate Marker Cache” section.

Your cache should now be rebuilt in the new location using these settings. This should resolve any private file system issues relating to the GMap module in Drupal 6. Drupal 5 may vary a bit and I have not tested this, but I suspect it should still resolve the problem, for the most part, but you may need to use a different directory than what I suggested.

Good luck, if you have any issues or other tips, such as for Drupal 5, I’d love to hear about them in the comments.