Webdev: July 2003 Archives

Már Örlygsson has written a howto on creating 'future-proof' URLs in Movable type. In short, he suggests storing individual archives at http://www.example.com/archive/2003/06/17/12.35.57/. The archive file will be called index.html. I like this idea, since it will allow me to change my site, without having to change my URLs. If for example one day I decide to use PHP in my pages, all I have to do is change the template and create index.php files. Since the URL's won't change, no links break.

Some day I might try to implement this, but I won't use the directory structure Már proposes (/yyyy/mm/dd/hh.mm/). He doesn't use the title in the URL, since he writes in Icelandic, which has some 'strange' characters. I write in English, so I don't have that problem. The other problem Már describes is that the location of the file changes if you change the title. This is true, but I also think that you think first before you post, and choose the best title possible. I have never changed a title of a post afterwards, and am not planning to do so in the future. I do see that this might be a small risk.

I also won't use a directory-level for the day. Not only because I don't post that much, but even if in the future I start posting three entries each day, the 90 files per directory won't be a big problem. The benefit of keeping the URL short and clear is more important for me. When I want to reread a message, I often just type in the URL. I can't always remember the exact day, but usually I know the month and the title of the post. With these two bits of information, I can quickly look up a page. So I opt for URI's like /archives/yyyy/mm/title_of_the_post/.

A while ago, I explained how I configured the server to return HTTP Error 410: Gone for all requests for pages created with my old CMS. After installing Movable Type, all pages of my site moved to another location, and I was not able to work out the new location of the files. In short, error 410 says: The requested file used to exist on this location, but it has gone to an unknown location. This message is more clear than the message returned by default; the famous 404.

I always check the server logs for 404 messages, since it might indicate that a link on the site is wrong and I'll have to fix that. One of the files coming up regulary in that log is the default MT stylesheet styles-site.css, which I have replaced by my own stylesheet with a different name. I immediately wanted to add this file to my '410--list', but then I realised that 410 is not the correct code, since I do know where the file went. Therefore a better solution would be to return code 301 (permanent redirect) together with the new location, so any smart client would simply redirect to the new address.

To implement this, I only needed to add a single line to the .htaccess file:

Redirect permanent /styles-site.css http://www.braintags.com/paz.css

This line tells the server to redirect requests for /styles-site.css with code 'permanent' to the file http://www.braintags.com/paz.css. Remember that the destination always has to be a complete URL!!

After yesterdays post I started playing more with Movable Type. I decided to move some static content from my site to a separate section, as described by Brad Choate. At that moment, the only static content I had were the HTML error pages, displayed in case somebody asks a non-existing page. These pages were implemented as index templates, but with the new method I can treat them as normal texts without having to edit HTML code. I also decided to move the Stylesheet templates to the new section, since they are hardly ever updated.

After entering the texts for the error documents, I ran into a problem. I wanted to use almost the same templates as I am using for the rest of the site, but these templates make use of template modules (text snippets), which are linked to a specific section. So I started looking for a solution to display information from one section into another. And I found exactly what I was looking for: MTOtherBlog.

After this success I created some more static content (a Spambot trap), and fixed my search page with the MTOtherBlog plugin.

I am very happy with my MT static content solution. However, after this experience I realise that MT is not suited for the Fimcap site, since it has too much static content in a more complex directory structure. This would mean that we have to create a seperate category for every subcategory, which would make it difficult to manage.

The buzz started with the redesign of Adaptive Path by [stop]design and Jay Allen. They used the Movable Type blogger software to produce a commercial site. And not only as a CMS to publish their 'Appearances', 'Essays' and 'News', but also to manage the static content of the site! Jay Allen posted a description of how he set up the Adaptive Path configuration.

Other people already had the same idea or started working after reading the above story. Doug Bowman of [stop]design started managing his portfolio with MT, Matt Haughey explains how to use MT in alternative ways, like creating an About page and using the database fields in different ways. He also lists some sites using MT this way. And finally, master MT-hacker Brad Choate explains how to use the MT-categories to place static content in directories. Managing static content with MT is definitely THE hype of this week!!!

I have been reading all this with a lot of interest. Already for a while Sebastiaan and I are thinking about a CMS for our Fimcap site, since this site is at this moment completely maintained by hand at HTML level. We do use some Server Side Includes (SSI) to handle general content like the page headers and footers, and NewsPro for some content, but mostly we have to change the HTML code. This makes it also really difficult for others to contribute to the site, since they first have to understand HTML and the organisation of our site. We have been looking around a while ago, and the best fit I could find at that moment was Plone, but since Plone is so completely different from what we are doing now, this would involve a really steep learning curve.

But now it looks like we can do it in MT. We can manage our static content, create templates, and store our dynamical content. The only thing I have to figure out is how we can implement the site in three languages. I guess I will just set up a demo and start playing...