Deprecated function: implode(): Passing glue string after array is deprecated. Swap the parameters in _gmap_base_js() (line 273 of /home4/monk233/public_html/sites/all/modules/gmap/gmap.module).
Running multiple sites? Consolidate & streamline with Drupal's Domain Access Module
FROM... http://www.astonishdesigns.com/archive-drupal-multi-site.cfm
With Drupal's Domain Access Module, running multiple websites or eCommerce web stores is easy, saving the business owner time and money. But first, let's cover the basics:
Why would I run multiple websites?
Depending on what you are selling, there are compelling reasons to setup and run multiple websites:
Multiple audiences. You might be selling a single product to different groups of customers that demand different messaging or unique packaging; e.g. one site selling to sailors and another site to power-boaters
Experiment. You may want to test a different pricing structure before rolling out the change to your existing audience.
Multiple product uses. You might have a product that offers a different set of benefits when used in different ways; e.g. a weight loss smoothie for dieters and a fiber supplement for people suffering from digestive problems
Co-branding or partnerships. You might have an opportunity to co-brand your product with another to offer a valuable bundled offering
However, a multi-website strategy can be expensive to setup and extremely labor-intensive to manage. For starters, building two separate sites means double the work with almost no economies of scale. Furthermore, you end up with multiple administrative tools to manage content, customers and orders on each site. You might even have to integrate multiple eCommerce stores with your accounting system.
So, what's the solution?
Wouldn't it be nice, if you could run all of your sites with a single set of administrative tools? This would allow your visitors to interact with different websites on the front-end, all feeding into and/or pulling content from a single data source on the back-end. Fortunately, there is a solution:
Drupal has a number of multi-site options, among them is the versatile Domain Access module (DA). With DA, everything is a matter of appearance. To the outside world, it looks as if you have two (or more) completely different sites, but beneath these sites lies one administration back-end. Combined with Ubercart, DA allows you to present completely different sites each with their own branding, products, and content, while all sharing a common platform. With only a single point of integration between your accounting system and your online stores, you'll save a bundle on license fees with integration utilities such as Webgility's QuickBooks connector.
To summarize, Drupal multi-site management includes the following benefits:
One content management system (CMS) to add, edit and review content across multiple sites
A single tool to search engine optimize content housed under many domains
A single eCommerce admin portal to search your customer list or process orders originating from multiple different web stores
Since Drupal is open source, you can manage as many sites as you like without ever paying costly CMS licensing fees
Restricting certain users to certain sites
If you delegate the management of your website to another person, you may need to limit one user's access to a particular site. With Domain Access, you can assign editors to specific sites, which will grant them access to that site alone.
Whether through automation, or in this case, combining multiple site's administration into a single interface, our top priority at Astonish Designs is to help you build a more efficient business. If you'd like to see the Drupal Domain access module in action, be sure to check out April's launch announcement titled "How can Drupal boost your web store to the next level?" featuring Austin, Texas based Acidgone.com and LeanNClean.com.
This post is part of a series about our implementation of Drupal during the redesign of www.museumofplay.org and the launch of the Strong. Read the first post here.
One of the first problems I encountered while working on the Strong websites was how to connect the websites together using Drupal. Domain Access module and Multisite installations are two different approaches. Here's my own struggle with this choice, and why I eventually went with a Multisite installation.
There are six distinct sites that share common features. I used subdomains in development, but we eventually settled on the following six domains:
thestrong.org
museumofplay.org
icheg.org
toyhalloffame.org
libraryandarchivesofplay.org
journalofplay.org
At first glance, the Domain Access module looked very promising. I began implementing it for our sites, but after some struggling, I decided it wouldn't work for us, and switched to a Multisite installation.
Here's why:
1. We like things different
I should point out that our Drupal site was not going to be like most other typical Drupal installations. For example:
Our site is primarily content-driven, with a rigid hierarchy of copy-edited pages
There are no registered users except for administrators
Comments are universally disallowed
Homepages are heavily customized
There is not a lot of "news" or fluid content, except for the Press Room
The Domain Access module is geared towards a more community-distributed content authoring sort of website, which we are not. That may have factored in.
2. Too many menus
What are the primary links? To get around this, I created 6 Primary Links menus for the 6 websites. And with over 150 pages for all the sites, the combination creates a looooong and difficult administration for menus. It's so hard to know which menu you're in, since it's all crammed together in the drop-down list.
I also was looking to use the Node Hierarchy module to build the site structure. This created yet another convoluted menu:
Tedious.
3. Namespace collisions
The sites have lots of content that is named in parallel. For example, several sites have an "About" page, a "Things to See & Do" page, a "Collections" page, and a "Research" page. As content development progressed, this naming actually became more and more parallel. This caused two problems.
Crazy confusing content administration
Granted, Domain Access does have its own admin listings that separate out each domain's content. Which is fortunate, because the default Content administration page becomes nearly unusable. Something like this happens:
Which brings me to my next point.
Depressing Pathauto aliases
My preferred way of generating path aliases was to use Node Hierarchy's tokens, which use the node title. I wanted (and, you could say, "needed") neat and pretty URLs for the site sections. In fact, my themes used the site sections to control colors and tabs. So I wanted URLs like /about-us, /see-do, /collections, /see-do/exhibits, etc.The problem is that Pathauto requires unique aliases. So, if I created www.museumofplay.org/about first, my attempt to create www.icheg.org/about would in fact create www.icheg.org/about-0. Then all the lower level pages in that section would have that ugly 0, like www.icheg.org/about-0/faq.You'll find, actually, that in the example site for Row Eleven Wines, posted as a case study for Domain Access, they got around this by inserting the Domain name into the path. So the About page on the Row Eleven Wines parent site is http://www.rowelevenwines.com/about; the About page for Pinot Noir is http://www.roweleven.com/pinot-noir/about; and, for Stratton Lummis, it is http://www.strattonlummis.com/stratton-lummis/about. This solution wasn't going to work for me.In my attempts to get around this limitation, I went so far as to start writing some mod_rewrite madness that would remove a site id from the beginning of the path. So, www.museumofplay.org/about would redirect you to www.museumofplay.org/1/about, www.icheg.org/about would send you to www.icheg.org/2/about, and so on. But I quickly learned that this was a flawed solution, caused all kinds of problems (paths for the lower level pages were becoming www.icheg.org/0/0/about/faq), and created a house of cards.
4. The house of cards
The paths were the last straw. With 6 big, complex websites being developed, stability became an important factor. All the workarounds I was exploring to meet my requirements were hack-ish solutions, and would have become this monstrous "house of cards", wherein one small change or bump would break ALL the sites. At least with 6 separate websites, if one goes down, 5 are still up, and that's 83% (approximately).
So, I changed my approach and went to a single code base, Multisite installation.
The Multisite Installation
I thought I'd talk here a little bit about what parts of the sites are shared, which led me to the Domain Access module in the first place, and how I worked around them.
There were two primary shared components, a common header and footer, and the "News Crawl" on the homepages.
This header and footer appear on every page of every site:
The HTML and the menus for these components were created by a custom module that I wrote. The defaults were all the correct forms of the links, so simply enabling the module would insert the menus in the correct place. This saved me from adding the same 20 menu items 6 times...
The other shared component was the "News Crawl", a box on the homepage with short news messages (that don't crawl, incidentally).
This I built using a crazy combination of CCK, Views, Views RSS, and Feeds module. It has a central administration page on the parent site, and all sites import items from a feed. (More about this in another post)
Besides that, users and other tables are pulled into a shared database in the settings.php file. Here's a peek at my settings.php file:
Users and roles were shared, but permissions were not. This is because I have different modules/features enabled on different sites, and didn't want to give everyone the same access. This is potentially a major pain, though. Enabling a module on every site requires setting permissions for every site—which is easy to forget.
One last thing—shared search. Since 3 websites became 6, we wanted search to be integrated between sites, so that no content that was rearranged was lost. I ended up resurrecting an abandoned project called Multisite Search to do that part for me.
Shared Sign-on/Single Sign On was looked at and desired, but it was again rather unstable and complicated, threatening another "house of cards" installation, so I abandoned it.
The Verdict
My struggle with this business was wrapped up about 9 months ago. I'm sure that in that time I've learned some more tricks and would have tackled some of these problems differently. I'm also sure that some of these modules have changed and matured since then. But when it came down to it, after evaluating the pros and cons of both approaches, Multisite was the way to go for us.
#Submitted by Dave Reid on Fri, 10/15/2010 - 2:05pm
People should only be seriously evaluating or using Domain module if they are sharing content across sites. If your sites share common features, but not content, multisite is he way to go.
I'm having an issue with a site running Domain Access Module and Feeds Module. I'm suspecting that the two have resulted in the issue we're experiencing.
Our feeds which are being pulled into the sites via the Feeds Module are not updating automatically - with a caveat - You can see the most recent blog posts in the feed if you are logged in as an administrator.
I can't see anything wrong in the configuration for the Feeds Module which would cause the issue.
Do you have any gut feeling as to whether or not the Domain Access module may be contributing to the described behavior.
In my experience with Feeds, I had some issues with cron. Basically, if I ran cron once, it would not pull the newest feeds until the next time. My solution was to run cron twice nightly, one after another, and have "Refresh" set to "as often as possible.
If you can see it when logged in, my first two guesses are 1) check your page caching, or 2) check permissions.
Comments
adminatl
Tue, 10/11/2011 - 23:24
Permalink
Running multiple sites?
Running multiple sites? Consolidate & streamline with Drupal's Domain Access Module
FROM... http://www.astonishdesigns.com/archive-drupal-multi-site.cfm
With Drupal's Domain Access Module, running multiple websites or eCommerce web stores is easy, saving the business owner time and money. But first, let's cover the basics:
Why would I run multiple websites?
Depending on what you are selling, there are compelling reasons to setup and run multiple websites:
However, a multi-website strategy can be expensive to setup and extremely labor-intensive to manage. For starters, building two separate sites means double the work with almost no economies of scale. Furthermore, you end up with multiple administrative tools to manage content, customers and orders on each site. You might even have to integrate multiple eCommerce stores with your accounting system.
So, what's the solution?
Wouldn't it be nice, if you could run all of your sites with a single set of administrative tools? This would allow your visitors to interact with different websites on the front-end, all feeding into and/or pulling content from a single data source on the back-end. Fortunately, there is a solution:
Drupal has a number of multi-site options, among them is the versatile Domain Access module (DA). With DA, everything is a matter of appearance. To the outside world, it looks as if you have two (or more) completely different sites, but beneath these sites lies one administration back-end. Combined with Ubercart, DA allows you to present completely different sites each with their own branding, products, and content, while all sharing a common platform. With only a single point of integration between your accounting system and your online stores, you'll save a bundle on license fees with integration utilities such as Webgility's QuickBooks connector.
To summarize, Drupal multi-site management includes the following benefits:
If you delegate the management of your website to another person, you may need to limit one user's access to a particular site. With Domain Access, you can assign editors to specific sites, which will grant them access to that site alone.
Whether through automation, or in this case, combining multiple site's administration into a single interface, our top priority at Astonish Designs is to help you build a more efficient business. If you'd like to see the Drupal Domain access module in action, be sure to check out April's launch announcement titled "How can Drupal boost your web store to the next level?" featuring Austin, Texas based Acidgone.com and LeanNClean.com.
adminatl
Tue, 10/11/2011 - 23:41
Permalink
Domain Access vs. Multisite
Drupal Redesign: Domain Access vs. Multisite
This post is part of a series about our implementation of Drupal during the redesign of www.museumofplay.org and the launch of the Strong.
Read the first post here.
One of the first problems I encountered while working on the Strong websites was how to connect the websites together using Drupal. Domain Access module and Multisite installations are two different approaches. Here's my own struggle with this choice, and why I eventually went with a Multisite installation.
There are six distinct sites that share common features. I used subdomains in development, but we eventually settled on the following six domains:
At first glance, the Domain Access module looked very promising. I began implementing it for our sites, but after some struggling, I decided it wouldn't work for us, and switched to a Multisite installation.
Here's why:
1. We like things different
I should point out that our Drupal site was not going to be like most other typical Drupal installations. For example:
The Domain Access module is geared towards a more community-distributed content authoring sort of website, which we are not. That may have factored in.
2. Too many menus
What are the primary links? To get around this, I created 6 Primary Links menus for the 6 websites. And with over 150 pages for all the sites, the combination creates a looooong and difficult administration for menus. It's so hard to know which menu you're in, since it's all crammed together in the drop-down list.
I also was looking to use the Node Hierarchy module to build the site structure. This created yet another convoluted menu:
Tedious.
3. Namespace collisions
The sites have lots of content that is named in parallel. For example, several sites have an "About" page, a "Things to See & Do" page, a "Collections" page, and a "Research" page. As content development progressed, this naming actually became more and more parallel. This caused two problems.
Granted, Domain Access does have its own admin listings that separate out each domain's content. Which is fortunate, because the default Content administration page becomes nearly unusable. Something like this happens:
Which brings me to my next point.
My preferred way of generating path aliases was to use Node Hierarchy's tokens, which use the node title. I wanted (and, you could say, "needed") neat and pretty URLs for the site sections. In fact, my themes used the site sections to control colors and tabs. So I wanted URLs like /about-us, /see-do, /collections, /see-do/exhibits, etc.The problem is that Pathauto requires unique aliases. So, if I created www.museumofplay.org/about first, my attempt to create www.icheg.org/about would in fact create www.icheg.org/about-0. Then all the lower level pages in that section would have that ugly 0, like www.icheg.org/about-0/faq.You'll find, actually, that in the example site for Row Eleven Wines, posted as a case study for Domain Access, they got around this by inserting the Domain name into the path. So the About page on the Row Eleven Wines parent site is http://www.rowelevenwines.com/about; the About page for Pinot Noir is http://www.roweleven.com/pinot-noir/about; and, for Stratton Lummis, it is http://www.strattonlummis.com/stratton-lummis/about. This solution wasn't going to work for me.In my attempts to get around this limitation, I went so far as to start writing some mod_rewrite madness that would remove a site id from the beginning of the path. So, www.museumofplay.org/about would redirect you to www.museumofplay.org/1/about, www.icheg.org/about would send you to www.icheg.org/2/about, and so on. But I quickly learned that this was a flawed solution, caused all kinds of problems (paths for the lower level pages were becoming www.icheg.org/0/0/about/faq), and created a house of cards.
4. The house of cards
The paths were the last straw. With 6 big, complex websites being developed, stability became an important factor. All the workarounds I was exploring to meet my requirements were hack-ish solutions, and would have become this monstrous "house of cards", wherein one small change or bump would break ALL the sites. At least with 6 separate websites, if one goes down, 5 are still up, and that's 83% (approximately).
So, I changed my approach and went to a single code base, Multisite installation.
The Multisite Installation
I thought I'd talk here a little bit about what parts of the sites are shared, which led me to the Domain Access module in the first place, and how I worked around them.
There were two primary shared components, a common header and footer, and the "News Crawl" on the homepages.
This header and footer appear on every page of every site:
The HTML and the menus for these components were created by a custom module that I wrote. The defaults were all the correct forms of the links, so simply enabling the module would insert the menus in the correct place. This saved me from adding the same 20 menu items 6 times...
The other shared component was the "News Crawl", a box on the homepage with short news messages (that don't crawl, incidentally).
This I built using a crazy combination of CCK, Views, Views RSS, and Feeds module. It has a central administration page on the parent site, and all sites import items from a feed. (More about this in another post)
Besides that, users and other tables are pulled into a shared database in the settings.php file. Here's a peek at my settings.php file:
$db_prefix=array('default'=>'','users'=>'drupal_shared.','role'=>'drupal_shared.','users_roles'=>'drupal_shared.','sessions'=>'drupal_shared.','sequences'=>'drupal_shared.','workflow'=>'drupal_shared.','workflows'=>'drupal_shared.','workflow_access'=>'drupal_shared.','workflow_states'=>'drupal_shared.','workflow_transitions'=>'drupal_shared.','multisite_search_dataset'=>'drupal_shared.','multisite_search_index'=>'drupal_shared.','multisite_search_sites'=>'drupal_shared.','multisite_search_total'=>'drupal_shared.',);Users and roles were shared, but permissions were not. This is because I have different modules/features enabled on different sites, and didn't want to give everyone the same access. This is potentially a major pain, though. Enabling a module on every site requires setting permissions for every site—which is easy to forget.
One last thing—shared search. Since 3 websites became 6, we wanted search to be integrated between sites, so that no content that was rearranged was lost. I ended up resurrecting an abandoned project called Multisite Search to do that part for me.
Shared Sign-on/Single Sign On was looked at and desired, but it was again rather unstable and complicated, threatening another "house of cards" installation, so I abandoned it.
The Verdict
My struggle with this business was wrapped up about 9 months ago. I'm sure that in that time I've learned some more tricks and would have tackled some of these problems differently. I'm also sure that some of these modules have changed and matured since then. But when it came down to it, after evaluating the pros and cons of both approaches, Multisite was the way to go for us.
Next post: Themes and sub-themes
Comments
People should only be seriously evaluating or using Domain module if they are sharing content across sites. If your sites share common features, but not content, multisite is he way to go.
Yes.
OMG, Dave Reid commented on my blog post, and I totally dismissed it! I met Dave at DrupalCon, he's like my hero! You're the man Dave, I'm sorry!
I'm having an issue with a site running Domain Access Module and Feeds Module. I'm suspecting that the two have resulted in the issue we're experiencing.
Our feeds which are being pulled into the sites via the Feeds Module are not updating automatically - with a caveat - You can see the most recent blog posts in the feed if you are logged in as an administrator.
I can't see anything wrong in the configuration for the Feeds Module which would cause the issue.
Do you have any gut feeling as to whether or not the Domain Access module may be contributing to the described behavior.
Thanks,
jm
In my experience with Feeds, I had some issues with cron. Basically, if I ran cron once, it would not pull the newest feeds until the next time. My solution was to run cron twice nightly, one after another, and have "Refresh" set to "as often as possible.
If you can see it when logged in, my first two guesses are 1) check your page caching, or 2) check permissions.