Web Development

URL aliases tip for migrating from Wordpress to Drupal

Tags: 

I recently re-launched a site of mine, breastfeedingfordads.com, 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.

"Should I learn HTML or XHTML?"

Tags: 

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.

Tips for Google CSE plugin for Drupal

Tags: 

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 google.com 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.

Drupal discovers the world of public-access wiki editing

Tags: 

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

Tags: 

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!

Pages

Subscribe to Web Development