Movable Type Extensions

February 6, 2004 9:01 PM

I'm worried this may be too specific for AxeMe, but here goes:

Is this sort of approach to Movable Type urls really a good idea? I've used extensions on my webpages since 1994, and dropping 'em for extended directory structures seems well, weeeiiiiiird. Has anyone here done this? Do they recommend it? Pros? Cons?
posted by keswick to computers & internet (11 comments total)

I've done it on my site. Yes, I like it. (Obviously, or I wouldn't have done it). In addition to the future proofing reasons mentioned in the article, I just find it more aesthetically pleasing. I haven't experienced any cons at all yet. I totally dig it. YMMV. If you decide to do it, feel free to drop me a line if you run into any trouble implementing it.
posted by tcaleb at 9:06 PM on February 6, 2004

It's a good idea to do, for the sake of longevity. You can use any type of server technology (HTML, PHP, JSP, whatever).

The W3C even backs it up.
posted by mathowie at 9:57 PM on February 6, 2004

I do this on all my sites, when I can. My question about an MT site though, is it worth the folder clutter you're going to have to deal with on the back end (I still use FTP a lot). I don't know that the answer isn't, "yes, it is," it's just something I'd consider first.
posted by o2b at 8:05 AM on February 7, 2004

o2b, huh? there is no change in the number of files on the site. The only difference is taking advantage of naming files index so one only need name the directory to call that file, and/or by removing extensions everything else so the client is bothered by whatever server side tech you are using. There is exactally the same number of files, either way. Maybe I am not understanding something you are saying here? Where is the clutter coming from?
posted by tcaleb at 9:14 AM on February 7, 2004

It just occured to me... They aren't saying every file should be called index and be in a directory of its own. Is that the folder clutter you mean?
posted by tcaleb at 9:19 AM on February 7, 2004

Has anyone ever tried to do this retroactively on a larger site?

I'd really like to implement future-proof URLs on one of my MT-powered sites, because I don't want to break the URLs if I ever make changes. But I have about 3500 entries, about half of which are pre-MT, and all of them lack keywords. I've thought of using the titles, but I still have about 1,000, I'd guess, that have incomplete imported titles. Meanwhile people link to entries and if I ever change things, I'll have to be able to redirect those.

In the future, I'll know better.
posted by realityblurred at 9:21 AM on February 7, 2004

Yes, I did it retroactively. I didn't have 3500 entries, but it was still retroactive.

You will need to be able to edit http.conf or make applicable .htaccess files.

Apache's mod_rewrite is your friend. Here are a couple examples of mod_rewrite rules I use to maintain those old links.

RewriteEngine on
RewriteRule ^/index.html$ /index [R=301]
RewriteRule ^/older/(.*)\.html /older/$1 [R=301]
RewriteRule ^/misc/(.*)\.html /misc/$1 [R=301]

Basically, this first rule changes /index.html to /index
The second, every html file under directory is rewritten sans extension.
The third, same as second, different directory.

Note, the rewriting is done on requests, so the "old name" is on the left, the "new" on the right. See here for more examples.

I am very OCD about directory layout, etc, so that is all I needed to do to maintain those old links. You may need more or less.

(And yes, I know that I could have done all of those actions in one rule, but there were some directories I wanted left alone and it was easier to explicity name these three rules than make exceptions).
posted by tcaleb at 9:53 AM on February 7, 2004

Thanks much. I think that solves half my problem; the other half involves naming the files. Currently I'm using the entry ID, but I know that is problematic. But it just occurred to me that I can export and edit all the entries -- it's just 84,900 lines of code -- to add titles and keywords, plus solve other lingering problems.
posted by realityblurred at 10:43 AM on February 7, 2004

I'm not sure why this is considered "future-proofing". Sure it looks different, and doesn't make it obvious what server technology you're using, but even if you switch page technologies in the future there's no reason you can switch PHP to using '.asp' extensions, or JSP to use '.html'.
posted by kaefer at 12:16 PM on February 7, 2004

realityblurred, in MT make a new individual archive template called Indiv Redirect (or similar) and use your old naming scheme -ie entry id in the archive file template. Then make the new (default) individual archive template with whatever you choose for the new scheme (personally, I use the entrytitle dirify'd and html'zed). In the old template put the following in the head section of the page.

<meta http-equiv="refresh" content="1; URL=<MTEntryLink> />

This will send the person from the old link to the new default one.

This is obviously not the most efficent way to do it, but I couldn't think of a better way to handle the drastic redirect. Especially since I went from /category/entryid to /category/year/month/day/title.

If there is a better solution I would love to hear it.
posted by tcaleb at 12:37 PM on February 7, 2004

I'm in the processs of doing this for several thousand entries on my site, and while it probably doesn't actually make any difference, I feel a whole lot better.
posted by anildash at 2:54 PM on February 9, 2004