Posted by drm on April 15, 2008 at 3:20pm
Hi folks,
I need to create a parallel test and development site on a subdomain for a client. It seems like a fairly straightforward task - copy everything over, and then change the database access stuff - that's in settings.php, right? And change the access permissions so that the public is not reading that site.
But I was wondering if there is a tutorial for doing this, or some common mistakes to avoid. I searched on Drupal.org (and google) and didn't find anything, but sometimes the search features aren't that good at finding such things.
Thanks for any tips.
Comments
correct
No tutorial that I have seen, but what you pretty much got it down. You can lock down the beta site using the htaccess file, or take the site "offline" through Drupal, and then only Admins can access it.
Lev Tsypin
ThinkShout, Inc.
thinkshout.com | twitter.com/levelos
Apache Config
If it's very restricted on an internal network, you can also restrict access in Apache to a specific IP Address (or addresses) so it never shows up publicly.
VirtualHost 192.168.230.9
ServerName drupaltest.kb0odu.net
DocumentRoot /home/web/drupal60/
Directory /home/web/drupal60
Order allow,deny
Allow from all
Allow from 192.168.230.7
Options +Indexes FollowSymLinks
/Directory
ErrorLog /var/log/apache2/drupal60.err
CustomLog /var/log/apache2/drupal60.log combined
/VirtualHost
Pardon the formatting. I can't seem to enter the correct apache directives. Hopefully you can make appropriate changes.
NOTE: This DOES require root access to update the appropriate Apache config file and restart Apache. Of course, YMMV.
TJ
n00b mistakes
Here are a couple additional items I'm willing to admit learning the hard way:
.htaccess: don't leave it behind. Copy and Paste on a Mac will screw you up every time if you're not careful. Tarball = better.
"Files" folder: make sure you check and correct permissions on the Files folder AND all internal files and directories.
php.ini: sounds like you'll be in the same environment, but having different settings can drive you mad.
Lastly, and I risk opening up a can of worms here, it's not setting up and using the dev site that's going to be tricky. Potentially it's the whole getting things moved and implemented on your live site. Doesn't have to be rocket science, but you'll save some time if you think through beforehand. Sounds like you're really just moving visibility on the domain level - 'sync'ing' two installations is a bit more...tedious.
Best.
-dp
Ditto this -- migrating settings can be a bear
Views and CCK are relatively straighforward, as the definitions for both can be exported/imported between sites.
Menus and blocks -- a different story. And module configs are also a different story. Keeping an accurate log here can save you much heartache -- and, if you are doing this for a client/within an organization, your config logs can be easily transformed into admin documentation.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey
Syncing Test and Live Installations
I struggled with syncing my development and live installations when first starting out on a large project; my test installation a slew of testing nodes/modules/blocks that I didn't want transfered over to my live installation (and vice-versa). Fortunately, I ran a across a project called Drupal Migraine, which provides database syncing between a test installation and a live installation without overwritting content on the live installation.
Another thing to remember when setting up a testing subdomain is to edit the robots.txt file to disallow search engines from spidering your site, on the off chance that they stumble across the subdomain.
Development sites are
Development sites are marvelous with new sites, and tricky as all hell with existing sites. The live site's Drupal database keeps changing, and so does the test site and the two are often difficult to reconcile, especially if you use some of the more complex modules, like the usernode, node profile lot. I have seen many silly mistakes, like advanced users making changes to the test site and wanting them carried over, developers fixing a bug in the wrong place, database confusion and worse confusion on the database backups (copied backup scripts), and more. It is a weakness of Drupal that having a development/test site is such a difficult thing to do, because from a pure development point of view it is far better methodology to have a test site, and a development site too for that matter. And I've yet to find a really good data-migration tool, and you need one.
Sala kahle,
Grant
A relatively new tool that shows progress
http://drupal.org/project/deploy
It's definitely worth looking at -- the dev is looking for people to test/help out, so now would be a good time to join forces with someone else looking to scratch the dev site itch.
Cheers,
Bill
FunnyMonkey
Tools for Teachers
FunnyMonkey