PHPackages                             tomboone/drupal-update-helper - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [DevOps & Deployment](/categories/devops)
4. /
5. tomboone/drupal-update-helper

AbandonedArchivedLibrary[DevOps & Deployment](/categories/devops)

tomboone/drupal-update-helper
=============================

A bash script to interactively update Drupal direct dependencies via Composer, one by one.

027Shell

Since Apr 25Pushed 1y ago1 watchersCompare

[ Source](https://github.com/tomboone/drupal-update-helper)[ Packagist](https://packagist.org/packages/tomboone/drupal-update-helper)[ RSS](/packages/tomboone-drupal-update-helper/feed)WikiDiscussions main Synced 1mo ago

READMEChangelogDependenciesVersions (1)Used By (0)

Drupal Update Helper Suite
==========================

[](#drupal-update-helper-suite)

This repository contains a suite of helper scripts designed to assist with common update and maintenance tasks for Composer-managed Drupal projects, particularly focusing on dependency updates and multisite installations.

---

Interactive Dependency Updater (`vendor/bin/composer-update-helper`)
--------------------------------------------------------------------

[](#interactive-dependency-updater-vendorbincomposer-update-helper)

This script provides an interactive way to update your Drupal project's direct Composer dependencies one package at a time, creating a separate Git commit for each successful update.

### Overview / Purpose

[](#overview--purpose)

Use this script when you want granular control over the update process, allowing you to test and review changes incrementally, rather than applying all available updates at once.

- Identifies outdated direct dependencies using `composer outdated`.
- Creates a dated Git branch (`update/YYYY-MM-DD`, using the current date) for the updates.
- Loops through each available update, skipping packages listed in `.drupal-updater-ignore`.
- Prompts (`y/N`) for confirmation before attempting to update each package.
- Runs `composer update [package-name] --with-dependencies` for confirmed packages.
- Detects common Composer failures (like authentication issues or issues related to vendored `.git` directories) and provides guidance.
- Determines the installation path of the updated package using `composer show --path`.
- Stages `composer.json`, `composer.lock`, and the updated package code directory.
- Skips the commit step gracefully if Composer didn't actually make changes (e.g., due to version constraints).
- Commits each successful update individually.
- Prompts whether to push the completed branch to your Git remote (`origin`).

### Prerequisites

[](#prerequisites)

Executing this script requires the following tools to be available in your environment (native or inside Docker):

- **bash** (v4+ recommended)
- **git**
- **composer** (v1 or v2)
- **jq** (command-line JSON processor)

### Usage

[](#usage)

1. **Navigate** to your Drupal **project root directory** in your terminal (the one containing the main `composer.json`).
2. **Ensure** your Git working directory is clean (`git status` should show no uncommitted changes).
3. **Execute** the script. If running within Docker, you **must** use flags to allocate an interactive terminal (`-it`): ```
    # Native environment:
    vendor/bin/update_modules.sh.sh

    # Inside Docker (example):
    docker exec -it [-e COMPOSER_AUTH='...'] your_container_name vendor/bin/update_modules.sh.sh
    ```

    *(Note: Pass `COMPOSER_AUTH` environment variable if GitHub authentication is needed).*
4. **Follow Prompts:** The script will guide you through creating a branch and confirming (`y/N`) updates for each detected package not listed in your ignore file.
5. **Review Output:** Pay attention to messages indicating success, skipped commits (e.g., due to constraints), or Composer failures.
6. **Push (Optional):** Decide whether to push the update branch when prompted at the end.

### Configuration (`.drupal-updater-ignore`)

[](#configuration-drupal-updater-ignore)

To prevent the script from offering updates for certain packages, create a file named `.drupal-updater-ignore` in your project root directory.

- List one `vendor/package` name per line.
- Lines starting with `#` and blank lines are ignored.

**Example:**

```
# .drupal-updater-ignore
# Core stuff if managed separately
drupal/core-recommended
drupal/core-composer-scaffold

# Modules/Themes to skip
drupal/module_with_patches
drupal/custom_theme_dependency
some-vendor/some-library

```

### Special Error Handling

[](#special-error-handling)

This script includes specific detection for a common Composer error (`The .git directory is missing...`) that can occur in workflows where vendored dependencies have their `.git` folders renamed (e.g., to `.git_`). If this specific error is detected, the script will provide tailored instructions guiding you on how to manually fix the affected package's state (usually involving `rm -rf` and `composer install` for that package) before you can proceed.

### Important Notes

[](#important-notes)

- **Run from Project Root:** Essential for Composer and Git commands to function correctly.
- **Clean Git Status Required:** Prevents accidental inclusion of unrelated changes.
- **Interactive Terminal Required:** The script relies on `read` prompts and needs a TTY (use `-it` in Docker).
- **DB Updates / Cache Clear:** This script **does not** run `drush updb` or `drush cr`. You must handle database updates and cache clearing separately after deploying the code changes.
- **Testing:** Always test updates thoroughly, preferably in a staging environment.
- **Backups:** Ensure you have reliable backups before running any update process.

---

Multisite Module Status Check Script (`vendor/bin/check_modules.sh`)
--------------------------------------------------------------------

[](#multisite-module-status-check-script-vendorbincheck_modulessh)

This script provides a command-line utility to assess the status of contributed modules within a Drupal multisite installation managed by Composer, targeting specific environment aliases.

**Purpose:**

- Checks the shared codebase for available **security vulnerabilities** using `composer audit`.
- Checks the shared codebase for available **general updates** (minor/major) using `composer outdated 'drupal/*'`.
- Identifies installed **Composer modules** (type `drupal-module`, excluding dev requirements) that are **not enabled** on *any* of the Drupal sites whose Drush aliases match the specified environment suffix (`.local` or `.prod`).
- Uses the project's local Drush instance (`vendor/bin/drush`) for consistency.
- Dynamically discovers target Drush aliases based on the provided environment argument.

**Prerequisites:**

1. **Execution Location:** The script **must** be run from the root directory of your Drupal project (the directory containing your main `composer.json` and `vendor/` directory).
2. **Drush Aliases:** Drush aliases **must** be configured for your multisite setup (e.g., in `[project-root]/drush/sites/self.site.yml` or similar). Aliases should follow a consistent naming convention ending in `.local` for local environments and `.prod` for production environments (e.g., `@self.site1.local`, `@self.site2.prod`).
3. **`jq` (Optional):** The command-line JSON processor `jq` is no longer strictly required by this script but may be useful for other command-line tasks.

**Usage:**

Ensure you are in your Drupal project's root directory. You must specify the target environment using the `-e` or `--environment` flag.

```
# Check modules against aliases ending in .local
vendor/bin/check_modules.sh.sh -e local

# Check modules against aliases ending in .prod
vendor/bin/check_modules.sh.sh --environment=prod
```

**Configuration (Drush Alias Example):**

The script relies on your existing Drush alias configuration. Ensure your aliases are defined and follow the `local`/`prod` convention.

```
# Example: drush/sites/site1.site.yml

# Define aliases for individual sites following the convention
local:
  root: /var/www/html/my-project/web # Adjust path to your Drupal web root
  uri: site1.dev.local               # URI used locally for site1
  config_split_name: local_dev_split # Optional: config split for local
  uses_private_files: true           # Optional: sync private files

prod:
  host: prod.server.com
  user: deploy_user
  root: /var/www/html/my-project/web          # Adjust path on production
  uri: https://www.site1.com # Production URI for site1
```

**Output:**

The script outputs the following sections:

1. **Timestamp & Target Env:** Indicates when the check was run and which environment (`.local` or `.prod`) was targeted.
2. **Discovered Aliases:** Lists the specific Drush aliases found matching the target environment pattern.
3. **Security Audit:** Output from `composer audit`, highlighting potential vulnerabilities.
4. **Available Updates:** Output from `composer outdated 'drupal/*'`, listing Drupal packages with available updates. (Review version numbers to distinguish minor/major).
5. **Unused Drupal Modules:** A list of module machine names that are:
    - Required in your `composer.json` (with type `drupal-module`, excluding `require-dev`).
    - *Not* found to be enabled on *any* of the dynamically discovered sites matching the target environment (`.local` or `.prod`).

**Dependencies:**

The script relies on the following command-line tools:

- `bash`
- `drush/drush` (via `vendor/bin/drush`)
- `composer`
- Standard core utilities: `grep`, `sed`, `sort`, `uniq`, `mktemp`, `wc`, `date`, `paste`, `comm`

---

Site Synchronization Script (`vendor/bin/sync_sites.sh`)
--------------------------------------------------------

[](#site-synchronization-script-vendorbinsync_sitessh)

This script automates the process of synchronizing data and files from a production Drupal site to its corresponding local development site for all sites defined in the `drush/sites/` directory.

### Prerequisites

[](#prerequisites-1)

1. **Drush Alias Files:** Each site pair (production and local) must have its aliases defined in a separate YAML file within the `drush/sites/` directory (e.g., `drush/sites/my_site.site.yml`).
    - The file name (without `.site.yml`) is used as the base alias name (e.g., `my_site`).
    - Aliases within the file must be named `local` and `prod` (resulting in Drush aliases like `@my_site.local` and `@my_site.prod`).
2. **`yq` Utility (Python version):** The script uses the Python-based `yq` command-line YAML processor (which uses path syntax like `.local.key`) to read configuration from alias files. This version is installed via `apt install yq` within the project's `Dockerfile`. Ensure this version is available in the environment where the script runs (the `wrlc_drupal` container).
3. **Config Split Name (Optional):** If the local site uses a specific configuration split that needs to be re-imported after a database sync, add a `config_split_name` key under the `local` alias definition in the corresponding `.site.yml` file. ```
    # drush/sites/my_site.site.yml
    local:
      uri: http://my_site.local
      root: /path/to/local/web
      config_split_name: local_dev_split # Add this line if needed
      # ... other local settings
    prod:
      # ... prod config ...
    ```
4. **Private Files Usage Flag (Optional):** To enable synchronization of private files, add a `uses_private_files` key set to `true` under the `local` alias definition in the corresponding `.site.yml` file. If this key is missing, `false`, or `null`, the private file sync step will be skipped for that site. ```
    # drush/sites/my_site.site.yml
    local:
      uri: http://my_site.local
      root: /path/to/local/web
      config_split_name: local_dev_split
      uses_private_files: true # Add this line to sync private files
    prod:
      # ... prod config ...
    ```

### Usage

[](#usage-1)

Run the script from the project root directory, typically inside the Drupal container:

```
docker exec -it wrlc_drupal vendor/bin/sync_sites.sh
```

License
-------

[](#license)

This script suite is licensed under the MIT License. See the [LICENSE](LICENSE) file for details.

###  Health Score

17

—

LowBetter than 6% of packages

Maintenance36

Infrequent updates — may be unmaintained

Popularity7

Limited adoption so far

Community7

Small or concentrated contributor base

Maturity15

Early-stage or recently created project

 Bus Factor1

Top contributor holds 100% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

### Community

Maintainers

![](https://www.gravatar.com/avatar/f731e16c4844d7b092ec253567f1909f7ba9f5a4e04810e8bf51d022461b1413?d=identicon)[tomboone](/maintainers/tomboone)

---

Top Contributors

[![tomboone](https://avatars.githubusercontent.com/u/20044572?v=4)](https://github.com/tomboone "tomboone (25 commits)")

### Embed Badge

![Health badge](/badges/tomboone-drupal-update-helper/health.svg)

```
[![Health](https://phpackages.com/badges/tomboone-drupal-update-helper/health.svg)](https://phpackages.com/packages/tomboone-drupal-update-helper)
```

###  Alternatives

[deployer/deployer

Deployment Tool

11.0k25.4M207](/packages/deployer-deployer)[appwrite/server-ce

End to end backend server for frontend and mobile apps.

55.3k84.2k](/packages/appwrite-server-ce)[pragmarx/health

Laravel Server & App Health Monitor and Notifier

2.0k1.0M2](/packages/pragmarx-health)[felixfbecker/language-server-protocol

PHP classes for the Language Server Protocol

22476.7M6](/packages/felixfbecker-language-server-protocol)[heroku/heroku-buildpack-php

Toolkit for starting a PHP application locally, with or without foreman, using the same config for PHP and Apache2/Nginx as on Heroku

8161.3M10](/packages/heroku-heroku-buildpack-php)[tiamo/phpas2

PHPAS2 is a php-based implementation of the EDIINT AS2 standard

4674.7k](/packages/tiamo-phpas2)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)