Hello, Is it possible to run a large university site with many themes and the roles of different content editors on a single installation? We are in the early stages of recommending a CMS for our university and this has been a question that has been raised multiple times with no clear answer about Drupal. I am seeking feedback, configurations and best practices on transitioning university wide web pages to a common Drupal installation. I am aware that there will be limitations to this type of setup, but resources are at a minimum and as much standardization as possible is one of the selection committees goals. Current pages are 90% all static html and in many cases are on different webservers around campus. From what I have witnessed most Universities who have employed Drupal as their platform of choice have many actual installations or multisite installations. Are there schools who have already or are planning to implement a single installation of Drupal for all of their core public facing webpages? What would be the best way to manage the many themes needed for subpages/departments and allocate permissions to these groups for restricted content editing? How would we allocate specific menu editing abilities to specific roles? We are transitioning to Desire 2 Learn as our LMS so these types of classroom features are not important to us currently. I am more specifically talking about the homepage, major landing pages, admissions, events, academic offices, administrative offices and possibly the most difficult part to implement, college specific websites.
If you have an opinion about this topic I would really enjoy your feedback and input. Feel free to contact me through my profile and I would be happy to talk with you via email or phone.
Comments
taxonomy, sections, and taxonomy access control
Bentley University uses those three modules to manage any number or sites with separate themes and users. Taxonomy terms identify the sub-sites, sections uses taxonomy to assign a theme, and TAC controls permissions based on terms. I've just made it sound a lot easier than it is..
Aegir
You might look at running Aegir for something like this. Bascially it's separate installs of Drupal administered from a central system.. And it allows you to roll out new installs and update current installs very easily.
You might be better off doing it this way then using multisite.
Eric
Eric Aitala - ema13@psu.edu - f1m@f1m.com - @aitala
www.essp.psu.edu - www.f1m.com
Context & Spaces
I think you might also want to look into the context- and spaces-module - these are used for separating site sections with openatrium and openscholar.
Links:
http://drupal.org/project/context
http://drupal.org/project/spaces
http://openscholar.harvard.edu/home
http://openatrium.com/
We use a multi-site install.
We use a multi-site install. If you were going with a single install then you'd want to use Organic Groups most likely. There are modules which base menu editing capability (e.g., http://drupal.org/project/ctm) and theme switching (http://drupal.org/project/role_theme_switcher) based on role.
I don't see the benefit of a single install over a multisite install though.
Also, you may want to also try this question in the Higher Education group.
Drupal evangelist.
www.CoderintheRye.com
organic groups
Our situation seems very similar to yours. I am the university webmaster and have no additional staff. Up to this point, it has been the wild wild west for department sites. Some have nothing, others have hand coded html sites. Addresses are wildly different as are themes. Our president commissioned a Web Redesign Action Team to unify graphic look and navigational structure of the university site. ADA accessibility was also a HUGE concern. I took it upon myself to install a CMS as I was bombarded with content updates daily. At this stage we are defining the first tier as university homepage, audience partition tabs, university offices, and colleges. academic departments have been offered the same service, but it has not been required yet.
We are currently in the development phase of a University Wide Migration to a Single Drupal Site. We hope to soft launch in November. We are using a single Drupal installation and the Organic Groups module to give each area their own "sub-site". Each group can have their own theme and content manager. Each OG also gets their own menu.
I had looked into multi-sites, Aegir, and the domain module to accomplish this, but they seemed overly complicated to me. The organic groups solution seemed the simplest in terms of setup and config.
We do not have very many roles yet, mainly an academic group manager, and non-academic groups manager. I have created several custom content types. Some are available to both roles, and some only to one. With OG, your can set permissions so that the group manager can only create/edit/delete their content. This keeps them from getting into any other group's content.
As far as themes go, each OG can have their own theme. For our initial phase of this project, all groups are using the same theme. Once the content is all moved over and I am freed up, I will work to create additional themes for each OG.
So far, we have not found any issues with this configuration. The last few weeks we have been pushing the content creators from each area to get their content in the new site. The site has remained responsive and the database has not grown to an unmanageable size. These are the 2 concerns I've had with going this route, but I have been unable to find anyone in the community who could confirm or deny my worries.
I would be glad to elaborate and/or discuss this further with anyone interested.
Thanks for the great input so far - questions
@chrisakeley, Thanks, the Bentley site looks super nice! Some good interface work going on there on the homepage for sure. Thanks for the suggestion of modules. I have looked at all three in the past for minor projects but have only used Taxonomy. I will work to explore those further. Can you tell me if the Bentley site is all a single install of Drupal? If not, where were separate or multisite installs used and why?
@aitala, Thanks I have seen Aegir mentioned in discussions a few times now. Looks like it is still in development and will be Drupal 7. Our question of Drupal 6 or 7 has not been fully addressed yet. The following link is the most comprehensive current information I could find on the Aegir. Are people using Aegir 6 in production environments now somehow?
http://developmentseed.org/blog/2010/sep/02/aegir-10-release-drupal-7-ea...
@comprojects, Thanks, Ill check those out. I am only slightly familiar with Context and what it does.
@nowarninglabel, Thanks for the input. I am not convinced a single install is the best choice but is what some of the team are most comfortable with due to limited server admin resources and the administration of multisite or multiple sites, maybe this is misguided?. I wonder if we will spend more time dealing with limitations of a single install than using multisite? OG has been at the top of my list as far as potential solutions. Ill check out the two related modules you mentioned, thank you. Thanks for the suggestion of the Higher Ed Group, I was not aware of it. I will let this stew here for a few and then post over there.
@mungai, Thank you for sharing your situation, it does indeed sound similar. I sent you an email through the contact form. The question of the database size of a single install has not be explored yet from our perspective. Your mention of it does give me pause, is this a concern? Is anyone running a very large university site from a single database that has grown to incorporate all the pieces I mentioned? Will speed become an issue in an installation of this type?
Thank again for all for the helpful feedback so far. :)
D7 vs D6
As for 6 vs 7, I'm not looking into transitioning / building D7 sites for another 8 months or so. For non-university sites / systems I'd probably use it sooner but D7 is still way too new (or will be) when you'd probably get this site / system off the ground.
I've used multisite's to pull off tons of sites though I'd probably recommend checking out taxonomy access / theme / themekey or OG or Domain (one of those 3 setups) for a large site that looks different in different places but is essentially still "the same" "one" site.
Some one you might want to check out the work of is Amherst -- http://groups.drupal.org/node/10231 . They are the one site do it all kind of setup with lots of theme differences and what not. Last I checked they had hacked core as part of their user groups / access control systems but still more then worth looking at.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
Austin Peay State University
Austin Peay State University (www.apsu.edu) is using a single large site that is subdivided for different departments via taxonomy and Tac Lite (http://drupal.org/project/tac_lite). We use the LDAP Integration module to integrate with our Active Directory system for authentication. We've been pretty happy with this so far, but it may not work for every school.
Mark W. Jarrell
Online Applications Developer
Richland Library
http://www.richlandlibrary.com
http://fleetthought.com
Twitter: attheshow
Drupal 7 vs 6 - future proofing
@btopro, Thanks for chiming in, I have followed many of your posts and information on the elearning PSU site and Drupal.org. Great stuff, thanks for sharing so much. I assume our timeline is going to be too aggressive to really consider Drupal 7. With that said, is one of the three methods you mentioned more future proof than others do you think?
Most likely too agressive for D7
thanks, Jing + FMS = 5-10 minute tutorial production time :p. Here's the decision tree as I see it:
Single domain / site (university.edu) and "other sites" living at university.edu/department1 then I'd go with Organic Groups or ThemeKey (probably OG).
If you're looking at art.university.edu, math.university.edu and things like that then Domain Access might be a good way to go.
Personally, we've gone with a shared-table multi-site structure. The shared-table approach isn't really necessary but has helped us unify logins. It's probably "the most future proof" only because it's entirely managed by core drupal technologies which are going to be supported in 7 and beyond. This isn't to say that domain access and OG will live on "forever" but I operate in an ultra paranoid decision tree so I try to stick to core as my base architecture as strictly as possible. https://elms.psu.edu/ has a lot of the philosophy behind our instruction / system architecture decisions.
There's nothing that's truly future proof but D6 is an incredibly robust platform and will be for several years. It'll also be widely supported in active development most likely a few years after D8 lands (which you're looking at probably 2-3 years away if I had to totally guess). So your site based on any D6 technology will probably be "current" and "supported" for at least 4 years which is much longer then most people keep a web technology the same anyway :p. These are the arguments I'm working off of at least.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
APSU
@attheshow, Thanks for the input, I have looked at your site in the past also. Great looking site. Its great to know that your site is running on a single instance. I really like the consistency of your menu system. Are you granting access to specific roles to edit the sub menus in some way? I have LDAP Integration successfully working on a small site we have been running, it has been working very well. Are there instances where you are running multisite or separate sites that appear to be part of the main site for any reason?
Workflow and TAC or OG
So after reading the following page this morning for another site I am working on I am concerned an assumption I have made may not be correct.
http://drupal.org/node/270000
Will the workflow module work with TAC or OG? We would like to control workflow and approval processes on many areas of the site. The aforementioned page makes me believe some of these modules may not play nice. Is anyone using them together with success?
A few things to consider
You've gotten some great feedback here - a couple additional things to consider:
FunnyMonkey
good points...
those are some good points, Bill. A question we are having though, and perhaps this is what you and others are referring to in terms of Aegir, is the hassle of multisite upkeep. I will check out Aegir, though the first sight of it is hard to follow, but does that help simplify multisite updating and management? Have others used it? Is it complicated as one user mentioned, or, is it so powerful that it's worth muscling through?
We see the multisite updating issue as being a major drawback to scalability...
g
ggevalt
www.youngwritersproject.org
No multisite for APSU domain
@paranormals No, there's no multisite process going on for the apsu.edu domain name. It's all one.
Yes, for the left sidebar menus, they're all actually individual menu blocks. They only appear based on the path that you're viewing on the site. For instance, if you're on http://www.apsu.edu/information-technology, it only shows the menu block for the Information Technology dept. Editorial control for each menu is controlled by using the "Menu Admin per Menu" module (http://drupal.org/project/menu_admin_per_menu).
Mark W. Jarrell
Online Applications Developer
Richland Library
http://www.richlandlibrary.com
http://fleetthought.com
Twitter: attheshow
Aegir, D6vD7, menus, workflow, urls
As far as Aegir goes, I looked into that, but as I was a complete noob at the time, I could not figure out how to get it to work. It seemed complicated and was outside of my comfort zone. Time constraints dictated that I move along without it. I may try to revisit Aegir later on.
D6 should be stable and supported for some time, so that was not really a concern for us. Again time constraints pushed us to move ahead. If I were to begin our redesign next year, I would consider D7 but I'm a little concerned it won't be as hardened and robust as D6 for some time. I have a few personal experimental sites that I run on D7, but nothing enterprise.
When using OG, each group can have a menu, and each group manager can control that menu. I assign each menu to a block in the template and tell it to only show on listed pages:
OG_subsite_name
OG_subsite_name/*
So far this has worked exactly as we have needed. I control the themes of the menus so that navigation remains consistent throughout the site.
For our workflow, we are working with the model that each OG manager has authority and control to change anything under their site. I approve each manager and share with them some Drupal and accessibility best practices that they sign off on. Previously, we used a model where all content had to go through one office to be approved. This led to a several month backlog and content expiring before it was approved. This led to a movement to post first and touch up grammar later.
Once our site fully launches, our Web Redesign Action Team will transition to a Web Content Review team and will monitor and periodically go over sites. This is mainly to ensure that our marketing message and image is consistent, to ensure correct factual data is presented, and to ensure that sites are kept up to date and content refreshed as to not get stale. Our university (FTE @9000) is not so large that this should remain manageable (I hope).
I cannot comment on if the workflow module will work with OG as it is not necessary in our configuration. Based on the article @paranormals posted, it would seem there are issues.
All of our preferred short urls are in the format www.domain.edu/department. We will use some apache and DNS tricks to keep in print and bookmarked old urls working. Again, in our background, there was a wild west mentality where every site did their own thing. Some were department.domain.edu, some www.department.domain.edu and many other variations. There was a movement to pick a simple standard and keep it for the redesign.
@attheshow, I really like the overall theme and menu theme on http://www.apsu.edu/information-technology.
@paranormals, as you have probably noticed by now, there are usually 10 different ways to address every Drupal question! This frightened me a bit at first, but now I see I am able to find a solution that fits into my scenario. And you can always code your own if you don't like the others.
Also working on a University website
I'm working to build a university website for one of our schools which will allow researchers and professors to create their own custom website. It should also allow those researchers who are part of a projects to be able to build and maintain project websites. For personal websites, it was a pretty easy setup since Drupal already has the settings to allow a user to only edit their own pages. For projects, it's a different story...
We have around 150 projects, each can have 1-15 different users who are a part of that project and who should be able to update pages for that project website when needed. I looked into the Taxonomy Access Control module and it seems like a great fit. I was able to create a role for a project and assign privs using TAC. What's nice is that you only have to deal with one content type. So far, tests are running fine, but I only have created about 10 projects (thus, 10 roles). Do you think this solution I'm working on is fine for my needs? What happens when I start having about 150 roles??? Will performance be an issue?
Any direction would be helpful!
alternatives could include OG
@ghosty - I don't know enough about the nodes you are allowing them to make but on the surface, organic groups is often used to partition the site into sections where the manager of the group controls the content. Each group uses the same content types. You don't need a role for each project, just a group. The group can be open to the public making it seamless or you can make it private. groups.drupal.org is "seamless." If you don't like how OG layouts out its group homepage, you can look at using Panels.
If this approach sounds helpful, this post might help u get started - http://groups.idcminnovations.com/articles/setting-drupal-organic-groups
OR you can get a jump start by downing Drupal Commons and play around with that. DC has some nice added features that you don't get downloading and building your own site. Download it here http://acquia.com/products-services/drupal-commons
Thanks for the web page, that
Thanks for the web page, that seemed to help me understand OG much better. I'm playing with it right now and so far I think that it may work for what we need. I may have more questions, but for now, this is a great start!
Glad it was helpful ;-)
Glad it was helpful ;-)
Do you know how many organic
Do you know how many organic groups you could have? Is having 300-500 for instance too much?
Also, is there a way to hide the Lists page which shows all the groups? I wouldn't mind having the webmaster see this list, but for a basic user or anonymous, they don't need to see it.
Finally, is there a way to hide the group home page? I know I can probably hide these pages using hook_menu, but wanted to know if there was a setting or some other way to hide them instead.
By the way, this looks like a winner!
Do you know how many organic
Yes, as long as you have a server that level of traffic - assuming that are all active at once. Also, if you enable the notification/subscription option, you want a server that can handle that traffic as well. There is a blog on the groups.idcminnovations.com site about setting this up as well.
There are several options. 1. if you don't want the list, when you create the group, don't check the box to show in the list. 2. if you want the list but don't want people looking at it, don't show the block or menu link that goes to the list. 3. if you want to be sure no one sees it but a specific role, go the view that creates the list and change the access settings (u will see it in the basic settings list)
Hide the group homepage? I am not sure I understand. You mean you don't want visitors to the site to see the group unless they are a member of the group? Or do you mean you don't want to show the mission or the list of nodes that show under the mission? Why would you create a group and not want someone to see it.
Before you start custom coding something with hook_menu, plan what you need and ensure that Drupal and/or OG doesn't already have a solution. Most of what you see is created using Views. Look at ALL the settings available in groups - the number of configurations is quite large.
Although I can check the box
Although I can check the box to not show the group in the list, it still remains that there is a list. This list would only be beneficial to the developers of the website since we are aiming to make each group a microsite. Members of each group do not need to know or see that list. That's why I would like to have all groups visible in that list, but only viewable to let's say a role I create for developers/admins. That's why I was thinking I might need to use hook_menu.
For the group homepage, I see that every group can create a post (node) and also that every group has it's own home page. I would like to have visitors only see the group posts since it is those posts which will represent the pages of the microsite. I am using the OG Menu module which will allow group members to construct a menu with our theme to help visitors navigate the site. The group homepage is just a place where you see the mission and list of all the nodes, but in our view, that page does not need to be seen by visitors. The group homepage reminds us of a blog which is not what we intend to use nodes in OG for.
Note: I forgot to add that for the list of groups, a link to that list shows up in the breadcrumbs for a site. That's another thing I would like to hide.
Multisite
Hello, I wanted to post a follow up to this thread. Thanks so much for all of the valuable input that was contributed. After much research and debate based on this discussion it looks like we are heading towards a multisite install. Due to our very diverse set of users who will need different types of access we do not believe a single site can accommodate our needs without great difficulty. We want to make sure our product can scale as needed and multisite seems to be the logical solution. The comments about multisite being part of core and the most future proof also make a strong case for this path of development.
FYI.. Im going to post a thread over in Higher Education Group about utilizing external resources at a university (Acquia, Lullabot, etc..) if anyone has an opinion on that subject matter.
http://groups.drupal.org/higher-education
Thanks again.
Mark