By jaochoo on

On the one hand, people say to never develop on a production server. On the other hand, most development seems to happen in the Drupal backend, creating content types, views, panels, taxonomies, configuring modules, etc. So it is not just about moving some theme directory to another server.

So how can I move my developments to a production server? I know that modules like Views, CCK, etc. have some import/export functions now, but what about all the various module and system configuratios and settings? In the beginning I tried to write down everything I changed but that soon wasnt efficient.. So how can I move from development to production? I guess I cannot just copy the whole file system and database..

⋅ Categories: Drupal 6.x

Comments

bwv’s picture

bwv commented

You might want to upload drupal core and the modules you use to your server, and untar them there.

Then import your database using phpmyadmin, for example.

Go to settings.php and manually configure it.

That should do the trick.

matter9’s picture

matter9 commented

Yes, what bwv says is the way to do it. Here's a little more clarification. The entire configuration of your Drupal site is stored in the db, so you don't have to individually backup views, cck, etc. just backup the db with mysqldump or phpmyadmin. Then, on the production site, create a db and restore that backup to it and everything is in place except the filesystem.

The filesystem contains two things: the Drupal scripts, including all of the modules you're using, and the contents of the files directory (or /sites/all/files or wherever you put miscellaneous files) These files are the images, pdfs, docs, etc which are referred to in your content. The relative path must stay the same if you want those references to work on the restored site. So, you could tarball or zip the entire filesystem, from /drupal down and then unzip it on the production server.

Last, adjust the settings file in /sites/default/ (or wherever) to point to your restored db and you should be good to go.

There is a pretty complete description of this restore procedure in the handbook.

yelvington’s picture

yelvington commented

You have two problems, not one.

Initial migration from dev to prod is pretty straightforward: Tar up your files, dump your database, move them to your production server, untar, and load the SQL. The http://drupal.org/project/backup_migrate module makes this very easy.

Once you have your production system up and running, any further development gets somewhat tricky. If you do any configuration work on the development server, you have to duplicate it on the production server. Usually that's a manual process, although some modules (such as Views) now have export/import capabilities.

There are some ways to automate the process, such as http://drupal.org/project/features, but you still have to be careful, as not everything you might do and test on your dev server is exportable.

victor.stan@gmail.com’s picture

victor.stan@gmail.com commented

I find this to be a major low point for many content management systems, and Drupal especially (since it's what I like to use). I think having settings not clearly delineated from content is a major design flaw that is hitting me really hard.

The more 'live' your site is, the more social it is, the less possible it becomes to just dump development stage db to live stage.

Clearly some people must have found a way around this, there are are universities, governments and successful commercial sites that use Drupal that must have experienced this problem and found a way around it.

Some devellopers have tried to make modules that makes the copying over less painful. The one that stands out the most is the deploy module http://drupal.org/project/deploy -- but I havent used it yet, it has some issues that will block me from being able to enjoy its 'theoretical' benefits.

Here is my question, and this is also a question for D7... why not separate settings from data? Make two databases! Use XML to store setting information. But don't just jumble everything together!

Now I'm in a very panful position of trying to set up a time efficient error-free process of updating setting only without touching the content of drupal databases...

Any tips and help appreciated!