Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By Pushkar Gaikwad on
I like to work on my site on my local system first and used to upload the database, replacing the older one. But nowdays the problem is that I have people posting on my site, so say if I download today's database on my local desktop, make some changes like adding modules and fine tuning it, and than replace the database of the live site, I will loose all posts of users of past few hours/day
How can I sync development between my live site and local development ?
Comments
I have thought about this
I have thought about this same issue and would like to know if any of the larger sites have some tricks to share. In the past, I have only had to deal with smaller changes to individual files. Therefore, I could just backup the file and add in the updated code with no problem.
-----------------------------------------------------------------
Petafoo - We Love Animals
need help
I also need a good way to do this. Someone please give us an answer. Thanks!
+1
+1
subscribing
Although that's a pretty old posting I'm subscribing, hoping there's a solution around these days.
Any suggestions?
Fork / merge script for drupal
What I do follows a fork / merge paradigm: when the test site is created from the live site (the fork), the state of the drupal directory and the drupal databases are archived. After this, the live site and the test site can be modified independently, as long as the activities done on each do not conflict.
This script is preliminary: please see:
https://tekazu.com/content/clone-drupal
(n.b. the site above isn't really live at this time: it still says "Welcome to your new Drupal website" on the front page, and the theme is unfinished. The presented script is in a similar state; review and use with caution.)
=-=
Seems to me that the problem will come into play with a live site staying live. Users will be posting content that the "cloned database" won't have saved. When you push the changes from dev - live, would one not lose the content from the time of export ?
what clone drupal seems to do is the same as some other modules already in contrib do. Unless I've got this wrong from jump.
Database tables are selectively pushed back to the live site
Imagine a situation where users are posting comments on the live site while the admin is adding content. When clone-drupal does the merge step, it will see that the comment tables on the live site have changed, and some of the node tables on the test site have changed. It will take only the tables from the test site that have changed when it pushes to the live site, so the updated comment tables are not overwritten. If there are conflicts, clone-drupal will not merge unless the merge is forced, in which case you do lose data. Therefore, you have to plan in advance; if users are allowed to post blog entries and book pages from the live site, then the admins should do the same, and only use the test site to adjust the theme, test module upgrades, etc.; it's easy to test, as you can run a "status" operation to see if conflicts have been introduced into the two sites, so you can find out if it's okay to edit blogs on the live site while adding book pages on the test site -- which I suspect is not okay, but I don't use Drupal like this, so I haven't tried.
Yes, there are other scripts similar to clone-drupal available, but the ones I found hard-coded which table are "configuration" and which are "data" and assumed that you wanted to take the "data" tables from live and the "configuration" tables from test. There may be other scripts available that I have not found; other existing scripts are likely to be more stable, as clone-drupal is still in early stages.
Once drush-HEAD is stable again I plan to either port this script to drush, or perhaps enhance the existing backup scripts to work like clone-drupal, depending on what is more appropriate. For the time being, drush-HEAD isn't working for me (pm and mm are broken, dl and status work), though, so I'm sticking with the bash prototype until things settle down.
The drupal way
For reference:
http://drupal.org/project/backup_migrate
Ultimately I think I would prefer to convert my script to a drush command, but I may integrate with the backup_migrate module, given time. The script needs to mature in use for a while first, though.
+1
+1