Managing a Drupal site often involves checking for module updates to ensure your site remains secure and performant. However, if you have ever run the standard drush ups command on a site with dozens of modules, you know the frustration of scrolling through a sea of green "OK" messages just to find the one or two modules that actually need attention.

Filtering your update list is not just about aesthetics; it is about efficiency. When managing multiple environments or using Drush aliases to check several sites at once, seeing only the actionable data is crucial. In this guide, we will explore several methods to list only the modules that require updates using Drush and Composer, covering both legacy Drupal 7 sites and modern Drupal 10+ installations.

The Classic Drush Method: Filtering Standard Error

For many years, the standard way to check for updates in Drupal was the drush update-status command (aliased as drush ups). By default, this command outputs the status of every enabled module.

One of the most effective "hidden" tricks in the developer community involves how Drush handles its output. Drush sends the "OK" status messages to the Standard Error (stderr) stream, while the actual update information is sent to Standard Output (stdout). You can take advantage of this by redirecting stderr to null.

Using Stderr Redirection

To see only the modules that have an available update, run:

drush ups 2>/dev/null

Why this works: In Linux and Unix-like environments, 2> represents the error stream. By sending it to /dev/null, you effectively discard all the "OK" and "Checked" messages, leaving behind only the table of modules that have pending updates. This is the cleanest way to get a concise list with version numbers and update types.

Using Grep for Specific Phrases

If you prefer a more traditional text-filtering approach, you can pipe the output to grep. This is particularly useful if you are looking for specific keywords like "Security":

drush ups | grep 'Update available'

While effective, keep in mind that grep might strip away the table headers, making the output slightly harder to read if you aren't familiar with the column order.

Modern Drupal: Using Composer to List Outdated Packages

In modern Drupal (Drupal 8 and above), Composer is the source of truth for dependency management. While Drush can still check statuses, many developers prefer using Composer directly to see what is outdated. This ensures you are looking at the versions defined in your composer.json and composer.lock files.

To list only Drupal-related packages that have updates available, use the following command:

composer outdated "drupal/*"

Understanding the Output

  • Red text: Indicates a version that is technically incompatible with your composer.json constraints (e.g., a major version jump).
  • Yellow text: Indicates there is a newer version available that fits within your existing version constraints.

This method is highly recommended for modern workflows because it prevents the "version mismatch" issues that can sometimes occur when using Drush on a Composer-managed site.

Prioritizing Security Updates with Drush

Sometimes, you don't care about feature updates; you only care about security. Checking for security vulnerabilities should be your first priority during any maintenance cycle. Modern versions of Drush provide a dedicated command for this purpose:

drush pm:security

This command specifically checks the Drupal security advisories database. If your site is secure, it will return a clean message. If updates are needed, it will produce a clean table like this:

+-------------+-------------------+-------------------+
| Name        | Installed Version | Suggested version |
+-------------+-------------------+-------------------+
| drupal/core | 9.4.1             | 9.4.5             |
+-------------+-------------------+-------------------+

This is the most efficient way to audit a site quickly without getting bogged down by non-critical module updates.

Best Practices for Drupal Updates

When you identify modules that need updates, follow these best practices to avoid breaking your site:

  1. Always Backup First: Before running any update command, ensure you have a fresh database dump and a backup of your code.
  2. Read the Release Notes: Don't just update blindly. A minor version bump might include a breaking change or a required database update (drush updb).
  3. Update in Environments: Always perform updates in a local or development environment first. Test the functionality, then deploy to staging and production.
  4. Use Composer for Updates: If your site was built with the drupal/recommended-project template, use composer update drupal/modulename --with-dependencies rather than drush dl or drush up.

Common Mistakes to Avoid

  • Mixing Drush and Composer: On a modern Drupal site, avoid using drush pm-update. This command can bypass Composer's dependency tree and lead to a corrupted vendor directory. Use Drush to check for updates, but use Composer to perform them.
  • Ignoring Peer Dependencies: When updating a module, remember that it might require a newer version of a library or another module. Composer handles this automatically, whereas manual Drush filtering might hide these dependencies from you.
  • Running Commands as Root: Always run Drush and Composer as the user who owns the web files (e.g., www-data) to avoid permission issues in your file system.

Frequently Asked Questions

Why does drush ups show my modules as "OK" even when I know an update exists?

This usually happens because of caching. Drush caches the update information. You can try clearing the Drupal cache (drush cr or drush cc all) or checking the "Available Updates" report in the Drupal UI to force a refresh of the update data.

Can I format the output as JSON for automated scripts?

Yes! If you are building a custom dashboard or a monitoring script, use the --format flag:

drush ups --format=json

This allows you to programmatically filter for modules where the status is not "up to date."

Does composer outdated show security info?

Not by default. While it shows newer versions, it doesn't distinguish between a bug fix and a critical security patch. For security-specific checks, drush pm:security or the composer audit command (in newer Composer versions) are better choices.

Wrapping Up

Filtering your Drupal update list saves time and reduces the cognitive load of site maintenance. Whether you are using the 2>/dev/null trick for legacy Drush 8 sites or leveraging composer outdated for modern projects, having a clean list of pending updates is the first step toward a healthier, more secure website.

Always prioritize security updates with drush pm:security and remember to test all changes in a staging environment before pushing to production. Happy coding!