Modern Drupal has one rule about modules: Composer manages the code, Drupal manages whether it’s turned on. Every module problem we get called about starts with someone mixing those up — code copied in by hand, or removed while still installed. This lesson is the clean loop: add, enable, update, remove. You’ll need Composer and Drush working in your project.

Find the module and its right version

Every module on drupal.org has a machine name in its URL — drupal.org/project/admin_toolbar means the Composer package is drupal/admin_toolbar. Before requiring anything, check the project page for two things: a release marked compatible with your Drupal version, and signs of life (recent commits, maintained status). A module nobody has touched in three years deserves the skepticism you’d give a gas station sushi roll. Our note on boring technology is the longer version of that instinct.

Require it with Composer

From your project root:

composer require drupal/admin_toolbar

Composer picks the newest release compatible with your site, downloads it to web/modules/contrib/, and writes the requirement into composer.json and the exact version into composer.lock. Commit both files — the lock file is how every other copy of this site gets the same code.

Enable it with Drush

The code being on disk changes nothing yet. Turn it on:

drush pm:install admin_toolbar -y
drush cache:rebuild

That two-state design — downloaded versus installed — feels redundant until you realize it’s what lets you test a module on staging before enabling it anywhere else.

Update one module on purpose

Resist the urge to run a bare composer update, which updates everything at once and turns one change into forty suspects. Name your target:

composer update drupal/admin_toolbar --with-dependencies
drush updatedb -y
drush cache:rebuild

The updatedb matters: module updates sometimes ship database changes, and skipping them is how sites drift into weird. This same loop, with a backup first, is the heart of applying a security update safely.

Remove a module in the right order

Removal is where order matters most, and it’s the reverse of install: uninstall first, remove the code second.

drush pm:uninstall admin_toolbar -y
composer remove drupal/admin_toolbar

The uninstall step lets the module clean up its database tables and config while its code still exists to do the cleaning. Run composer remove first and Drupal is left believing in a module that isn’t there — that’s a white-screen classic. If Drush refuses because another module depends on it, uninstall the dependent one first, and watch out for submodules that ship inside a bigger project.

Verify composer.json matches reality

The end state you want: what Composer thinks, what Drupal thinks, and what git holds all agree.

composer validate
drush pm:list --status=enabled --no-core
git status

composer validate should say your file is valid. The Drush list should show only modules you recognize and mean to have on. And git status should show composer.json and composer.lock changed together, ready to commit — never one without the other. When all three line up, anyone (including future you) can rebuild this site from the repo and get exactly the modules you have right now. That’s the whole point.