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.

All in one wifi router vs separate parts?


If you had:

  • 100mbit Ethernet
  • 11g wireless
  • router/firewall
  • all in one device

and wanted to upgrade to:

  • 1gbit Ethernet
  • 11n wireless
  • router/firewall

would you go with one device or separate them into multiple components? And, what requirements would you have for the component(s)? Lastly, any model recommendations?

Thanks interweb, you're the best! :-)

"Should I learn HTML or XHTML?"


I've actually been asked this question several times lately, where someone wants to either brush up on their little used and mostly forgotten skills, or is looking to learn from scratch. The answer to the question is simple: XHTML all the way, and here are my reasons:

  • With XHTML you have to close every tag, rather than e.g. leaving paragraph tags hanging around on their own. This will lead to much more organized and clean code as all tags will be correctly nested.
  • Cleaner code will lead to fewer bugs as it will be easier to keep track of the code.
  • Having all attribute values in quotes means you longer have to wonder why your <img src=/images/oh so important.png> image doesn't work right.
  • The syntax rules force others providing content for the site also have to keep their work in check, which can avoid conflicts.
  • XHTML means no font tags, so you have to do your design in CSS. This starts pushing sites towards separating the content from the presentation, which is a very good thing.
  • XHTML doesn't allow the BLINK or MARQUEE tags, which should be the number one reason to use XHTML - they're evil and as developers it is our job, neigh our duty, to save managers from themselves.

Drupal discovers the world of public-access wiki editing


200811192054.jpgThose wonderful people in the Drupal community have been awesome citizens and have stepped up to the plate after the Drupal documentation team opened the doors for anyone to contribute to the official online "handbook" documentation.

The previous situation only allowed certain individuals to edit pages, so if while strolling along through the pages you happened to notice an inaccuracy or something you thought you could explain better you had to either write a comment or email the person in charge of it.

Now, after a month-long experiment has worked out nicely, the powers that be have decided to leave the open-editing on so everyone can benefit from the continued goodwill.

Yay! :-D

Learn Drupal by practice, itterations


I've found that web development as a whole works best by iterative development, using many concepts from Getting Real and other agile theories. This is definitely true of Drupal. When you start off with Drupal you'll start building content types, views and panels galore, and there's nothing wrong with this, it's the best way of getting your ideas out so you can see how they work. You'll also then start dipping your toes into other modules and then writing your own, using books and documentation along the way. Good times.

The thing to remember is to revisit your previous work and improve upon your work: export views to files to speed them up and add an element of revision control; rewrite some clunky SQL queries with improved architecture and views; merge two modules you wrote before and make one that's better; add extra text to node titles for improved search engine accuracy; clean up the CSS and views to work faster and produce more sane output. And on and on..

There's lots to do, lots to learn, don't stop!


Subscribe to Computery