I'm in the process of developing a portal that will consist of a central primary site and sub-sites for each organisation using it.

So far I've been using Joomla to build portals and websites, however I'm worried that its permissions model and scalability are too limited for this project. I have built a prototype using multiple Joomla installs and a frameset to link them together, but it feels like a hack and could be a nightmare to manage. Plus there is no integration between sites.

The requirements are as follows:

  • Users logon to their organisation's sub-portal, so are able to participate in blog/gallery/chat/forums/community features in that portal, but each sub-portal needs to link in to the main portal for main news, articles, global forums, etc. with a shared userbase and single sign on (no need to logon multiple times when moving between sub sites).
  • Admin of content, forums, moderation is for local administrators in each sub-portal, but with overall super admin control of the central (main portal) which has overriding control of each sub-portal.
  • We would need to be able to add features to sub-portals globally, i.e. rolling out updates if necessary, new modules, themes.
  • There will be a directory of sub portals from the main site. Users can either login to their 'local' portal or start from the main portal and visit sub sites.
  • The ability to target advertising/campaigns at global or regional/sub-site levels, if each site is running from a separate subdomain (site1.mainsite.com) should be possible with phpAdsNew.

Civicspace and Drupal hint at the correct community features and feel nice and stable to use, and I suspect would be a lot easier for local admins with limited knowledge to administer than Joomla would be. I'm just unsure whether the multi-site capability is more to keep a shared codebase than have sub sites as part of a bigger site?

Should it work?

Many thanks!
Tom.

Comments

Anonymous’s picture

Is it possible to implement the above using sections, so each sub portal is a section, can I then assign an administrator to that section?

Would organic groups do this? Can I target a URL to open the site within that organic group? Can an organic group manage their group as if it is their own website, with its own theme?

Or can I use a taxonomy tree to create
global site
+-- regional site A
| + site A1
| + site A2
+-- regional site B
| + site B1
| + site B2
etc.
so that there are users that have global administrative rights, regional admins and site admins, where sites include forums and content etc?

mademarest’s picture

bumping this : )

even just a link in the right direction regarding this topic would be appreciated.

thanks

aball’s picture

Shameless Bump.
I need to know this info too.

Mademarest, I'll be testing this out and I'll let you know how it works for me.

I've also tried mando and joomla, both of which don't do the 'team site' functionality both of us want.

--
Regards,
Aaron Ball

jc786’s picture

I need this info too. One thing you might like to consider is assigning user names to each sub site and using that to setup different sub-site pages rather than organic groups.
jc

aball’s picture

michelle’s picture

I have no experience in this area, but suggest you have a look at http://drupal.org/project/domain and see if it will help.

Michelle

--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.

aball’s picture

Hey everyone,

Sorry for the delay in my response. Thanks jc786 for the e-mail about this.

I have been playing with this idea for the last two weeks here and have found some stuff that will help and some stuff that doesn't.

First off, I don't think drupal was designed for use as a multi-tier portal site (obvious by how granular the user and group permissions are not).

Now, down to the muck that everyone loves.
To do what we want, I haven't found very many good ways to do it. Here are some pros and cons of various methods...
1.) Create multiple instances of your drupal install -- One portal per drupal instance.
Pros: Users can only access the portal they belong to.
Only one database is required since drupal database table prefixes can be changed(ie: portal1_drupalUsers, portal2_drupalUsers, etc...)

Cons: Administrators have to register at each drupal instance so they can maintain the site. All custom site settings also have to be transferred somehow to the duplicate instances. Not sure how to do this but I imagine it can't be much harder than copying either database tables or folders and files.

2.) Install lots of modules to manage permissions with various things.
In my drupal install, I have nodeaccess installed to regulate who can see what. The unfortunate downside is that to my knowledge, you can't keep a group of users from seeing a specific page. If they have node view permissions, they can see all of them. The nodeaccess module only works for books, forums, blogs, etc. and not for the root site. That being said, I will outline some of the things I have done to regulate who can get where in my drupal install.
For starters, you can manage Navigation link group permissions so the first thing I did was create an administrator links group for my admins only. I then proceeded to take the admin links that I didn't want the users using the primary navigation group to see. Standard users end up seeing [My blog, Contact, My account, User list, Create content, Log out]. For each new group of people that need to be added, I create a user role and a navigation links group that only that group and the administrators can see so each standard user has two navigation groups, primary navigation and nagivation. The 'home' link refers to the administrator's blog, book, or whatever you want it to refer to but uses nodeaccess to prevent all other users from being able to access that blog/book specifically. This results in a page that other users, given they can guess the url, can get to but cannot access. This page serves as the group's portal.
A little side note regarding navigation: No worries about the administration link in primary navigation as the permissions for that specific link can be managed directly and it does not necissarily have to be removed. I only did it just to make the administrators links nav group look more complete. My link migration still isn't totally complete but is close.

To sum up hopefully shortly,
I created roles for each group of users. Each group has their own set of links (permissions controlled from the block configuration page ...Site Building--> Blocks--> "configure" [to the right of the specific menu block]) that direct to only their pages that only members of that role can access (nodeaccess controls who can see who's blogs/books/etc.).

Does that answer any questions or does it just create confusion? If anyone wants screen shots, let me know and I'll get some of mine online for you guys.

--
Regards,
Aaron Ball

jc786’s picture

I'd like to take you up on your offer of screen shots please. Do you have a working site we could have a look at to see the capabilities.
Thanks again for your input.

aball’s picture

Unfortunately, I have had some problems with the site. I was using it for a project and one of the administrators with me got mad at another member of my admin team and deleted everything on the site, including all other users. I had to hack his account (good ol' SQL MD5 queries) just to get back in. I'm afraid the site is scrapped. I'll see if I can find the time to piece it back together for you. I'll keep you posted.

--
Regards,
Aaron Ball