Updating a site

The Drupal Kit provides scheduled updates every two months, with releases targeted for the second Tuesday of odd-numbered months. Release details can be found in the Changelog and release notes. For self-managed sites, it is the responsibility of site developers to update sites they maintain, reviewing the release notes for factors that might impact customizations.

To check which version your site is currently using, go to Reports > Status Report (admin/reports/status) and check the entry for “Installation Profile”.

Updating the Drupal Kit
- Updating a Pantheon site
- Updating a non-Pantheon site
All other updates (including add-ons)
General update reminders
Note: Updating vs. Upgrading

Updating the Drupal Kit 

Note

The process for updating the Drupal Kit includes two separate considerations: updating the Composer package utexas/utdk_profile (which provides the base functionality of the Kit and the Forty Acres theme), and updating any Drupal Kit add-ons that have been added to the site. This process will be different depending on whether your site is hosted on Pantheon.

Updating a Pantheon site 

For sites hosted on Pantheon, you must use the Pantheon site dashboard to apply the update to the Drupal Kit. This is because the version of the Drupal Kit is set by the Pantheon “upstream.”

Note

Pantheon’s 1-click update applies to all packages listed in your Composer manifest. If you added drupal/views_data_export with a floating version constraint such as ^1 and a new release of Views Data Export is available, the 1-click update will update that dependency, too.

Depending on the site, the types of dependencies defined, and types of updates available, developers may want to apply updates in more targeted ways than the 1-click update. Multiple techniques for narrower update strategies are discussed below.

From https://dashboard.pantheon.io/, click the DEV tab. If there are available updates to the Drupal Kit, they will be listed under “Upstream Updates.”
Click “Apply updates.”
Deploy the change to the TEST environment for functional testing, and then to LIVE.

For subsequent local development, run git pull origin master, then composer install to apply the changes to your local environment.

Updating a non-Pantheon site 

For non-Pantheon sites, the following command will update only the Drupal Kit kernel. This may include a Drupal core update and contributed modules required by the kernel. It will not update any other dependencies, not even Drupal Kit Add-ons such as the News, Profile, or Event features.

Perform this update in a non-live environment, then sync the code change.

composer update utexas/utdk_profile --with-all-dependencies

Since this command specifies the package name utdk_profile, it will not update other dependencies you may have defined in your composer.json such as other contributed modules. You should keep any modules you add updated, and should use Composer to do so. See below.

All other updates (including add-ons)

Drupal has embraced Composer as the tool for orchestrating the external PHP code that goes into building a web application. Developers can use Composer to add Drupal modules, themes, and PHP libraries. The Drupal Kit itself is added to sites via Composer, and updating the Drupal Kit follows the same Composer rules as updating any other requirement.

What’s changed since version 2?

If you maintained a Drupal Kit version 2 site, your update process would have been either to pull in an upstream Git repository or to download and manually copy new files into your codebase. In version 3, updates are handled through Composer, regardless of where your site is hosted.

See technical documentation on the Composer update command and Composer versions.

Composer can make updates as simple as a single command. Its range of capabilities also facilitates different strategies for different site needs, some of which require an in-depth understanding of Composer. Each of the three update approaches listed below explain what part of the code it will update and guidance on when the approach should or should not be used.

Method One: Apply all available updates 

The broadest way to update packages is by running the update command without any narrowing parameters:

composer update

This is the same syntax Pantheon uses in its 1-click update (see above). It will update the code of any and all packages that have available updates as allowed by version requirements set in your composer.json file. (It will also update those requirements’ requirements, so your terminal output will show packages being updated that you haven’t explicitly added.)

Using this syntax, Composer requirements you have added will be updated according to the logic you set. If, for example, you required drupal/restui:^1, Composer will check for and apply updates to this module.

If you instead explicitly required drupal/restui:1.20.0, no update will be performed. Developers who do not want to retrieve automatic updates to certain modules may choose to use an explicit version requirement strategy such as this, or may use one of the variations below.

Note

The strategy of applying all available updates will generally work well for sites that have few additional Composer requirements, and when developers have been regularly applying updates.

Method Two: Apply all “UTexas” updates 

The following command will update all packages from the utexas (i.e., ITS) vendor, as well as their dependencies.

composer update utexas/* --with-all-dependencies

For example, if the latest release of utexas/utdk_profile specifies a newer version of Drupal core to use, this command will update Drupal core, as well.

If you required any of the Add-ons, any which have new releases will also be updated.

Any other dependencies you added will not be updated. If, for example, you also required drupal/restui:^1, that module will not be updated even if a new release is available, since it is not from the utexas vendor.

Note

Updating all utexas packages but avoiding updates to other dependencies may be best for sites with many additional Drupal modules, where updates to those additional modules need to be tested individually.

Method Three: Update specific packages 

To update individual packages one at a time, use the following approach (where <vendor>/<name> is a Composer package reference such as drupal/views_data_export):

composer update <vendor>/<name> --with-all-dependencies

General update reminders 

It is a good practice to set your production site into “maintenance mode” during deployment. This can be done in the UI at Configuration > Development > Maintenance Mode (admin/config/development/maintenance).

Occasionally, updates to Drupal core, contributed modules, or the Drupal Kit’s configuration will need to make changes to the active database. If there is a pending update, you should always perform it.

Run the database update by navigating to https://example.edu/update.php. or by running drush updb if you have installed drush.

Finally, it is a good idea to manually run any pending cron jobs, if you do not have a mechanism in place for automating this. See Pantheon’s article on Cron for Drupal.

Note: Updating vs. Upgrading 

The contents of this page discuss updating an existing Drupal Kit version 3 site to a new release. This should not be confused with upgrading a site from version 2 to version 3 (see Moving from Drupal 7).