Stanford has a very active and engaged Drupal community. These are some of the Stanford specific resources for Drupal:
One of our major goals as a Drupal community is to facilitate the re-use of exportables, like Features (using the Drupal Features module).
There is more extensive documentation of our best practices in publicly shared google doc: https://docs.google.com/document/d/1YJykryqu2wY8K-o85dE3ev0H1rWHYHvSpqMcqwVY5yY/edit?usp=sharing
Properly configuring caching on a Drupal site is one of the most important things that a site administrator can do to improve performance. Caching represents a tradeoff between speed and "freshness" of content, however. There are some tools, such as the Boost crawler, that can prime your cache.
(See also: Load Page Cache after Cron Runs.)
For a personal stanford sites site (i.e. people.stanford.edu/mstoaks) Is it correct that the module "Backup and Migrate Files" is only available in production and not in dev (people-dev.stanford.edu/mstoaks)?
Rationale for This Document
An upgrade of a Drupal 6 website is a complex proposition. As a general rule of thumb, many professional Drupal development teams approach a major Drupal version upgrade as a new site development project, and estimate anywhere from 60-80% of the original development resources (time, money) for the upgrade.
Ever get frustrated about the output from
'--extra="-t"' to your
'drush sqlq' command, and get a nicely-formatted table. (
"--extra" allows you to include any options you would pass to
'man mysql' to see more options to pass to
There are two ways you can run Drupal 6.x at Stanford.
Request your Drupal 6.x site on the Stanford Sites service. This is open to everyone, including individuals. Installation is easy and code updates and maintenance are handled by IT Services. You can't install your own modules or themes, but installations come with plenty of pre-installed modules chosen by the community. Read more at sites.stanford.edu.
In fall 2011, the web infrastructure team in IT Services made some changes to how virtual host (vhost) proxies are handled. Previously, all proxies were on a dedicated pool of proxy servers (proxy1.stanford.edu, proxy2.stanford.edu, proxy3.stanford.edu). This configuration required the use of the Reverse Proxy module. The infrastructure team is in the process of moving all existing proxies onto the www servers themselves.
If you are developing a custom module with custom blocks in Drupal 7, using hook_block_info() and hook_block_view(), and you are finding that when you make changes to the code and they don't show up in the block, or you change the name of your delta and get an "undefined variable: block" error message, despite obsessively clearing your cache and enabling/disabling the module, try this:
(per Marco, 2.1.2012)
Users with 8 character long SUNetIDs can't log into your Drupal site using WebAuth. Other users have no issue.
There is a bug in the WebAuth module for Drupal that's triggered under the following conditions:
* vanity URL is handled by the Reverse Proxy servers
* WMD 2.55 or 2.56 (possibly earlier ones as well)
* SUNetID of person logging in is 8 characters long
== The Cause