Problems With My Relatives

Things are shaping up pretty nicely so far on this anti-CMS CMS, but the first snag has been hit: relative references. It reared its ugly head when I implemented categories/tags, but it's even going to be a problem for gathering articles up for this index page. Let me illustrate it by way of this example image:

You can probably see that image but, as I write this article, I can't. That's because it is given using its full URL (e.g., http://www.impossiblystupid.com/node/201/images/scream.png). Until this article gets published, though, that file does not exist on that server. And even though you can see it now, if anything changes about my setup, it'll break a URL like that. You can see the problem in action if you go looking for some Impossibly Stupid things on the old site that expect to be on the www site (e.g., Nice Bulge vs. Bulge-less). In general, having a full URL is necessary for everyone else to find a piece of content, but it is really inconvenient to use by people who are putting together and organizing said content. So the middle ground is usually:

You can probably see that version of the image, too. It's given using just its absolute path (e.g., /node/201/images/scream.png). The way the web works is that it goes looking for that image on the same server that it got this page from. This is slightly more convenient for people putting sites together, because it means I can use a private server to stand in for the public server, allowing your software to still find the image at the same place on the public server that my software put it on the private server. The path is absolute, but the server is relative.

It's still not as nice as it could be, though, because it still makes it hard to move things around internally. In particular, putting everything under /node/ for now is really just part of my strategy to transition things away from Drupal, since it used the whole /node/ organization scheme. The point being that even the above image will not be found if I want to reorganize things locally. And that leads us to the crux of the problem:

You probably can't see this image, but I can. It's given using a completely relative path (e.g., images/scream.png). It means the image can even be found by the web browser without needing a server at all or access to any particular directory/folder structure; it just looks in the same place it found the page that references it. Most content management systems don't use relative links because their pages don't really have a so-to-speak “location” on the computer, but rather they're usually just generated from information stored in a database.

So how can I see it but you can't? Well, the truth is you can see it if your idea of “local” is the same as what the server expects. Which is to say, if you go to the individual page for just this article you should be able to see all three images just fine. The problem I'm faced with is that the index page (and category pages) gather up a number of articles and tries to display them in, as far as a web browser is concerned, the “wrong” location. Because of how I build up this list of articles it, for example, sees images/scream.png and wants to look “locally” for it, either at the index (/images/scream.png) or at the category pages (e.g., /organization/category/Web Playpen/images/scream.png), but it's still actually under /node/201/images/scream.png. Result: broken image on those other pages.

So there are two solutions I'm going to look into over the weekend. The common solution is to do what most CMS software like Drupal does and put everything at an absolute path. To be honest, that's also going to be most convenient for other external referencing of the files, such as for the RSS feed. But what I really want to play with is using JavaScript to change all the relative paths into either absolute paths or even full URLs. Because, conceptually, it is better to have a self-contained context, limited scope, and a minimum number of external dependencies

Update: You should now be able to see all locally referenced images. The “trick” I used was to load the article's individual page into an iframe, and then a simple copy-over of all the document images' src attribute seems to turn them from a relative path into their full URL. A similar technique should work for any other types of element that link to extra content using relative paths.