[eluser]Jelmer[/eluser]
@Wanwizard
The most I took issue with is that you call it a lazy-man's approach. I have a system that should work on almost any host, but if I were to make my .htaccess that specific I could never include some updates on every website.
I do get to put my system directory outside the webroot on all my hosting accounts, and to be honest I would push any client to another server if I couldn't do that. So that's not a problem for me.
While you might be right that's it's more difficult to find some errors, it's still a very good approach for many users (like me). It's not lazy to keep things portable, that actually prevents mistakes. That's not lazy, that's a best practice in my book. Maybe that's because I generally have little trouble finding those mistakes, as I load very little that I wouldn't notice missing right away.
In the end I don't fully disagree with you, I just take issue with you calling it "a lazy man's approach". It may be harder for some to find their mistakes and it may be more dangerous if you can't put your system directory outside the webroot. But in the end if you're writing a system that needs to be usable in more then just a couple implementations, you're far better off (IMHO) using code that is flexible.
I'm sorry, I can be a nitpicker on these things: just generally calling something "lazy" because you had a bad experience with it will not go for everyone. I want my system to handle requests that the filesystem can't. I generally combine both approaches, both making some directories excempt from CI handling and allowing for real files to be handled by the .htaccess. Part of that might be that I generally use ".htm" extentions with CI (which would already excempt images and other stuff).
But to reitterate: using a solution like the one we're talking about might cause errors in some situations but it might also be a very good practice in others. Calling it "lazy" in all cases is a generalization I take issue with, not that it might not be the best practice for all.
