By lodge_t on

I am currently running a number of drupal sites (virtual domains using a common code base, and individual databases). I now want to create an administration site, whereby I can create nodes that will be seen by all of my drupal sites.

The way I thought about doing this is to use drupal's database prefixing functionality, and creating a new module 'sharednode', and an associated shared 'sharednode' database, that can be accessed by all of my sites.

If I do this then I can then create new sharednode modules which are specifically intended to be run across multiple sites. The problem is that, if sharednodes are then to have the same functionality as standard nodes, then some modification must be made to the core files. I'm not too keen on doing this, as it will make upgrading to new versions a nightmare.

Has anyone else ever tried creating multiple sites, each with their own standard drupal local database, but which also access one or more shared databases? Has anyone gone further to develop node modules that are specifically designed to be shared across multiple sites?

I know that it is possible to share information using RSS, but what I'm talking about is creating new nodes (such as polls, blogs etc etc) that behave in the same way as normal nodes, but which are shared across multiple sites.

Comments

marqpdx’s picture

marqpdx commented

I'm looking for exactly the same thing. Did you make any progress on this yet?
Thanks,
mark

moshe weitzman’s picture

moshe weitzman commented

this gets hard if your shared content must use the node api. if you stay away from nodes, then you can esily share dedicated tables like a new sharedcontent table.

if you must share content types which use the node api (blog, poll, etc.), then you are going to have to share the node and sequences tables. at that point, you are very close to running a 'two sites same database' configuration.

basically, this is hard without lots of knowledge of drupal guts. research the code or hire someone to do that.

lodge_t’s picture

lodge_t commented

Moshe is right. I went ahead and implemented it - and got it working - but I have to say that it meant the creation of a large number of new 'shared' modules and 'shared' databases. It's one thing to get nodes displayed across multiple sites - and it's another to then allow them to behave as a normal node would (ie, to allow 'shared' comments to be added, and 'shared' taxonomies and so on.) It basically meant that I was duplicating vast tracts or core functionality, and the solution is not nearly elegant enough to provide the simplicity that most people clearly want. I'd be very interested in other ideas. I still think this is a worthwhile project, but I'm not convinced that the 'sharednode' concept is the best way forward.....

pamphile’s picture

pamphile commented

1

pamphile’s picture

pamphile commented

That above post with a number #1 is a edited post I made. Everytime I tries to edit it, a 1 was displayed instead of my post - weird

pamphile’s picture

pamphile commented

I know exactly what your talking about. Before using Drupal, I built something similar using my own CMS system.

I did two things:
1. Each node had a domain associated with . When the node is displayed it's associated domain is used.

2. Each category id (taxomony term in drupal) had a dedicated domain assocated with it. When the nodes within this category are displated it's associated category domain is used. ( you could also allow the node domain to override the cateogy domain)

THIS IS VERY IMPORTANT
1. Identify a starting category ID or ( Taxomony Term in drupal ). Like this you avoid spamming the search engins.

That's mostly it. This really works !!!

I could implement this in Drupal if I understood how it worked. I already have it working on my own personal CMS. I beleive it would be much better on Drupal though. Custom CMS systems tend to be demanding on time and brain power. Why don't we do this together in Drupal ?

To get started with this in Drupal we should
1. Create a domain field within the node table
2. Create a domain field within the main taxonomy table

Then
1. Whenever a node is used displayed, use the nodes associated domain. If no domain is associated with the node use the default domain.

2. Whenever taxonomy term is browsed, use the domain that is associated with the taxonomy term.

3. Identify the starting taxonomy term for each domain.

* A bit or database normalization would also help

http://scriptdiary.com - http://01wholesale.com - http://businessletters.com - http://01classifieds.com

pamphile’s picture

pamphile commented

It would be great if this thread was promoted to the frontpage. I am sure many Drupalers would want adding their input.

marqpdx’s picture

marqpdx commented

I second that.
Great discussion. (plus, it would be cool if users could vote on promoting to front page, with thresholds... I know i know, i'll work on it at 3:45 tomorrow morning.)
mark

marqpdx’s picture

marqpdx commented

I'm not sure using the Taxonomy is the best way. I think "domains" need to be inclusive, so that top level domains include all content, with children domains more selectively filtered.

I put down a few thoughts on another node, which you might want to check out here.

Thanks,
mark

pamphile’s picture

pamphile commented

Someone gave a reply to your idea, it can be done using the present Drupal modules.
http://drupal.org/node/14816#comment-24565

What I described can't be done yet. We need a true separation of content on a domain by domain basis without installing multiple drupals and databases...

http://01wholesale.com

adamrice’s picture

adamrice commented

This is exactly what RSS was originally invented for. Drupal, of course, can produce RSS feeds (and has several modules that extend its RSS handling) and the node aggregator module lets you import these feeds as nodes.

You wouldn't be treating the imported content as if it were in the same form as the original, and that would get tricky, too: if you were syndicating a poll, should each receiving site tabulate poll results separately, or should they be tabulated together?

Adam Rice

pamphile’s picture

pamphile commented

RSS is an interesting option but not the final answer.

You don't want to maintain multiple websites and multiple codebases.

The goal is to reduce your workload while launching new websites from one codebase. OR another way to say it is, you want to offer multiple websites from one codebase.

Here are some desirables:

1. It should not be time consuming to maintain. Just park a domain on the root website, and assign the domain to a category and select a template.

2. It should be easy to manage. ( Once a category is assigned a category, all content within that category should be branded with the new domain. )
Old pages from the category should not forward to the related area under the new domain.

3, It should not spam the search engins with duplicate, this won't happen since the categories content will now be hosted on a new domain

http://scriptdiary.com - http://01wholesale.com - http://businessletters.com -
http://scriptmigration.com