Cruft-free URL annoyances

1> For purposes of illustration, I'm going to turn this one back on you first. If you'd set your output extension to .php, would you be in here saying that MT didn't tell you to make sure your hosting plan included PHP? How about ASP? JSP? CFM? And so on. Or let's get really arcane and say you use a custom extension for whatever reason, like Flickr's .gne(They don't actually do this anymore.)

The basis here is that this is a server consideration. MT doesn't care what your file extension is or even know what it "means" beyond it being a bit of text it tacks onto the end of your archive mappings. If you're configuring your system to output files without extensions, it's your responsibility to make sure the server knows what to do about that, the same way you're expected to first know that it allows PHP.

2> The links include index.html because that's what the file is. In this case, you could have used the Link tag, and its with_index attribute.

but in both cases now, my URLs no longer work if you add a slash after them, since in the case of the entries and archive pages at least, they're not folder anymore.

I'm not sure I see what the problem is here. This is correct for what you've set up, and you've explained the reason for it yourself in the quote.

Keep in mind that the context here is cruft free URLs. Those are generally speaking a good thing, since they future proof your URLs to be CMS & scripting language neutral.

I'm not changing the extension to a particular language specific one, I'm removing it entirely. I'm not trying to switch to something my host may or may not be offering. Note that MT has no problem listing a bunch of platform specific server side include options under Publishing Settings, without really knowing if I'll be able to use them or not.

The bottom line here is that I tried to create cruft free URLs, something which MT didn't seem to do out of the box (and Wordpress does), and I had to resort a method that I happened to be familiar with, but the average blog maintainer who doesn't know about Apache specific .htaccess config options might not have been. The 'problem' that I'm pointing out is that MT lacked easy access to a feature that ought to be supported from the start.

Maybe MT could have helped out here? There's a precedence for it editing the main .htaccess file when you enable dynamic publishing e.g..

I didn't know about the with_index parameter, thanks for the pointer.

I would add to Su's comments the fact that tweaking the web server configuration is outside of the scope of MT. You could be using ANY web server, not just Apache. So, how exactly you tell your web server how to serve the right MIME type when your files have no extension belongs entirely to the web server. That alone means that MT cannot rely by itself on being able to handle cruft-free URLs, so "easy access to a feature that ought to be supported from the start" looks a bit far-stretched(*). Having cruft-free URLs in MT depends on your hosting environment and belongs to a tutorial. There are a few around, and you could contribute one yourself.

(*) Hey, Six Apart, where's my pony? ;-)

François, it's not quite true that tweaking the web server configuration is outside the scope of MT. MT explicitly modifies the .htaccess file for Apache sites e.g. when you enable dynamic publishing.

Perhaps MT could at the very least warn you if you change the file extension to blank?

You're missing the point where MT works with ANY web server, not just Apache. Plus, tweaking a .htaccess is no panacea, your web host could (and usually does) limit you on what you can change through a .htaccess file.

I just disagree on your initial point that MT should do everything out of the box, when it's clearly not its scope. As for documenting the implication of changing the file extension, yes it's better if every single case is documented, though I would argue that one shouldn't play with those settings when they clearly don't know what they're doing (just my opinion ;-).