I have two Drupal 7 sites running a very similar structure (views, content types, etc) but with a different theme and a few other changes.

I need to have all the nodes of specific content types that are created in site A to be copied to site B. If it is possible, it should work automatically or by running a script. For example, the sync would run as a scheduled cron job.

I do not need both sites to run in the same database, they must have their own separate database, just the same nodes for specific content types.

I've been investigating, and I see that I can use Node Export, Feeds and even a drush command (ne-export/ne-import). I'm not sure yet about how to put all the pieces together. Has anyone done this already?

  • Is there a reason why you can't just switch themes based on it's url? This seems like the least complicated way to go about this. E.g.: drupal.stackexchange.com/questions/812/…
    – chrisjlee
    Jun 1, 2012 at 17:14
  • 2
    Of course there is a reason, that's why this is a problem. There are more differences including modules and views. As I said, I need these sites to have their own separate databases.
    – jpatiaga
    Jun 1, 2012 at 19:43
  • I'm trying to do something pretty similar to this. Have you made any progress in the last few months? I see Deploy 7.x is still in development. Oct 15, 2012 at 17:19
  • The following blog post has a detailed step by step instructions for syncing data between two sites. This is the best possible method for syncing specific data like particular content type etc,. (The same should work between D6 & D7 sites as well.) isovera.com/blog/…
    – Chakri
    Dec 4, 2014 at 8:33

4 Answers 4


For Drupal 8 you can use the Content Synchronization module. From the project page:

The content synchronization module provides a mechanism to export single content items, or all content items, from an environment, and move them to another, effortlessly.


The following method is not officially recommended. But if you understand what you are doing and what the consequences are, the benefits can outweigh the drawbacks.

See Share tables across instances (not recommended)

I'm using this setup to run a network of sites for a client of mine where content is identical across sites, but the presentation (including views, modules, variables, block placement) is different. My particular setup is Drupal 6, but it could easily be adapted for Drupal 7.

The first step is to configure each of the sites to run off the same database (using table prefixing) and codebase (using Drupal's multisite functionality)(*). Once the sites are all running off the same DB and codebase, you can create a $db_prefix array in your settings file.

In my setup, each of the sites shares all tables with the default site by default:

$db_prefix['default'] = 'default_';

And the following tables are unique per site (again, this is D6, D7 would be slightly different):

$db_prefix = array(
    "sessions" => "site1_",
    "authmap" => "site1_",
    "variable" => "site1_",
    "system" => "site1_",
    "role" => "site1_",
    "menu_custom" => "site1_",
    "menu_links" => "site1_",
    "menu_router" => "site1_",
    "cache" => "site1_",
    "cache_block" => "site1_",
    "cache_form" => "site1_",
    "cache_menu" => "site1_",
    "cache_page" => "site1_",
    "cache_update" => "site1_",
    "cache_views" => "site1_",
    "cache_views_data" => "site1_",
    "views_display" => "site1_",
    "views_object_cache" => "site1_",
    "views_view" => "site1_",
    "blocks" => "site1_",
    "blocks_roles" => "site1_",

I've been running these sites in production for a couple of years now. Editors only login to the "default" site (defined in /sites/all) and all content (nodes) is managed there. Changes to nodes take effect on all of the "slave" sites immediately and without any intervention (save for whatever caching you have in place).

This is definitely an advanced option and it has it's drawbacks (upgrading between major versions of Drupal is nearly impossible), but if you are comfortable and understand what you are doing, it can be a great solution.

(*) As long as all of the sites are on the same server or have access to the same database server, I guess you don't need to set it up as a multisite. But to make sure there are no differences in core files, I would still recommend it.


Try the Drupal Sync module This module is still in dev but I've tested it with success between 3 websites.

The present module allows synchronizing content among multiple websites. Supported entity types: node and taxonomy, menu items. Many hooks were used during creation of the module. It allows widening synchronization functional by developing additional modules.


First of all, there is no coding needed, or direct database interaction.

Easy solution:

  1. Make a a View of nodes you want to export using https://www.drupal.org/project/views_rss

  2. Set up periodic node import using https://www.drupal.org/project/feeds

  • RSS may not be sufficient if you are having many custom fields.
    – Chakri
    Dec 15, 2014 at 4:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.