John Bickar's Blog Posts

If you're using Behat and the Drupal Extension, you might find the following code snippet helpful if you want to add a step to wait for batch jobs to finish.

If one of your Behat scenarios kicks off a batch job (e.g., a Feeds import), and you want to wait for that batch job to finish before moving on to the next step, add this step definition in your FeatureContext.php file:

Then, in your featurename.feature file, you can call this step like so:

This will cause the web driver to wait until the batch job is finished (or, more accurately, to wait until there is no longer an id="updateprogress" element on the page), or else timeout after 3 minutes (180000 ms). You can adjust the timeout to whatever you want by changing that 1800000 number. You will have to use the @javascript context in your feature to use this step definition.

(Note that a request to add this step definition to the Behat Drupal Extension has been submitted.)

See The Code

• Example .feature file
• Example FeatureContext.php file

Drupal 7.32 was released on October 15th to fix a critical security vulnerability. All Drupal 7 sites on sites.stanford.edu and people.stanford.edu 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 sites.stanford.edu or people.stanford.edu?

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

• FAQ on the Drupal Security Vulnerability

• Public Service Announcement About the Drupal Security Vulnerability

• Drush plugin for checking your Drupal 7 site

• Your Drupal Website Has a Backdoor

• Your Drupal Site Got Hacked - Now What?

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

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

• Friday, September 5, from 9 a.m. - 5 p.m.: Personal websites hosted on Stanford Sites (at people.stanford.edu)
• Saturday, September 6, from 4 - 8 a.m.: Group and department sites hosted on Stanford Sites
• Sunday, September 7, from 4 - 8 a.m.: Group and department sites hosted on Stanford Sites

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, and this related blog post for a complete overview of theme updates.

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 7.31
• Administration views (admin_views) 7.x-1.3
• Backup and Migrate (backup_migrate) 7.x-3.0
• Better Exposed Filters (better_exposed_filters) 7.x-3.0-beta4
• Block Class (block_class) 7.x-1.3
• Computed Field (computed_field) 7.x-1.0
• Content Access (content_access) 7.x-1.2-beta2
• Context (context) 7.x-3.2
• context_list_active (context_list_active) 7.x-1.0-alpha2
• Date (date) 7.x-2.8
• Email (email) 7.x-1.3
• Features (features) 7.x-2.2
• Feeds Tamper (feeds_tamper) 7.x-1.0
• Feeds XPath Parser (feeds_xpathparser) 7.x-1.0-beta4
• File (Field) Paths (filefield_paths) 7.x-1.0-beta4
• Flag (flag) 7.x-3.5
• Insert (insert) 7.x-1.3
• Libraries (libraries) 7.x-2.2
• Link (link) 7.x-1.2
• Menu Block (menu_block) 7.x-2.4
• Metatag (metatag) 7.x-1.0-rc2
• Module filter (module_filter) 7.x-1.8
• Mollom (mollom) 7.x-2.10
• Node clone (node_clone) 7.x-1.0-rc2
• OpenLayers (openlayers) 7.x-2.0-beta9
• Pathologic (pathologic) 7.x-2.12
• Relation (relation) 7.x-1.0-rc5
• Rules (rules) 7.x-2.7
• Site Verification (site_verify) 7.x-1.1
• Taxonomy Manager (taxonomy_manager) 7.x-1.0
• Transliteration (transliteration) 7.x-3.2
• Views Data Export (views_data_export) 7.x-3.0-beta8
• Views Slideshow (views_slideshow) 7.x-3.1
• Webform (webform) 7.x-4.0
• Cube (cube) 7.x-1.4
• Rubik (rubik) 7.x-4.1
• Tao (tao) 7.x-3.1
• Stanford Date Formats (stanford_date_formats) 7.x-1.0
• Stanford Date Timepicker (stanford_date_timepicker) 7.x-1.0-alpha3
• Stanford Events Importer (stanford_events_importer) 7.x-3.0-alpha7
• Stanford Image (stanford_image) 7.x-3.0
• Stanford Image Styles (stanford_image_styles) 7.x-3.0
• Stanford News (stanford_news_
• Stanford Sites Helper (stanford_sites_helper) 7.x-1.2
• Stanford Slides (stanford_slides) 7.x-3.0-alpha3
• Stanford Video (stanford_video) 7.x-2.0
• WebAuth Module for Drupal (wmd) 7.x-3.3
• WebAuth Extras (webauth_extras) 7.x-1.0-alpha2
• Stanford Drupal Profile (stanford) 7.x-1.1
• iCalcreator 2.20.2
• jquery-ui-timepicker v1.4.5

Drupal 6:

• Date (date) 6.x-2.10
• Feeds (feeds) 6.x-1.0-beta13
• Feeds Tamper (feeds_tamper) 6.x-1.0
• FileField (filefield) 6.x-3.13
• ImageField (imagefield) 6.x-3.11
• Link (link) 6.x-2.11
• Node form columns (nodeformcols) 6.x-1.7
• Rubik (rubik) 6.x-3.0-beta5

In July, 2014, the Field Group module was updated from 7.x-1.1 to 7.x-1.4 on Stanford Sites. This update has the potential to cause issues with CSS, as certain types of markup were removed from the HTML output of the page.

Background

The Field Group module allows site builders to group fields together on the back-end edit form of entities (e.g., nodes, BEANs), and on the front-end display of those entities. The latter is what was affected.

The Issue

In Field Group 7.x-1.1, field groups that were configured as <div> elements would get a class of group_groupname and group-groupnameapplied to them (note the underscore and the hyphen in each class):

<div class="field-group-format group_foo field-group-div group-foo  speed-fast effect-none">

In Field Group 7.x-1.4, the group_groupname has been removed, but group-groupname persists:

<div class=" group-foo field-group-div" id="node-article-full-group-foo">

Before (7.x-1.1)

After (7.x-1.4)

The Fix

If you have CSS like the following:

simply update it to this:

Better yet, the Field Group module allows you to assign your own classes and IDs to field group elements, so you should add those and target those names in your CSS (therefore not relying on the markup output by the Field Group module). Read Megan Miller's excellent article, "How I learned the hard way to create reusable classes" for more on that subject.