3

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 '12 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 '12 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. – ted.strauss Oct 15 '12 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 '14 at 8:33
1

Check out the deploy module. It is designed to allow developers to easily stage Drupal content from one site to another. Deploy automatically manages dependencies between objects (like node references). It is designed to have a rich API which can be easily extended to be used in a variety of situations.

  • The Drupal 7 version is still under development, but it might be worth the shot. I'll try and post the results, thanks! – jpatiaga Jun 6 '12 at 20:06
1

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.

0

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.

0

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 '14 at 4:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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