URL aliases tip for migrating from Wordpress to Drupal


I recently re-launched a site of mine,, which I migrated from Wordpress to Drupal. It took a bit of work to get the basics the way I wanted, and replicate the functionality of the plugins I was using, but it seems to work well.

There was a bit of a problem, however. Out of the box, all of the old articles that were converted to the "blog" content type (as created using the converter mentioned before) had the arcane default URL structure of "content/[title-raw]". An obvious problem was that this didn't match the Wordpress default nor my custom format of "[yyyy]/[mm]/[title-raw]". This was leaving me with lots of unnecessary 404 errors and disgruntled visitors, so it needed to be fixed.

Here's how I fixed it:

First off I had to update the existing settings so that Global Redirect wouldn't keep re-building the wrong ones..

  • I went to the "Automated Alias Settings" page (Site Building -> URL Aliases -> Automated Alias Settings).
  • Under the "General Settings" section I removed everything from the "Strings to Remove" text box so all words would be retained.
  • Under the "General Settings" section I also enabled the "Reduce strings to letters and numbers from ASCII-96"
  • Under the "Node Path Settings" section I updated "Blog entry paths" to "[yyyy]/[mm]/[title-raw]".
  • Under the
  • After that I hit "Save Configuration".

Next off I had to purge the old aliases:

  • I went to the "Delete Aliases" page (Site Building -> URL Aliases -> Delete Aliases).
  • Once there I selected "content" and clicked "Delete Aliases Now".
  • After a moment all of the page aliases had been removed.

Lastly, I wanted to create the correct aliases ahead of time - I could have left it Global Redirect to do, but best to take care of this now:

  • Again, back to the "Automated Alias Settings" page.
  • Under the "Node Path Settings" section I opened the "Replacement Patterns" section and clicked on "Bulk generate aliases".
  • I think clicked "Save Configuration" to have all of the URLs updated, and because there were more than 50 nodes to update I had to run it twice.

Note that the last step could have been done in one step by updating the "Maximum number f objects to alias in a bulk operation" to a higher number, but on very large sites you should be careful to not set it too high or the page will time out.

Anyway, after a few quick moments all of the old URLs were no longer generating 404 errors.

Tips for Google CSE plugin for Drupal


If you've decided to use the Google Custom Search Engine (CSE) plugin for Drupal, there are a few things you can do to make life easier for your visitors:

  • Add some rewrite rules (to the .htaccess file) to redirect requests for the old search engine to the new one. This can help visitors who know how Drupal works and were typing their search manually, etc.
    • RewriteRule ^search$ /search/google [R=301,NC,L]
    • RewriteRule ^search/node$ /search/google [R=301,NC,L]
    • RewriteRule ^search/node/(.*)$ /search/google?query=$1 [R=301,NC,L]
    • RewriteRule ^search/taxonomy_search$ /search/google [R=301,NC,L]
    • RewriteRule ^search/taxonomy_search/(.*)$ /search/google?query=$1 [R=301,NC,L]
  • Disable the built-in search engine module to reduce memory overhead and speed up page requests.
  • Use some CSS to hide the background image added to the search boxes:
    • input.form-text {
    • background-image: none !important;
    • }
  • If you have custom search boxes replace them with code that calls the Google CSE engine, i.e.:
    • <?php print drupal_get_form('google_cse_searchbox_form');?>

Put together this can make the GoogleCSE almost(*) completely transparent to your visitors.

* Note: I'm not sure if it's a feature or a bug, but I'm going to go with the latter - all search result pages for GoogleCSE append a great deal of information to the URL instead of just submitting these fields transparently via the API call. This is obviously not very user friendly for advanced users who can normally just go to e.g. /search/node/doodlebutt to search for "doodlebutt", or for occasions when you're doing tricks on the search engine, instead when visitors do this they're just putting their search term into the search box and will have to click the Search box to see any results.

Don't take your iPhone abroad


A simple statement for you: unless you have AT&T stock, don't take your iPhone with you when you go abroad. If, for some crazy reason you decide you moost haf eet, at least do yourself a favor and:

  • disable data roaming
  • disable 3G

You may also want to enable Airplane mode, just to be sure.

I say the above after having returned from two weeks in Ireland. Before we left we signed up for the 20mb international data plan and international roaming. What we didn't do was:

  • sign up for the 30mb data plan
  • sign up for the international calling plan

I believe if we'd signed up for these two we'd probably saved about $100 off the $350 bill that followed soon after our return, but quite possibly not that much.

Overriding CSS can be a pain


One of the difficulties with Drupal is that with so many modules needed to make a good site you can end up with a dozen or more different CSS files. On occasions when you need to tweak the CSS to match a specific design, or fix something for IE6, it can take quite a while to dig down to the exact definition you need. You might try throwing random snippets of CSS at the problem to try to make it go away, but they usually won't work.

What I've found is that to successfully override CSS you have to repeat the exact same definition as the original, no matter how obtuse it my seem. So if you want to override one simple paragraph you may have to assign some pretty strange CSS, eg.:

* html .span-6 {margin-right: 5px;}

If that's what is already being used, then that's what you have to do to override it.

It may be a bit frustrating, but following that simple guideline has saved my bacon several times.

Patch for wp2drupal for Drupal 6


I'm trying to migrate one of my personal sites from Wordpress to Drupal and needed a way to migrate the existing data. Well, it turned out to be a little tricky as I'm using Drupal 6 while the only really useful converter, wp2drupal, was written for Drupal 5. Luckily someone converted wp2drupal to D6, so away I went.

Unfortunately I wasn't able to get far, it turned out that there was a problem in the D6 port which causes an "Access Denied" error when you actually submit the form to begin the conversion. Not to be undone, I started poking around the script and discovered that the menu configuration was using an older format than what the current Drupal release (v6.4) required. A few quick lines later and I was able to get it working again.

In the interests of helping the community I've compiled the changes into a patch file:

There are still a bunch of syntax errors that will show up after the data has converted, but at least it will actually convert the data over. Also, I made some minor tweaks to the code according to the Drupal development guidelines based on what the coder module recommended. Lastly, be warned that the patch was created using git, so it may be easier to just add the few missing "access" lines manually.


Subscribe to tips