Smokes your problems, coughs fresh air.

Tag: Drupal

Enforcing Drupal URL aliases

I hate modules, especially core modules. I prefer code to be tightly integrated. I want it to work together. Is that too much to ask? In Drupal, most functionality has been stuffed in modules. There’s a Locale module, a Content Translation module and a Path module. What’s missing is a Working Together module.

For me, clean, meaningful URLs are a number one, two and three requirement for any website that I do. Drupal considers /node/54673 to be a cool URL. I don’t. So, as a kind of afterthought, Drupal comes with the Path module. This module allows you to set URL aliases per node.

The problem is that there’s no concept of a canonical URL. The URL alias works, but so does the node/3242 URL. Neither redirects to the other. In many cases this is not much of a problem (because regular visitors will not notice this) but for our current project it is.

We have a lot of blocks with URL dependent visibility settings. For example, for a section about investing we have a menu that is displayed on all URLs starting with /investing, such as /investing/projects and so on.

After editing a page, Drupal helpfully redirects the user to node/[nodenumber]. For us, this means that the menu is no longer displayed and even the theme will be wrong. (We use the Sections module to select a subtheme based on which section you’re in.)

Global Redirect doesn’t work

The Global Redirect module promises to solve this by allowing you to redirect node/[nodenumber] URLs to their alias if available. It kinda does, in some circumstances.

Our Drupal website sports two languages: English (EN) and Dutch (NL). English is the default language (not the fallback language; we don’t use a fallback) and doesn’t use a prefix. Dutch uses the nl prefix. Two example URLs:

URL alias Generic URL

When /node/288 is requested, the client is correctly redirected to /investing/projects, but when /node/110 is requested, no redirect takes place. It will take place when prefixing /nl, but this is completely useless since Drupal’s built-in actions such as edit don’t redirect using this prefix, and these actions were what we needed this module for in the first place.

A very simple hack that does work

We ended up tearing our hair out trying to fix Global Redirect until we decided that we could just delete the module and replace it with a RewriteRule and a simple PHP script.

Modify: .htaccess

# Put this after RewriteBase and before Drupal's default rewrite rules
RewriteRule ^(../)?node/([0-9]+)$ fixurl.php?nid=$2 [L]

Add: fixurl.php

require_once './includes/';
$result = db_query("SELECT * FROM {url_alias} WHERE src = 'node/%d' LIMIT 1", $_GET['nid']);
if ( db_error() ) die("O agony!");
$url_alias_object = db_fetch_object($result);
$destination = $url_alias_object->dst;
$result = db_query("SELECT prefix FROM {languages} WHERE language = '%s'", $url_alias_object->language);
if ( db_error() ) die("O agony!");
$prefix = db_result($result);
if ( !empty($prefix) )
  $prefix .= '/';
header("Location: /$prefix$destination",TRUE,301);

Shortcomings in our hack

The code assumes that every content page has an URL alias. For us, this is okay, because we need these pretty URLs to even have menus show up or to have the right page be displayed with the right theme.

Also, this code is specifically tailored to language code in the URL prefix. For subdomain based language selection, for example, you’d need to modify it.

Drupal 5 image management

Today, I have to face the task of finding reliable Drupal 6 modules for image uploading and WYSIWYG editing, so I dug into my drafts bin and found an old unfinished post dated March 24, 2008 about a similar quest for Drupal 5:

I’ve founded this new website, (Don’t mention the name; I know it’s sheer genius.) Drupal is going to power the site. At least I hope it will. First, I have to somehow convince Drupal’s media management not to suck, so far to little avail. 🙁 This post is my attempt at getting my thoughts straight. (It’s the logging in blogging that is of great help to me when, later, I can quickly pick up a problem where I left it. Also, sometimes, a better solution is thrown at me.)

So, Drupal: Drupal is great! The installation is a snap. The organization of the management interface is very intuitive and I love how interdependent modules are handled (i.e.: the fact that they’re handled). I ended up with Drupal in my search for a system which can power a weblog and a wiki at the same time. Drupal is a CMS framework which I had often come across but for some reason had never taken a closer look at. Much to my detriment, was my first thought during the configuration/exploration phase after installation.

Before I continue about Drupal, I should tell you something about what I want to do with Naturally, the topic will be wilderness. The site’s purpose is to popularize the wild, uncontrolled aspect of nature. I’m doing this because I’d like to see wilderness everywhere, but especially in your eyes. The site will mostly be a blog, with illustrated stories, podcasts and even video’s. But, we want to have the ability to add a knowledge base (with wiki power). And everything has to be integrated, much more deeply than in my Point Omega project where I simply installed MediaWiki and WordPress, each on their own subdomain.

Now, I need to make a selection from the many media management modules which are available for Drupal. Initially there will be some posts with many photographs on Uploading and annotating these one-by-one will take all the fun out of it, so I want this to be made easy. The modules which I choose will have to facilitate this.

  • EXIF extraction is an absolute must. IPTC extraction is optional, as long as the IPTC information is not stripped from the original images. If changes to the extracted data would be changed back in the original images, this would be especially nice.
  • Batch uploading is another requirement. I don’t care much whether this is through WebDAV, a Gallery2 API or even using a compressed archive, but I don’t want to upload images one by one.
  • A final wish is the mass editing of captions and/or other meta-data. I like very much how Google’s Picasaweb does this. If this works well, it could somewhat mitigate the need for EXIF/IPTC meta-data extraction.

Up till now I’ve tried the following:

  • The first thing to decide was whether to use the regular Image module or not. I chose yes because there are so many other modules which depend on this module. It comes with a few contributed add-on modules already. The included gallery module is quite to my taste, so that’s good.

  • When using the Image module, there are many options for inserting images. So far, I like the GUI of Image Assist for uploading and inserting single images. I do think that the button messes up the layout of the content creation page though. Also, a module like this is completely useless when you want to upload more than a few files, which I do. 😕

    Drupal content creation screen with the img_assist module enabled
    The content creation screen was so beautifully sober without the intrusive Image Assistant icons!

    There’s another module, Upload Image, which might be even better for uploading single images. I like that it integrates with the attachment functionality which keeps my screen clean and comes from a core module. What this module does extra is that it turns each attached image into an actual image node, opening up many advantages such as adding the attached images to albums and everything. If I keep using the Image module, this module will also remain part of my toolkit for sure!

    The Upload Image module is supposed to display thumbnails instead of filenames in the attachment list. It doesn’t for me. But there’s another module, Upload Preview, which does just this and only this. Too bad that this module doesn’t work. It seems easy enough to fix, so I might patch this if I decide to go this route.

    I haven’t tried Node Images. It doesn’t have a proper release yet, and I’m not sure what it’d add over the other attachment features.

    But, of course, there’s competition for the core upload module: File Field uses the Content Construction Kit to do the same.

  • The Exif module can only display Exif data at this time, while I want to extract at least a caption. Support for extraction is planned. David Lesieur, the author of the module is not actively developing the module at this point.
  • Independently from the Image module, I’ve tried the Asset module. This module doesn’t seem to like safe_mode very much and I think that its file picker/upload dialog is inferior to img_assistant’s.

Something I haven’t tried: I like the ideas of the Media Manager module, but it’s hardly feature-complete or even stable at this point.

Maybe in the end I’ll have to settle for using a service such as Flickr or Picasaweb with some integration module. That would be quite a bummer, actually.

Because I was in a time-squeeze at that time, having the images hosted elsewhere was actually the last-minute solution that I chose for anything more involving than a few loose images.

Then, there’s still audio and video, but I think I really have to save that for a later time, although if this makes me choose for a the Asset module, for example, I might be totally screwed if I’ve already come to depend on another (incompatible) set of modules for image management.

Also, there’s an annoying bug in Image Uploading module.

This post applies to Drupal 5, while both that website and the website I’m working on now run on Drupal 6.

As a sidenote, the upgrade from Drupal 5 to Drupal 6 at the time was a total disaster, probably due to all the messing with modules and ended up with me painstakingly reconstructing all content from an SQL backup. 🙁

© 2024 BigSmoke

Theme by Anders NorenUp ↑