I think the way DonCoryondefines DrupalMU is exactly what that brings to one first hears it's name. As WordpressMU provides separate independent blogs base on a common code one could expect that DrupalMU should provide such environment:
Separate independent Blogs based on a common Drupal Installation.
and I think anyone that Google brings here, this group, was been seeking for this usage.
in approval of @DonCoryon I think the solution must be some code that automatically handles the creation of creating subdomain and required tables.
Then the absence of some modules would be felt:
-
A module that provides Theme System:
-- Theme Engine
-- New themes should be applied to all users -
A module that provides the Core Administrator the ability
-- to make Global Changes on all subsites.
-- control modules/themes. -
A module that is all-sites-aware and could provide some stuff according of multiple subsites, such:
-- Latest posts in all blogs, most visited, etc.
-- Taxonomies across the blogs.
-- Relative posts across the blogs
I absorb your attention to the Case Study of OfficeMedium.
their struggle with creating and handling multiple drupal installation is pretty like our challenge here.
Comments
This is very much like what
This is very much like what we've done with the OpenScholar project (http://scholar.iq.harvard.edu/) using Features, Spaces, and OG. Making DrupalMU behave in this manner seems like it might be the best approach.
Great; some questions
well done.
Independent websites for each user.
it would be great if you could submit a case study for your project on drupal.org.
however some questions:
- have you got separated tables behind the scene or everything is handled via the base drupal's tables?
- and in such a way, could users have a, for example, a block of new posts from all users in one of their own page?
Everything is handled via the
Everything is handled via the base tables - no multisite going on here.
Regarding the block of posts from all users, yes, it's possible. You'd set all og posts to be public. On individual groups, you'd filter by the group nid to only display nodes for that group. If you wanted to show everything, you wouldn't do any filtering by the group nid.
in the way using single
in the way using single installation for all blogs some problems like having blocks with contents of all blogs will be solved; but some major problem arise:
1- Security issues: all blogs use the same database connections and a security hole in a module or theme would give the access to whole database to attacker.
2- Backup issues: in this case making a backup of a single blog would be a lot more difficult and surely incomplete. the problem is even more complicated for restoring a backup.
3- Access/Permission issues: permission should be considered for every core and contrib modules; and surly there would be need of writing a lot of modules to handle this. e.g. what User Comment module tries to solve.
4- Multiuser Blogs should be forgotten!: in this way according the number 3, giving a blog administrator the right to create some editor users and manage their permission would seem impossible.
some questions about your system:
- have u provided some themes for users or they can use their own?
- have u provided some predefined content-types and vocabularies or they can create and play with them? if so, what about their visibility to other users?
To address your
To address your concerns:
This is true. However, if you are using a multisite approach with shared core/modules, you have the same risk. Maintainance is trivial though, as you only need to apply a patch once in one location.
This is certainly a valid issue, and I am not sure what the solution would be.
Access is not that big of an issue.
In a Features/Spaces/OG scenario, a blog could absolutely be multi-user. In fact, in OpenScholar, we're already doing this. It's trivial.
Regarding your questions:
thanks for the answers. i was
thanks for the answers.
i was just visiting your website and watching your presentation; it seems you have enough dominance on the security aspects.
about applying the patch that you mentioned, i should say in the "one-core/multiple-databases" way there would be the same. because there would be just one drupal installation and an "all" folder for modules, themes and libraries.
out of the subject, about the problem on backing-up/restoring that you confirmed i think this could be globally solved if:
drupal create some abstract hook that every module have to implement it. e.g. hook_backup_data_hook() and hook_backup_settings_hook()
then it would be possible to ask a module to get a backup of it's related "data" for a specific "role". and many more examples.
maybe it could be done by an API contributed module.
what do yu think?