Help with implementing drupal for a large organization
I'm looking for any assistance, suggestions or contact information that might help me direct the implementation of Drupal as a University-wide web solution. Please read below to see more details about what I'm looking for. Any information would be greatly appreciated. _*About Us*_ The University of Delaware (UD), located in Newark, Delaware, is now committed to rolling out Drupal as the primary web solution for the entire University. We currently have 7 colleges, 50 research centers, 23 intercollegiate athletic programs, numerous student organizations, and a long list of units that currently manage their current static html sites. _*The Plan*_ We plan to offer drupal-based web hosting to any and all units, colleges, and organizations within the University community. Let's just say that we expect to run drupal as a multiple "multi-site" installs and are expecting 100+ sites. At this point the plan is to run a production box with a mirrored development box for site modifications. We are building the servers on the UNIX environment using Drupal 6. We need help in best practices for our user community. More explicitly: * We expect to set up a standard drupal install and add UD "vetted" modules. As new modules or updates become available, we expect that we will need to add these to the "core" set of modules that we will make available to all sites. (ie. sites/all/modules folder) Any suggestions on how to update modules and theme for a large number of sites? * To start with, we see three drupal core installs: the first for low-profile or non-aggressive site development, the second for moderate development, and the third for aggressive development. The thought behind this is to reduce the number of sites that we need to review for conflicts with newly added or modified modules. Any thoughts on this? * We are trying to develop a policy on user access to the file system. We understand that there are users that won't want access, but there will also be others that want to tweak modules and themeing directories. Are there any suggestions on best practices for allowing our users access to the files system? My systems folks do not want to have the nightmare of granting access, but as a developer myself, I think this is a must. * URL domains are also an issue. We have some sites that are subdomains (mysite.udel.edu), other sites are directory-based sites under the hosted domain (udel.edu/mysite). Udel.edu is running on another server. I feel confident that we can run the subdomains without much a problem, however, I am interested to see if there is a suggestion on what to do with the latter issue of udel.edu/mysite. I don't want to rewrite the URL or redirect. Any thoughts or comments on this? Please note, I recently joined the Drupal in Ed group and plan to submit these questions more explicitly to them. I am also aware of the case studies on http://groups.drupal.org/taxonomy/term/4339. Sorry for the length of the message, please contact me if you have questions, comments, or suggestions. Thanks! -Tina ********************************** Tina Callahan 014 Smith Hall, Newark, DE 19716 University of Delaware 302-831-1982 tina.callahan@udel.edu **********************************
Tina, I'm just making a small comment here that certainly doesn't respond at all to the breadth of your question... I think you guys might be a great case for using the Acquia distribution, and likely some of their other services. It would bring some stability and coherence to what could be an incredibly complex set of installations. I don't mean to be glib or suggest this is an all-encompassing solution in any way, but it seems like just vetting modules on it's own could use up a bunch of your resources and the Acquia installation does that for you. That's all I have time for now, Good luck. It's awesome that UD is going Drupal! Shai Content2zero <http://content2zero.com> On Wed, Dec 3, 2008 at 7:57 PM, Tina Callahan <tinytina@udel.edu> wrote:
I'm looking for any assistance, suggestions or contact information that might help me direct the implementation of Drupal as a University-wide web solution. Please read below to see more details about what I'm looking for. Any information would be greatly appreciated.
*About Us* The University of Delaware (UD), located in Newark, Delaware, is now committed to rolling out Drupal as the primary web solution for the entire University. We currently have 7 colleges, 50 research centers, 23 intercollegiate athletic programs, numerous student organizations, and a long list of units that currently manage their current static html sites.
*The Plan* We plan to offer drupal-based web hosting to any and all units, colleges, and organizations within the University community. Let's just say that we expect to run drupal as a multiple "multi-site" installs and are expecting 100+ sites.
At this point the plan is to run a production box with a mirrored development box for site modifications. We are building the servers on the UNIX environment using Drupal 6.
We need help in best practices for our user community. More explicitly:
- We expect to set up a standard drupal install and add UD "vetted" modules. As new modules or updates become available, we expect that we will need to add these to the "core" set of modules that we will make available to all sites. (ie. sites/all/modules folder) Any suggestions on how to update modules and theme for a large number of sites? - To start with, we see three drupal core installs: the first for low-profile or non-aggressive site development, the second for moderate development, and the third for aggressive development. The thought behind this is to reduce the number of sites that we need to review for conflicts with newly added or modified modules. Any thoughts on this? - We are trying to develop a policy on user access to the file system. We understand that there are users that won't want access, but there will also be others that want to tweak modules and themeing directories. Are there any suggestions on best practices for allowing our users access to the files system? My systems folks do not want to have the nightmare of granting access, but as a developer myself, I think this is a must. - URL domains are also an issue. We have some sites that are subdomains (mysite.udel.edu), other sites are directory-based sites under the hosted domain (udel.edu/mysite). Udel.edu is running on another server. I feel confident that we can run the subdomains without much a problem, however, I am interested to see if there is a suggestion on what to do with the latter issue of udel.edu/mysite. I don't want to rewrite the URL or redirect. Any thoughts or comments on this?
Please note, I recently joined the Drupal in Ed group and plan to submit these questions more explicitly to them. I am also aware of the case studies on http://groups.drupal.org/taxonomy/term/4339. Sorry for the length of the message, please contact me if you have questions, comments, or suggestions.
Thanks! -Tina
********************************** Tina Callahan 014 Smith Hall, Newark, DE 19716 University of Delaware 302-831-1982tina.callahan@udel.edu **********************************
-- [ Drupal support list | http://lists.drupal.org/ ]
One thing I would consider On Dec 3, 2008, at 4:57 PM, Tina Callahan wrote:
• To start with, we see three drupal core installs: the first for low-profile or non-aggressive site development, the second for moderate development, and the third for aggressive development. The thought behind this is to reduce the number of sites that we need to review for conflicts with newly added or modified modules. Any thoughts on this?
I would try to get as many of the simple generic sites as possible on a multi-site install, but don't be afraid to pull these out to their own codebase when they require a module that won't be used by other sites. Don't be afraid to migrate into a custom codebase when necessary, but use smart tools to keep the management to a minimum. Whether that is just a series of shell scripts, svn:externals, or even a distributed version control system
• We are trying to develop a policy on user access to the file system. We understand that there are users that won't want access, but there will also be others that want to tweak modules and themeing directories. Are there any suggestions on best practices for allowing our users access to the files system? My systems folks do not want to have the nightmare of granting access, but as a developer myself, I think this is a must.
One technique here, might be to create an account for each group corresponding to their site's name, and give them a public_html folder within their home directory, that is in turn symlinked to public or something similar in the drupal root of their site, so that they can access it at example.com/public/FOO. Allowing the user FTP access to their own home directory would allow them simple file uploads or static files if necessary. Since these would be found under the root for their site, they could easily link to them from within their site as well. -Mike __________________ Michael Prasuhn mike@mikeyp.net http://mikeyp.net
participants (3)
-
Michael Prasuhn -
Shai Gluskin -
Tina Callahan