Skip to content Skip to navigation


Cynthia Mijares Posted by Cynthia Mijares on Friday, December 5, 2014 - 8:21am

Drupal has a couple of standard ways to display content using a Default view or a Teaser view display. Stanford Web Services uses View modes to create multiple image/Field Collection displays and allows the site builder to change how fields will be displayed. 

Enabling View modes on your site

  • From the Modules menu, enable Display Suite and Display Suite UI. If necessary, flush the Menu Cache.
  • Navigate to Structure > Display Suite.
  • Click View modes tab.

Create new View mode

  • Click + Add a view mode.
  • Fill in the Label field.
  • Edit Machine name (if necessary).  Stanford Web Services recommends that you choose your machine names carefully.  Pick a prefix for your organization or use one that is already in use by your organization (e.g., soe_ , gsb_ , etc.).
  • Select Entities for which the view mode will be available.
  • Then click the Save button.


Manage the display of the new view mode

  • From the Display Suite View modes page, click on the Displays tab, then click Manage display for the item you are targeting.
  • Click the Custom display settings horizontal tab, then select the view mode you just created.
  • Click the Save button.
  • The View mode is now available.


  • You can show/hide the field label and show/hide individual fields.
  • Click on the gear and choose from your available Image styles. 
  • Then click the Save button.
Posted in:
Caryl Westerberg Posted by Caryl J Westerberg on Friday, November 21, 2014 - 8:18am

Have you ever wanted to put a border on an image or highlight a link for more information in a text field? It is possible to configure the  Styles dropdown menu in your WYSIWYG editor to allow you to add styles to the content in a text field. If you don't know how to configure your Styles dropdown, here's how you can add multiple classes to an element using the HTML editor pane of the WYSIWYG.

Disable the WYSIWYG

To edit the HTML in a text area:

  1. Navigate to the page you'd like to edit

  2. Click the Edit button

  3. Scroll to just below the Body or other WYSIWYG text area

  4. Click on Disable-rich text

You should see the WYSIWYG disappear, and if any content was in the field you’ll see the HTML. To go back the WYSIWYG, click on Enable rich-text.

Adding classes to HTML elements

At Stanford Web Services, our themes support a variety of CSS classes which you can use in a text area. Some of these classes such as float-right are available through the WYSIWYG Styles dropdown menu. Other classes that are available in the theme, but not currently present in the Styles dropdown, such as border-simple must be applied directly to the HTML. 

Suppose you have an image that you want to have both a simple border and to have it float to the right. Here’s how to make that happen:

Add the float-right through the WYSIWYG

Taking advantage of the WYSIWYG, let’s start with the WYSIWYG enabled.

  1. Add the image to the text area

  2. Click on the image to select it

  3. From the Styles dropdown menu, select Image Right

Image of the styles dropdown menu

Add the border directly to the HTML

1.  Disable the WYSIWYG by clicking the Disable rich-text link below the field.

2.  Look for the line with your image. It’ll probably look something like:

<p class="float-right"><img src=""/></p>

3.  Add the border class, border-simple, to this line. The result should be something like:

<p class="float-right border-simple"><img src=""/></p>

4. Enable rich-text then scroll to the bottom and click Save.

Check out the results

You can see that the image has floated to the right, and if you look, you'll see a border around the image.

More CSS classes from Open Framework Style Guide

You can learn about our CSS classes such as float-right and border-simple  from our Open Framework style guide.

Posted in:
Posted by Joe Knox on Thursday, November 20, 2014 - 10:57am

University IT will perform updates for all websites hosted on the Stanford Sites Drupal hosting service on the following dates:

  • Friday, December 5th, from 9 a.m. - 5 p.m.
  • Saturday, December 6th, from 4 a.m. - 8 a.m.
  • Sunday, December 7th, from 4 a.m. - 8 a.m.

The changes are significant and include security patches and upgrades for both Drupal 6 and 7 sites. See below for a complete list of module updates.

The 7.34 update to Drupal core addresses two vulnerabilities: limiting the length of passwords at the API level and correcting an issue with sites that serve “mixed mode” http/https content. Stanford Sites relies almost exclusively on the WebAuth module for Drupal and does not serve “mixed mode” http/https content. As a result, the update did not warrant an emergency rollout.

Websites are scheduled to receive upgrades on a rolling basis. Please note that when the upgrade begins on a website, all logged-in users (if any) will be logged out, and the website will be placed offline temporarily. Visitors will see a message that the website is offline for maintenance. Security patches and database updates will be applied, and the website will be placed back online. We expect the website to be offline for approximately 1 minute during the updates.

If you experience issues with your website hosted on Stanford Sites, please submit a HelpSU request. We will respond as soon as possible.

What is included in the upgrade

Drupal 7:

  • Drupal Core 7.34
  • External Repository Update Status 7.x-1.0
  • Bean 7.x-1.8
  • Calendar 7.x-3.5
  • Context 7.x-3.3
  • Contextual Block Classes 7.x-1.0
  • Context List 7.x-1.x-dev
  • Display Suite 7.x-2.7
  • Field Collection 7.x-1.0-beta8
  • File Entity 7.x-2.0-beta1
  • Link 7.x-1.3
  • Metatag 7.x-1.4
  • Mollom 7.x-2.12
  • OpenLayers 7.x-2.0-beta11
  • Relation 7.x-1.0-rc6
  • Services 7.x-3.11
  • UUID 7.x-1.0-alpha6
  • Webform 7.x-4.2
  • Stanford Courses 7.x-3.3
  • Stanford Events Importer 7.x-3.0-alpha9
  • Stanford Image 7.x-3.1
  • Stanford Image Styles 7.x-3.1
  • Stanford Sites Helper 7.x-1.3
  • Stanford Sites System Tools 7.x-1.2
  • Stanford WYSIWYG 7.x-2.3
  • Stanford Drupal Profile 7.x-1.2
  • WebAuth Module for Drupal 7.x-3.4

Drupal 6:

  • Backup Migrate 6.x-2.8
  • Backup Migrate_files 6.x-1.x-dev
  • Filefield Paths 6.x-1.5
  • Google Analytics 6.x-3.6
  • Imagecache Actions 6.x-1.9
  • Mollom 6.x-2.11
  • Views Bulk Operations 6.x-1.16
  • Webform 6.x-3.21
Posted in:
Sara Worrell-Berg Posted by Sara Worrell Berg on Friday, November 7, 2014 - 7:16am

Are you at BADCamp this weekend? Want to talk about opportunities for web-savvy folks at Stanford?

We want to talk to you, too!

It’s a great time to be working on the web, particularly in Drupal, at Stanford - there are over 100 positions in various fields across the university, and as of right now almost 20 of them involve Drupal. You have a passion for supporting Stanford’s academic mission? We have open positions for project managers, site builders, developers, content strategists, writers, and designers. See all the jobs open at Stanford and search for the right one for you.

A little shout-out for SWS

Our team is partnering with Stanford's top-notch School of Engineering to create new roles and do great work together. We’re looking for amazing people for the following positions:

web project manager to lead custom Drupal development projects with clients as well as select internal projects, including custom module development, upgrades to the popular Stanford Sites platform, and anything else our team can dream up. The perfect role for a seasoned PM who loves agile and thinks Post-It’s and kanban boards are beautiful office decor. Apply for this position on Stanford Careers with job number 63437.

producer/site architect to partner with the web project manager to build excellent Drupal sites hosted on the Stanford Sites platform. The perfect role for someone who loves Drupal, solving problems, building Features, and working with a team. Extra points for someone who loves to share what they're learning with others through our blog and Drupal camps. This gig isn't on the job board just yet; contact SWS to learn more.

John, Zach, Shea, Megan, Cynthia, Caryl, Linnea, and Sara

Posted in:
Posted by Joe Knox on Thursday, November 6, 2014 - 9:00am

Need to build and manage a website for university work? Want responsive and accessible themes that work well on phones, tablets, and desktop browsers? Looking for a self-service tool that requires little technical expertise and has all patches and upgrades handled at no cost? Stanford Sites is for you!

Post updated on May 20, 2015.

The Stanford Sites Drupal hosting service has many of the most popular Drupal modules and unique Stanford themes pre-installed. It’s customized for our academic environment and is available to current faculty, staff, and students free of charge, so you can use it to build your personal and department or group website. 

As of fall 2014, there are more than 1,400 websites hosted on Stanford Sites, and all are monitored and securely maintained by University IT. Training and support are available as well.

How to get started

Our Stanford Web Services team developed a "Getting Started on Sites" series. We're always adding more awesomely helpful tips to our blog, so add it to your favorite browser’s bookmark toolbar.

While the series can be read and studied in any order as needed, we’ve constructed the following list in the most sequential way to help guide you through getting started on Stanford Sites. 

  1. How to Request a new Drupal Site
  2. Configuring Your Personal Drupal Site
  3. How to Attach Documents to Your Content
  4. How to Add Images to Your Content
  5. Inserting Images in Your Content
  6. How to Add a Google Map to Your Website
  7. Image Styles
  8. Adding New Fields to Your Content Type
  9. What’s this “No front page content” about?
  10. Creating a New Content Type
  11. Improving the Node Edit Form
  12. How do I remove the “authoring information” on my page?
  13. Taxonomy
  14. Taxonomy Manager
  15. Adding a new user to your Stanford Drupal site
  16. Remove Users Account Privileges
  17. Creating a New View Mode
  18. Adding Google Analytics to your site
  19. Why you might want to request a development site
  20. Linking to a Profile on
  21. Creating a Personal Webpage: Just like the Jane Smith preview!

Posted in:
Photo of John Bickar Posted by John Bickar on Friday, October 31, 2014 - 2:43pm

Drupal 7.32 was released on October 15th to fix a critical security vulnerability. All Drupal 7 sites on and were upgraded that day. On October 29th, a further Public Service Announcement was released, detailing the severity of the vulnerability and steps to take if you believe that your Drupal 7 site may have been compromised.

Given this recent PSA, we are continuing to audit all sites on the Stanford Sites platform in coordination with the Information Security Office (ISO).

If you have questions about your Drupal 7 website at Stanford and would like further information about how the vulnerability may affect you, please submit this form, and University IT will contact you to help.

Common questions

Q: Do you have recommendations on how a site owner should investigate this problem for Drupal 7 sites not hosted in or

A: Yes, though the answer is complex. The most thorough process for investigation and remediation is detailed in the flowchart at: Your Drupal Website Has a Backdoor

Please note that if you did not upgrade your website on October 15, simply upgrading to Drupal 7.32 now may not be enough. You may need to take additional steps to look out for signs your website has been compromised.

Q: The PSA says that "Attackers may have copied all data out of your site." Does this include the database access info in the settings.php file?

A: Unfortunately, yes. The vulnerability that was announced (and patched) on October 15th allows an attacker unfettered access to your Drupal codebase, files, and database.

What to do now

Every content management platform requires regular maintenance and security upgrades, and there are several options available to you for help.

First, know where your website is hosted and know what version of Drupal you are using and when it was last upgraded. If you need help answering these questions, please contact University IT through submitting this form, and we will be happy to assist.

Next, if you know that your Drupal 7 website is not hosted on Stanford Sites and it is not yet upgraded, please do the following ASAP:

  1. Take immediate steps to upgrade, or contact your web developer to do so.
  2. Watch for signs of a compromised site, or submit this form to request University IT help with monitoring.

Further Reading

Thank you for taking these important steps to ensure the security of your websites for Stanford University.

Posted in:
Shea McKinney Posted by Shea Ross McKinney on Monday, October 27, 2014 - 8:30am

In this article we are going to talk about what hard and soft configuration is and how to decide between the two when creating a distribution.

At Stanford Web Services we have several products, or Drupal distributions, and we build them with contributed modules, installation profilesFeatures, and custom modules. When we design a product we have to make decisions on what should never change and what can, or will, change but should have a sensible default when the site is initially installed.

If you are a developer or site builder and are working with or creating a distribution, please read on.

What is hard vs. soft config?

  • Hard configuration are settings that should never change throughout the lifetime of the website. 
  • Soft configuration are settings that can change or be removed but provide a sensible default or starting point. 

The what

Using ordering a Classic Club sandwich off the menu at Quiznos as an example, we can say the sandwich is the product. The sandwich has hard configuration on what types of protein it comes with (ham, turkey, & bacon), and soft configuration on what types of toppings are included. Quiznos suggests that you should eat the Classic Club with cheddar cheese, tomatoes, lettuce, and mayo. As an end user you may not like tomatoes and would rather have olives and mustard added to the sandwich. 

Much like Quiznos, when we are designing our products we have to decide what things an adminstrator, or user can change, and what they cannot. For those items that a user can change we should provide them with an out of the box set of options that appeal to the majority of users. An example of hard configuration in our products would be our WYSIWYG and text formats configuration. We have established a set of options and formats that should be consistent throughout all of our products. An example of soft configuration would be user roles and permissions. We provide default out of the box configuration that makes sense for most websites, but administrators may want to change which content types their staff have access to and which they do not. 

The how

Ok, great. So now you understand what hard vs. soft configuration is, how do you get them into your product? Your first guess may be Features and you are right. Features is great for packaging up settings and putting them into code. Settings in code is a great way to store hard configuration. But wait, you can override features through the user interface. Shouldn't hard configuration be something that never changes? You are right again, hard configuration should be set in stone, so when working with Features you have to be very careful to not allow administrator users access to the sections where they may change your hard configuration. The good thing about Features is that if the configuration ever does change you can quickly revert back to the original state using Feature's revert functionality. Another way you can write hard configuration is directly into your custom modules. You may use custom modules to hard code items like, content types, entities,  and views.

If Features is good for hard configuration is it also good for soft configuration? The answer for this will differ based on who you ask but our opinion is not really. The answer depends on the development workflow or site building practices in use. Features can be overridden through the UI and therefore, has the ability to provide sensible defaults that users can change. If your site building practices include re-exporting and keeping the Feature modules up to date with the latest changes you may use them effectively and efficiently. When designing a distribution we have to keep in mind that not everyone will keep Features up to date when building out their website. We also do not want to pigeonhole our site builders into this process or to force them to try and abstract the parts of the feature they want to disable. A better option for soft configuration would be to write some input once only code. This would be code that is either in an installation profile install task, or in a custom module's hook_install(). By putting the soft configuration into one of these two areas we can safely provide out of the box settings that are usable and changeable by site administrators. If the site administrator decides later they want to put their new changes into a Feature they may without running into conflicts with other features. 

Kit compliance  is important for creating re-usable features and does a good job at determining the items that can, or should, go into a feature and which items that should not. Those items that should not are a good example of something that can be configured as soft configuration. For example, Kit compliance allows for user roles and permissions that are directly related to the feature itself, but does not allow for roles or permissions established by some other contributed modules. If you wanted to set the permissions that are not directly related to your feature you may do so in an installation profile install task. This task will run once during the installation of the site. By setting permissions in an installation task you lose the ability to revert the configuration through features, but you gain flexibility in that you can change this setting later without worry.

Please check out these resources for more information on how to create a distribution:

photo of Nicholas Taylor Posted by Nicholas Taylor on Monday, October 20, 2014 - 8:56am

Web archives are a great way to reference or recover deprecated site content. You can help to ensure that old versions of your website will be faithfully preserved by designing for archivability.

A brief self-introduction

Regular visitors to the Stanford Web Services Blog likely won't recognize my byline; I am the Web Archiving Service Manager for Stanford University Libraries and pleased to join up as a new guest contributor on web archiving topics. My inaugural post concerns archivability, a design best practice to help ensure that the ever-changing web has a memory, as well.

What is archivability?

John Bickar has previously blogged on creating a static copy of a website. Archiving a website likewise entails creating a static copy but includes the capture of additional context that facilitates long-term preservation and re-presentation in a replay interface like Wayback. An archivable website facilitates content copying or archiving, particularly by crawler-based approaches, and a high degree of fidelity between the user experiences of the archived and original content.

What are the benefits of an archivable website?

Caryl Westerberg has previously blogged on the Internet Archive Wayback Machine as a resource for previous site versions. The Stanford University Archives also collects select Stanford University websites and will ultimately make those available via a Wayback instance hosted by Stanford University Libraries. Designing for archivability helps such efforts to provide you with your own deprecated site content when you need it. A more archivable website also tends to be more performant and accessible to search engine crawlers, improving usability and discoverability.

How can I make my website more archivable?

Many of the site optimizations that you would otherwise implement for performance or search engine optimization will improve archivability. For more specific recommendations, tools, and examples, Stanford University Libraries has recently published comprehensive web archivability documentation on its website.

Feedback or questions?

While I'm especially interested in working with campus webmasters on improving the archivability of the domain, I welcome any feedback or questions in support of web archivability generally. Please get in touch through this contact form.

Posted in:
Sara Worrell-Berg Posted by Sara Worrell Berg on Wednesday, October 15, 2014 - 12:29pm

A critical security update for Drupal 7.x was released today, October 15. University IT is conducting unscheduled maintenance for all websites hosted on the Stanford Sites Drupal hosting service to mitigate this vulnerability, and no further actions need to be taken by site owners at this timeMore details on what was included in this critical update can be found at

Please note that another, unrelated critical security fix is underway which affects the university's web servers. These updates are ongoing, and websites hosted on the Stanford Sites service and on AFS or other systems may experience temporary instability until the maintenance is completed.

University IT follows security best practices and closely monitors the releases of all core and module updates; critical security updates may be tested and applied immediately, and less urgent bug fixes are tested and applied in scheduled maintenance windows on a regular basis.

If you experience issues with your website hosted on Stanford Sites, please submit a HelpSU request, and we will respond as soon as possible.

Update - October 15, 2014, at 6:07 pm:

University IT completed the update to Drupal 7.32 for the Stanford Sites Drupal hosting service, including all websites on and

Posted in:
Caryl Westerberg Posted by Caryl J Westerberg on Monday, October 13, 2014 - 9:00am

When we launch a site at Stanford Web Services, we open the doors and roll out the red carpet for the search engines to index the site. However, before launch we like to keep the content under wraps and ask the search engines not to index the site. To do this, we use a module called Stanford MetaTag NoBots.

Using the Stanford Metatag NoBots module

To use this module, after installation, you only need to enable the module. When enabled, this module stops search engines from indexing your site. To allow the search engines to index your site, you disable the module.


If your site is hosted on Stanford Sites, this module is already available on your site; you just need to enable it. Otherwise, you can find this module on Github at:

To learn more about using this module and tips on checking your site to see what the search engines see, check out the at:

How it works (the technical stuff)

When a search engine crawler (or "robot") crawls a site, it sends information about whichrobot it is, in the form of a user agent string. So Google's crawler will send the "Googlebot" user agent string, Bing will send "Bing", etc. The Context User Agent module allows Drupal administrators to set up conditionsbased on a given user agent string.

When a web server responds to a request for a page, it sends various HTTP headers in its response. One of the (optional) headers is the X-Robots-Tag: noindex,nofollow,noarchive header, which (in short) tells search engine robots, "Hey, don't index or archive this page, and don't follow any links on it either". (Learn more about the Robots Exclusion Standard on Wikipedia.)

We configured Context module along with Context HTTP Header and Context Useragent modules to indentify when the the user agent string is a robot and react with the X-Robots-Tag HTTP headers. The Stanford Metatag NoBots module captures this configuration as a Feature


screenshot illustrating the context configuration

To learn more about using the Stanford MetaTag NoBots module and for tips on checking your site to see what the search engines see, check out the at:

Why a new module?

We started out using the MetaTag module on With this module you can prevent the search engines from indexing the pages on a website. This  module works great at stopping the search engines. In fact, it works too well.

When we went to launch a site, even though we changed the settings to allow indexing, some pages still remained blocked. This was because, even though we unchecked the box, meta tag information for some pages had been saved to the database and did not revert as expected.


I’d like to extend a tip of my hat to Shea McKinney and John Bickar for developing and documenting this module, and to John Bickar for contributing to this post.

Posted in:


Subscribe to Stanford Web Services Blog