Development Enviroment for Drupal is an article I wish I’d found a year ago when it was originaly posted. Its an extensive description of how to use svn and other tools to maintain various Drupal environments synchronized. I’m pleased that it confirms my own decisions about how to use subversion to manage core and site-specific modules. I to use a symbolic link to point the /sites folder in my webroot to an external directory with my site-specific files. The one thing I found about doing so, not mentioned in the article, is that you’ll want to add the following rewrite condition to the rewrite rules that funnel most web requests to drupal’s own index.php file. This condition excludes symbolic links and makes files requested by visitors cachable. Your modified .htacess file should end up looking like:
# Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
Drupal’s largest design flaws is how it stores both content and configuration in the database, and not just in the database but often times in the same table, like variables. This could be fixed simply through a table naming convention where config_ had been prefixed to configuration data tables, but its a bit late now. Yes, this means there’d have to be a config_variables and a variables table, but we could all live with that. Bit I digress, I’m intrigued by the dbscripts project, particularly its promise of being able to merge changes from database dumps coming from multiple environments and is something I need to look at sooner rather than later.