I don't believe rewrite rules are a particularly intuitive place to put configuration information like that. Maybe I am misunderstanding something, but is the only difference between the development, staging, and production environments the database connection? Typically the code is also different (at least once changes are made), and so if you are using a revision control system, I think it might be a better idea to have a template configuration file (database.cfg.template) that you copy (and tell your revision control system to ignore) and modify (to database.cfg). Then it's obvious where this information is.
views:
235answers:
5You're right -- it's a wierd idea.
IMO, this is a really bad use for mod_rewrite. True, the configuration information belongs with the machine, rather than the codebase (a mistake I see people make all the time), but it doesn't necessarily belong with the webserver configuration, either.
I would recommend a configuration file that is not managed by version control.
If you want to set the environment in the vhost you can do something like
php_value ENV "development"
And then read it from the $_SERVER
array
First of all, if you're not actually changing the URL, don't use $1 as the replacement, just use a dash. As per the docs:
A dash indicates that no substitution should be performed (the existing path is passed through untouched). This is used when a flag (see below) needs to be applied without changing the path.
But really, I think the answer is mod_env. SetEnv directives could be placed within your <VirtualHost> blocks, avoiding the unnecessary RewriteRule foo.