Difference between revisions of "Drupal"
Jump to navigation
Jump to search
m |
m |
||
| Line 32: | Line 32: | ||
*Create initial roles -- site admin, faculty, staff, grad student, ugrad student, and the particular content admins for that site: "Grad Office", "Main Office", "Grants Manager", etc. | *Create initial roles -- site admin, faculty, staff, grad student, ugrad student, and the particular content admins for that site: "Grad Office", "Main Office", "Grants Manager", etc. | ||
*Create an error page. Read http://drupal.org/node/120646 | *Create an error page. Read http://drupal.org/node/120646 | ||
| + | |||
| + | ==Development Plans== | ||
| + | #GuardDog Module -- in order to provision all of our accounts, we'll need to create a GuardDog module that (and we can look at the ldap groups module for ideas I believe) will allow us to detect and select GD groups, associate them with roles, and maintain user accounts... creation is one thing, but when we start looking at keeping content over time, or specifically in the case of students become alumni, we'll need to think about how we disable/delete accounts. | ||
| + | #Drupal Mass Manager -- due to the fact that we'll be installing Drupals everywhere, and upon many different vhosts, we need ways to maintain the sites. | ||
| + | ##If possible, we should look at ways of creating a single theme and module repository that all of the sites can either see, or that we somehow automatically maintain... not sure about this. | ||
| + | ##Due to the fact that the one central location we have for everything (that we can always access) is our database server, we need to look at creating an application that allows us to automate/update/view site settings across the board... | ||
Revision as of 20:03, 2 February 2008
Default Modules
These modules are those modules which we activate on all of our sites across the board.
- WRAP Authentication (custom)
- Custom module created by WolfTech to allow the drupal system to recognize when and to auto login when someone has used WRAP authentication.
- Masquarade
- allows the site admins to troubleshoot permissions issues by "logging in as" another user.
Optional Modules
The following are optional modules which have been tested by us and are supported for use within our drupal sites.
Future Modules
These modules are ones that we're investigating and may support once we've had time to play with them.
- User Badges
- We could possibly use these to distinguish people on the sites when posting. Especially when we get into forums, commenting, etc. Think of "ECE Faculty", "ECE Staff", "ECE IT", "ECE Grad Student", "ECE Ugrad Student", etc.
Rejected Modules
Just for us to keep note/logs, here are those modules which we've looked at, but rejected. If we're smart, we've noted why the module was rejected.
Current Drupal Sites
- ECE Intranet -- General Administration
- ECE Intranet -- Sponsored Research
- ECE Intranet -- Graduate
- ECE Intranet -- Undergraduate
- WolfTech -- Drupal Development
Initial/Common Site Setups
Need to start listing this out, creating a recipe for our sites... here's a few in no particular order
- Turn on the Full HTML Input format as default. Will stop people from having problems with images and tables in their pages/articles.
- Configure your default content types to not promote to the frontpage -- though this probably isn't an issue if we're changing the frontpage. Need to check on that. Administer>>Content management>>Content types
- Administer>>Content management>>Comments>>Settings and set the comments to be entered on a "separate page" and make sure that "Preview comment" is set to "Required."
- Change the frontpage from "node" to a page of your choice -- or enable the "front_page" module to force the issue.
- Create initial roles -- site admin, faculty, staff, grad student, ugrad student, and the particular content admins for that site: "Grad Office", "Main Office", "Grants Manager", etc.
- Create an error page. Read http://drupal.org/node/120646
Development Plans
- GuardDog Module -- in order to provision all of our accounts, we'll need to create a GuardDog module that (and we can look at the ldap groups module for ideas I believe) will allow us to detect and select GD groups, associate them with roles, and maintain user accounts... creation is one thing, but when we start looking at keeping content over time, or specifically in the case of students become alumni, we'll need to think about how we disable/delete accounts.
- Drupal Mass Manager -- due to the fact that we'll be installing Drupals everywhere, and upon many different vhosts, we need ways to maintain the sites.
- If possible, we should look at ways of creating a single theme and module repository that all of the sites can either see, or that we somehow automatically maintain... not sure about this.
- Due to the fact that the one central location we have for everything (that we can always access) is our database server, we need to look at creating an application that allows us to automate/update/view site settings across the board...