Recovering Drupal After an Interrupted Composer Install

Recognize the symptoms

Field widgets such as string_textfield disappear, Twig reports missing core templates, or services fail to compile even though the referenced files still exist.

Diagnose before changing content

Check drush status, confirm the locked Drupal version, inspect whether core files exist, and compare the generated vendor tree with a healthy environment using the same lock file.

Recover generated dependencies

Preserve the broken runtime as a backup, restore vendor and web/core from a known-good build of the same commit, rebuild caches, and rerun the failed operation. Do not replace the database or custom source code.

Build before deployment

Run Composer, coding standards, and asset builds in Lando or CI. Deploy a complete artifact to constrained hosting instead of building dependencies there.

Partial installs create an inconsistent runtime

Composer does not update every file atomically. If installation stops partway through, the repository commit and lock file may describe one release while generated autoload data, installed packages, scaffold files, or Drupal core files reflect another point in the operation. The resulting exceptions can look unrelated because the runtime itself is internally inconsistent.

That is why the first recovery goal is to restore one coherent dependency set rather than debug every missing class or plugin individually.

Prefer reinstalling the known lock file

When the PHP environment can run Composer safely, restore the repository to the intended commit and run composer install from its reviewed lock file. If the hosting environment cannot perform that installation reliably, deploy a complete known-good build produced elsewhere from that exact commit and lock file.

Copying individual missing files is risky because there may be many more mismatches than the first exception reveals.

Verify the runtime before touching content

After restoring dependencies, confirm Drupal bootstraps, the database connects, module discovery is complete, caches rebuild, and important routes work before changing the database. A broken plugin definition caused by incomplete code is not evidence that content or configuration should be deleted.