After you’ve created a project it will be paused, which means that no updates or modifications will be made to your repository and it's safe to go ahead and configure update behaviors now. Follow the "Configure update behaviors" link at the top of your project overview to proceed to the update behaviors configuration wizard.

Wizard mode

Before you start to configure each of the six update types, you should decide one thing: Do you handle the update types Critical, Moderately Critical, Less Critical and Not Critical the same way? If yes, you can shorten the setup by using the SHORT mode option:

Both modes require the same setting decisions:

First, we have to configure the update behavior for the "Highly critical" updates; after saving these settings, you will configure the group of non-critical security updates, and lastly - the Normal updates (or non-security updates).

Let's see what settings can be applied for a single update type and how we can use them to achieve the best results.

Decide if you want Drop Guard to perform updates for the specific update type at all by checking or unchecking the "Apply updates to..." box. If unchecked, this update type will be excluded from updates.

Specify the Git branch you want the updates of this type to be committed to. The list of your branches will be pulled into the select list and the most appropriate branch will be suggested automatically. This branch is also used as a source for any feature branch created for updates of this type.

Next, you will be dealing with a set of checkboxes.

Decide if you want Drop Guard to create a feature branch for this update. If unchecked, all updates will be committed to the source branch we've set above. When you are using feature branches, don't forget to create the "Merge branch" action on the "Events" screen of the project edit form, so your QA process is fulfilled. A good recipe is to merge the feature branch when the task status is "Test passed" or "Closed".

If you're performing manual or automated tests for your updates, check this box above. When it's checked, Drop Guard won’t close an update task until the "Test passed" button will be clicked by someone responsible for QA.

This checkbox is an important one - if checked, Drop Guard will push updates automatically right after they're detected. This is essential for the "Highly critical" updates, as the website should be patched as soon as possible, otherwise you're at risk to face the next Drupalgeddon effect eventually.

This checkbox is used for the cases when the update could not be applied because of the merge conflict. It’s Drop Guard’s goal to preserve your customized changes of your modules.

While performing an update, Drop Guard checks the specific module for modifications. If such is found, it makes a patch out of it, applies an update against the "clean" version of the project, and tries to re-apply the patch. Then it's up to you to decide whether to stop the update process and review what went wrong or to proceed, discarding your modifications, at the same time writing the output to the task log. We recommend having this one checked for all update types except "Highly critical".

The following checkbox can be used to tell Drop Guard to create a Git tag for update commit. You can also create Git tags for various events on the "Events" screen.

Drop Guard needs to update itself in rare cases as well. An updated module ensures seamless functionality of the tool. Click here to learn more about the Drop Guard live site module. Drop Guard will handle its own module updates like other module updates of the update type you need to set in the next box:

And finally, there is the "Reload best practices" button at the bottom of the “Update behaviors” page in case you're unsure which settings to apply for the given update type, or just messed with configuration a bit and want to revert to the default state.


This video explains how to configure update behaviors properly.