Here is the structure of the site I'm setting up. One primary (or default) site with complicated functionality - ubercart, and a host of other feature-providing modules. Four or five child/additional sites with much simpler functionality and independent content. So far this would clearly call for a multisite setup.
Here is the part where it gets tricky - throughout all of the sites I need related content/top content blocks that get node data from all of the sites. Furthermore, for each each node I need a feature that allows it to be 'featured' or 'shared' on any or all of the sites, for the same node to be displayed in the context of whatever site it's being shared on - so that site's unique theme and settings. But not that much content will be shared - only about 10% or so, and the rest of the nodes will remain on and be displayed only on their respective sites.
Thanks to this discussion (http://groups.drupal.org/node/99244) I'm leaning towards a multisite setup. But then this presents new questions and problems. I'm fairly certain that I want my sites to share blocks, views, field types and content types tables, but do I want them to share node tables?
If these sites share node tables, then Drupal needs to know which nodes reside specifically on what sites, and which nodes are featured. If this is the case, then Drupal also needs to be able to figure out what path aliases to use (do I keep path_alias tables separate?). A downside to this method means that all of the administrators on all of the sites will be able to edit any content regardless of what site it is intended for, which sort of drops and functionality of having site-specific content administrators.
If these sites DON'T share node tables (which seems more 'proper'), then I need to configure my views to be pulling data from different databases (or at least different tables), and my 'sharing' functionality suddenly becomes really complicated.
Or I can scratch all of that and use Domain Access - this means (as far as I can tell) that I cannot have varying complexity of Drupal installations and different site configurations, once again I don't know how I would implement 'sharing' functionality, and it seems that there could be a lot of fun and frustrating path alias issues down the road (two or three instances of a node in different places, plus parallel pages?).
I think that sums up my basic concerns and the options that I see that I have. I'd really rather not use Domain Access, especially seeing as how I'll be adding extra sites and developing the sub-sites independently of the default site in the future.
Thank you all in advance.
- Noah
Comments
An alternative to look at. It
An alternative to look at. It doesn't address all of your stated needs, but worth reviewing.
Virtual Site Project
Thanks for the prompt reply!
Thanks for the prompt reply! I hadn't heard of Virtual Sites before, but from some looking into it I can see that it doesn't really fit the requirements, while it also has many of the disadvantages that Domain Access presents. It's really too bad that there isn't a way to combine the core multisite functionality with any of these modules...
There's a reason for that!
There's a reason that you're having trouble nailing down your objective. Take a look at this: Sharing Tables Across Instances.
Good to know.
My objective is pretty nailed down, it's just how on earth I'm going to accomplish it - that's the problem. But that write-up certainly does bring to light some things I overlooked. Which would be that sharing tables between multisites is not awesome. For modules, table-sharing would be an all-or-nothing affair, so that's not a big deal. But I don't want to have to be cloning and re-merging all of my shared tables for each core update.
Please Share Results
Once you've hurdled the solution, please share how you did it. This is something that many of us would like to do.
More food for thought
You could also consider using a mix of the following projects:
Domain Access
Chaos Tool Suite (Including Page Manager, Page Manager Existing Pages, Stylizer, etc.)
Panels (Much more than a layout manager, it puts the content and context in charge of the page, as opposed to the usual practice of putting the page in charge of its content -- simply awesome. Page variants are aware of DA domains, all view modes, etc.)
Panels Everywhere (Totally abandon the obsolete blocks system.)
Display Suite (Specifically for fine-grained configuration of existing and new view modes, especially by DA domains.)
Views (Of course.)
Ok, I guess I'm a radical.
I'd consider going with
I'd consider going with Domain Access in combination with a simple custom module which blocks or redirects folks who are trying to access things you only want to be accessible on the main site. Well… simple for a developer, anyway.
Your main reason for not using DA seems to be that it shares too much, but I think it will be far easier to take an approach like this than trying to mess with shared tables. In reality, I think shared tables is almost always going to be a scary, dangerous, problematic approach.
The Boise Drupal Guy!
Isn't this built into Domain Access?
Disclaimer: I have not yet worked with Domain Access on D6.
I am reasonably certain that the functionality your describing, Garrett, is built into DA on D7. So maybe its already there for D6, obviating the need to develop a custom module.
Core Domain Access can
Core Domain Access can redirect when content which belongs to a certain domain is accessed, yes, but the OP is referring to things which aren't content, such as pages that Ubercart provides and presumably Views. Domain Access can't redirect on those (that I know of).
The Boise Drupal Guy!
Thanks!
All this input has been great.
Radical is good! I ended up using Domain Access after all, despite my previous objections. I decided that while it's not ideal that all of the sites will be structurally so similar, what differences do exist can be handled fairly well by the vast host of Domain Access submodules. Also, thanks to additional research and your input, I decided not to dabble in the mess that is shared tables. I need something that is fairly low maintenance yet flexibly expandable, and duplicating and re-merging tables all the time sounds like a nightmare.
After installing Domain Access and tinkering with it for a while, I realized that it had a lot of functionality that I had overlooked or was unaware of. As it turns out, having site-specific moderators is possible, to a degree. Many of my questions about node paths (including site-specific node access) can be solved by Domain Access core, and for parallel page functionality I installed Domain Path. (http://drupal.org/project/domain_path)
So I'm pretty happy now! If I need to have separate functionality between sites, chances are there's a module for that.
But just one more question: One site has a lot of complicated stuff on it; such as commerce, a comprehensive user system, etc. What should be my concerns be concerning site speed? Will the smaller, simpler sites be affected by all of the functionality of the large site? How well is Domain Access structured to optimize this? Anything I need to know about separate caching settings, or do these even exist?
Thanks!
Your subsites, like all other
Your subsites, like all other Drupal sites, will be slower for having more modules installed, though the extent of it can vary - some modules don't do anything at all unless you directly access a path it provides or something, and others do things every page load (including Domain Access itself, which adds a good deal of code, albeit well-written and generally quick, to Drupal's standard bootstrapping process). It will be up to you to find the proper balance between speed and convenience. But that's nothing new; using Drupal itself is substantially slower than using flat HTML files…
If your site is mostly going to be accessed by anonymous (not logged in) users, there are various caching solutions which you may find useful, from simple ones like Boost to more complex ones (which typically require software other than just Drupal itself to be installed on the server) such as Varnish and XCache.
Does the site which will have the complicated stuff on it also need to share content with the other sites? Perhaps you can spin that one off to its own Drupal instance and use Domain Access for the smaller sites.
The Boise Drupal Guy!
Cool.
The complicated site does need to be the same installation as the others because it serves as a content 'hub'. On the other sites functionality will not be affected by whether the user is anonymous or not (except for the admin user), so can I use this to my advantage? I was hoping that separate site functionality using Domain Access would be a little more decentralized, but then again, I can't really complain. ;) Are you familiar with how "decentralized" Commerce is?
I like the idea of Boost, but I'm still trying to figure out the best way to do this. Is Boost really just an extension to core Drupal caching with HTTP compression as an optional bonus, or is there more to it than that? Why does it only support anonymous page requests? Or, should I let Drupal core do its own thing and enable Apache HTTP compression? How does that compare to using a server-side solution like Varnish? Is the extra Varnish module an addition to Drupal's caching, or does it replace it entirely?
Thanks for putting up with my ignorance. I suppose I've made it obvious that I don't really know how this works. I suppose the real question is, "how do I not shoot myself in the foot?"
I'm a bit confused by what
I'm a bit confused by what you're asking in your first paragraph. What do you mean by "decentralized" here? Also, do you mean Commerce, or Ubercart? (Is this a D6 site or a D7 site?)
At any rate, the idea behind Boost is that, in most cases, the page content for one anonymous user is going to look exactly the same as the page content for any other anonymous user. So what Boost does is save the output of pages as they would be viewed by anonymous users as plain HTML files to a certain directory on your server. You then configure your server daemon to look for pages in that directory first for users that aren't logged in. If the file is there, it's sent back to the user's browser without Drupal ever having to be bootstrapped - the PHP runtime, the database, none of that is ever touched. If the page doesn't exist, however, then Drupal bootstraps and generates it (and Boost saves it for next time).
Drupal (and Boost) can compress files for HTTP compression, but I strongly suggest you don't let it, and instead enable it in the server daemon's configuration. The server should be doing that work, not PHP.
This idea doesn't work for logged in users because once you're logged in, lots of stuff changes depending on who you are - your user info is shown on your user page, you get different menu items depending on your roles, etc. There are other approaches to caching that work for logged-in users, but they tend to get more complex. You should hope that your site becomes popular enough that you have a need for such levels of optimization… But when you're just starting out, I wouldn't worry about it.
The Boise Drupal Guy!
Clarification:
I'm using the Commerce module on D7. I suppose "decentralized" is not the word I'm looking for. I was thinking in the incorrect mindset that DA would make separate sites, rather than one site with different "skins". What I really want to know is how much Commerce will work in the background, and thus slow down the simpler sites. If I understand correctly, DA uses different logins and sessions for different sites, so a user logged in on the site with the store will be logged out in the others, making Boost more practical and hopefully slowing down background requests.
So as for as site speed goes, it seems that the best and easiest route for me would to install Boost, turn off Boost HTTP compression (which uses PHP) and enable it via Apache. Is that what you would recommend?
This site is actually an update of an older D6 site and an integration of several WordPress sites I made a while back, which were not at all optimized for speed so understandably they're very slow. So there is an existing user base, and I'm estimating that usage is going to be about 50% authenticated, not counting crawlers.
It's true that different
It's true that different sites will use different login sessions, though this has more to do with how HTTP and cookies work than Domain Access itself.
At any rate, for the sites that aren't using Commerce, the slow-down will be negligible, though as I said, every module installed on a Drupal site will slow it down negligibly due to its very existence. In this case, I don't think it's something you need to worry about too much.
Yes, I would recommend that. I suggest you don't try to do it until you're just about ready to go live, though. Whenever you're in the middle of development, stuff that caches tends to get in the way.
The Boise Drupal Guy!
Here's an interesting challenge:
Site 1 has subdomains that will not share the user table, but will share modules.
Site 2 has a different domain, but will share the user table with site 1, and has different modules but will share some page content.
They are currently on two different servers, but I can place them on the same machine to share DB etc.
From what I have read I have a hybrid of the functionality between the two approaches.
Multisite or Domain Access? Which one should be used to do the trick here....
Thanks in advance for your tips!