Core modules required:
• CTOOLS(required by another module)
• Views (Essential “smart query” tool for displaying content; requires CTOOLS)
• Panels (Allows creation of layouts with drag and drop; requires CTOOLS)
• ckeditor (newest RTE; required by another module)
• wysiwyg (Rich text editor which allows custom editors, such as ckeditor)
• IMCE (required by another module)
• IMCE wysiwyg bridge (requires IMCE; allows image selection from the editor/thumbnail creation/file browser)
• pathologic(required by another module)
• link it and link it picker (requires pathologic, replaces nodepicker in drupal 6 -- allows user to click button to link to another node)
• Administration Menu
• token (required by another module)
• pathauto (requires token)
• menu_block (allows functionality to add secondary menu on sidebar)
• menu_breadcrumb (Allows breadcrumbs to work off of instead of )
• date (Adds flexible date/time field types to CCK)
• devel (Allows debugging information for developers)
• Theme Developer (Helps designer/programmer decide on templates to use, and shows fields used on pages. Requires devel.)
Here is a list of the modules we're currently using with the 34 Olin Library sites. These are just the enabled modules that are not part of Drupal core. (One 'module' from Drupal.org may contain several different modules you can enable at will - this lists them separately.)
The columns show the enabled module name, the number of Drupal 7 sites with the module enabled, the number of Drupal 6 sites, and the total sites.
We start sites off with no modules and add them as needed. We try to get rid of modules that are no longer needed for speed and maintenance reasons. This is sort of an organically grown list.
Here at Olin Library we've been using a couple of our custom modules to allow users to create accounts and log in to drupal sites using CUWebAuth. I was talking to Mark Wilson at the SIG meeting - he managed to do this using the LDAP modules from drupal.org. I wonder how many other CUWebAuth strategies there are out there?
I have a very long list of the modules used by the six sites in Admissions, Financial Aid and the Graduate School, that I didn't want to post here and I don't have a handy place to put it where anyone can see it. It's more like Jim's list with which modules are enabled within groupings of modules. I don't have the expertise to know which should be part of a core supported group, so I haven't broken those out. I have sent it to the Steering Committee to use in their deliberations. If anyone else wants to see it, drop me a line.
Posted by Anonymous (not verified) on November 12, 2012 at 10:21pm
I would add these two modules to the list.
Node Clone: "The clone module allows users to make a copy of an existing item of site content (a node) and then edit that copy. The authorship is set to the current user, the menu and url aliases are reset, and the words "Clone of" are inserted into the title to remind you that you are not editing the original content." This makes it easier for non-technical writers to add content to new Drupal sites.
Advanced Help: "The advanced help module allows module developers to store their help outside the module system, in pure .html files. The files can be easily translated simply by copying them into the right translations directory."
Comments
Suggested Core (Contributed)
Suggested Core (Contributed) Modules to get a Drupal site rolling right "out of the box":
Re: Suggested Core (Contributed)
boost (excellent for mostly static sites)
cck (drupal 6)
wysiwyg
webserver_auth (cuwebauth)
google_analytics
i also like views/panels, but also can be a world of hurt
pressflow is a very nice bundle of common modules
Pasted from Irina's (CIT) requirements comment
Core modules required:
• CTOOLS(required by another module)
• Views (Essential “smart query” tool for displaying content; requires CTOOLS)
• Panels (Allows creation of layouts with drag and drop; requires CTOOLS)
• ckeditor (newest RTE; required by another module)
• wysiwyg (Rich text editor which allows custom editors, such as ckeditor)
• IMCE (required by another module)
• IMCE wysiwyg bridge (requires IMCE; allows image selection from the editor/thumbnail creation/file browser)
• pathologic(required by another module)
• link it and link it picker (requires pathologic, replaces nodepicker in drupal 6 -- allows user to click button to link to another node)
• Administration Menu
• token (required by another module)
• pathauto (requires token)
• menu_block (allows functionality to add secondary menu on sidebar)
• menu_breadcrumb (Allows breadcrumbs to work off of instead of )
• date (Adds flexible date/time field types to CCK)
• devel (Allows debugging information for developers)
• Theme Developer (Helps designer/programmer decide on templates to use, and shows fields used on pages. Requires devel.)
Modules in use at Olin Library
Here is a list of the modules we're currently using with the 34 Olin Library sites. These are just the enabled modules that are not part of Drupal core. (One 'module' from Drupal.org may contain several different modules you can enable at will - this lists them separately.)
The columns show the enabled module name, the number of Drupal 7 sites with the module enabled, the number of Drupal 6 sites, and the total sites.
We start sites off with no modules and add them as needed. We try to get rid of modules that are no longer needed for speed and maintenance reasons. This is sort of an organically grown list.
https://confluence.cornell.edu/x/rtQEBw
CUWebAuth Modules
Here at Olin Library we've been using a couple of our custom modules to allow users to create accounts and log in to drupal sites using CUWebAuth. I was talking to Mark Wilson at the SIG meeting - he managed to do this using the LDAP modules from drupal.org. I wonder how many other CUWebAuth strategies there are out there?
Modules used by Admissions and Grad School sites - SAS-IT
I have a very long list of the modules used by the six sites in Admissions, Financial Aid and the Graduate School, that I didn't want to post here and I don't have a handy place to put it where anyone can see it. It's more like Jim's list with which modules are enabled within groupings of modules. I don't have the expertise to know which should be part of a core supported group, so I haven't broken those out. I have sent it to the Steering Committee to use in their deliberations. If anyone else wants to see it, drop me a line.
I would add these two modules
I would add these two modules to the list.
Node Clone: "The clone module allows users to make a copy of an existing item of site content (a node) and then edit that copy. The authorship is set to the current user, the menu and url aliases are reset, and the words "Clone of" are inserted into the title to remind you that you are not editing the original content." This makes it easier for non-technical writers to add content to new Drupal sites.
Advanced Help: "The advanced help module allows module developers to store their help outside the module system, in pure .html files. The files can be easily translated simply by copying them into the right translations directory."