Drupal sharing content between two websites

I am farmiar with building drupal sites but not sure what the best way to implement this scenario. I have two domain names mydomain.com and mydomain2.com. I need to have a conten type with some fields in. i.e.

ContentType
Field - Title
Field - Body
Field - Picture
Field - Price

I want both sites to use the same data for the custom conten type. So you enter the data on one site and it will be updated on both.

mydomain.com will show the follwoing infromation from the content type.

ContentType
Field - Title
Field - Body
Field - Picture

mydomain2.com will show all the data.开发者_JAVA百科

mydomain.com and mydomain2.com will have diffent look nd feel. And each domain may use some diffent modules. mydomain2.com will be using ubercart and mydomain.com will not.

Would I use mutlisite here and somehow sharte the tables. Use one instance of drupal and do the rest with theming? Use features and context?

Any help would be apreciated.

After doing some research this may be what I need http://drupal.org/project/domain. A case study can be found at http://drupal.org/node/369398.

Still wondering if there are otherways so not acepting this as the answer yet.

You just need to share tables between the sites.

You can share specific tables (best done in logicaly groups) accross Drupal 7 installs by adding something like this to your settings.php file:

$my_db_users = 'drupal_users.shared_';
$my_db_content = 'drupal_content.shared_';

$databases['default']['default'] = array(
    'driver' => 'mysql',
    'database' => 'defaultdatabase',
    'username' => 'databaseuser',
    'password' => 'databasepassword',
    'host' => '127.0.0.1',
    'port' => 3066,
    'prefix' => array(
        'default'   => 'default_', 
        'users'     => $my_db_users,
        'sessions'  => $my_db_users,
        'role'      => $my_db_users,
        'authmap'   => $my_db_users,
        'node' => $my_db_content,                       
        'node_revisions' => $my_db_content,        
        'node_type' => $my_db_content,    
    ),
    'collation' => 'utf8_general_ci',
);

In the above instance, we set variables that point to different databases for certain groups of tables. So in the above example, we need three databases: defaultdatabase, drupal_users, and drupal_content.

Then in the array, we set the default table prefix 'default' => 'default_', and that says: "store all tables, unless otherwise specified, in defaultdatabase and make their table prefix default_." We're also saying: "store all users, sessions, roles, and user-role mappings (authmap) in the database drupal_users with the table prefix shared_." And lastly, we're saying: "store all node types, nodes, and their revisions in the database drupal_content with the table prefix shared_."

With great power comes great responsibility:

You will completely hose your install if you don't keep logical groups of tables together.

What are logical groups of tables? Well, probably any table with the prefix node_ in your current install should probably be moved to the shared database. Most well structured modules (say node_access) will have their table name's prefixed with something logical. Based on your modules, ensure you keep groups of tables in the right place (in the default database for site-specific data, or in another database for shared data.)

Add a little bling:

I did a similar install where the users and roles were shared, but NOT the authmap. To what end?

Well, if you do this, you could have the same users and groups accross a large network of sites while still allowing users different permissions on different sites. On one site you may be an editor, but on another you'd be an author.

The Domain module looks good (although I haven't used it). It may be overkill for your needs.

If you want something very simple you can create a module which sets the global $custom_theme in hook_init() depending on the domain.

For me, if this was a critical portion of the site, I would create a custom module. There are a few guides out there to create node_types through modules. I happen to like this one.

That way, you have a basic structure of your data in a custom table and then can customize the call for displaying the data to either include the price column or not.

Again, some may see this as too much work but if you aren't familiar with Drupal module development, this is a great way to learn. If you are familiar, it should be quick and simple.