PHPackages                             wunderio/updates\_log - 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. [Logging &amp; Monitoring](/categories/logging)
4. /
5. wunderio/updates\_log

ActiveDrupal-module[Logging &amp; Monitoring](/categories/logging)

wunderio/updates\_log
=====================

Logs detailed information about module updates.

2.5.7(11mo ago)149.6k↓35.2%1[9 issues](https://github.com/wunderio/drupal-updates-log/issues)[1 PRs](https://github.com/wunderio/drupal-updates-log/pulls)GPL-2.0-or-laterPHP

Since Jun 3Pushed 11mo ago2 watchersCompare

[ Source](https://github.com/wunderio/drupal-updates-log)[ Packagist](https://packagist.org/packages/wunderio/updates_log)[ Docs](https://github.com/wunderio/drupal-updates-log)[ RSS](/packages/wunderio-updates-log/feed)WikiDiscussions main Synced 1mo ago

READMEChangelog (10)Dependencies (2)Versions (40)Used By (0)

Updates Log
===========

[](#updates-log)

[![Validate Release Tag vs Composer Version](https://github.com/wunderio/drupal-updates-log/actions/workflows/validate-release.yml/badge.svg)](https://github.com/wunderio/drupal-updates-log/actions/workflows/validate-release.yml)

Project overview
----------------

[](#project-overview)

Updates Log is a Drupal module that logs project update statuses. It helps track security updates across multiple Drupal installations by logging module statuses on a daily basis and creating alerts based on these logs.

### Why use Updates Log?

[](#why-use-updates-log)

When managing many Drupal sites, keeping track of security updates can be challenging. Updates Log provides:

- Daily logging of module status changes
- Centralized logging compatible with systems like SumoLogic
- Ability to create custom alerts (e.g., on Slack) based on logs
- Comprehensive statistics for analysis and monitoring

While alternatives like Warden exist, Updates Log offers more configurable alerting capabilities.

Team
----

[](#team)

- **Ragnar Kurm** - Maintainer
- **Wunder** - Development and support

Distribution
------------

[](#distribution)

- [Packagist](https://packagist.org/packages/wunderio/updates_log)
- [GitHub](https://github.com/wunderio/drupal-updates-log)

Installation
------------

[](#installation)

### Requirements

[](#requirements)

- Drupal 9, 10, or 11
- Composer
- Drush

### Installation steps

[](#installation-steps)

1. Install the module using Composer:

    ```
    composer require wunderio/updates_log:^2
    ```
2. Install a core patch for the `update` module [bug](https://www.drupal.org/project/drupal/issues/2920285):

    - For Drupal 9 use [this patch](https://www.drupal.org/files/issues/2021-06-12/2920285-23.patch)
    - For Drupal 10 use [this patch](https://www.drupal.org/files/issues/2022-03-30/update-module-stuck-mr782-dedup-2920285-35.patch)
    - For Drupal 10.1.5+ use [this patch](https://www.drupal.org/files/issues/2023-10-10/update-module-stuck.patch)
    - For Drupal 10.2.2+ use [this patch](https://www.drupal.org/files/issues/2024-01-26/2920285-51.patch)
    - For Drupal 11, you may still encounter this issue. If you do, try the workarounds in the troubleshooting section
3. Enable the module:

    ```
    drush en -y updates_log
    ```
4. Optional: By using [Config Split](https://www.drupal.org/project/config_split), keep the module enabled only in the default branch.
5. Export the configuration:

    ```
    drush cex -y
    ```
6. Verify the installation by running cron:

    ```
    drush cron
    ```

    At the first cron execution, it will report all modules from "unknown" state to the "known" state. Check your logs!

Usage
-----

[](#usage)

On hourly basis it logs the differences of the statuses of modules like this (if there are any changes):

```
 ---- -------------- ------------- ---------- ------------------------------------------------------------------------------------------------------
  ID   Date           Type          Severity   Message
 ---- -------------- ------------- ---------- ------------------------------------------------------------------------------------------------------
  1    01/Jul 15:43   updates_log   Info      updates_log={"project":"drupal","old":"CURRENT","new":"NOT_SECURE","site":"example.com","env:"prod"}==
 ---- -------------- ------------- ---------- ------------------------------------------------------------------------------------------------------

```

`old` and `new` denote statuses. Respectively old status, and new status. The above log can be understood like this: `drupal` package was up-to-date in earlier run and changed its status now (security update was released), so the status changed from `CURRENT` to `NOT_SECURE`.

Status codes are taken from the Drupal code:

- `web/core/modules/update/src/UpdateManagerInterface.php`

    - `NOT_SECURE`
    - `REVOKED`
    - `NOT_SUPPORTED`
    - `NOT_CURRENT`
    - `CURRENT`
- `web/core/modules/update/src/UpdateFetcherInterface.php`

    - `NOT_CHECKED`
    - `UNKNOWN`
    - `NOT_FETCHED`
    - `FETCH_PENDING`

Timing
------

[](#timing)

The full statistics log entry is generated in approx 24h interval.

The diff log entries may be generated as often as once per hour.

State
-----

[](#state)

`updates_log.last` - Only hourly last run timestamp is kept here. The value is kept in epoch seconds. If there is a necessity to observe or change the values, these are the reference commands:

- `drush sget updates_log.last`
- `drush sset updates_log.last 1654253832`

`updates_log_statistics.last` - Only 24h last run timestamp is kept here. The value is kept in epoch seconds. Similar reference commands apply as shown above.

`updates_log.statuses` - Module "current" statuses are kept in this state variable. Required to be able to perform diff. To observe the contents of it run the following command: `drush sget updates_log.statuses --format=json`.

Output
------

[](#output)

The generic format is `id={json}==`. There are two equal-signs at the end to mark the end of the JSON. It is needed, because in some logging environment there is additional encapsulation used which makes parsing impossible.

### Diff

[](#diff)

When there are any changes in module statuses, then their output in the logs looks as follows:

```
updates_log={
  "project": "webform",
  "old": "NOT_CURRENT",
  "new": "CURRENT",
  "site": "example.com",
  "env": "prod"
}==
```

Every state change will have its own log entry.

### Statistics

[](#statistics)

The module also logs "Statistics" once in 24h that gives a quick overview about how many modules there are and in what statuses.

```
updates_log_statistics={
  "updates_log": "2.5.0",
  "last_check_epoch": 1672835445,
  "last_check_human": "2023-01-04T12:30:450GMT",
  "last_check_ago": 16,
  "site": "project-acme-support",
  "env": "prod",
  "summary": {
    "CURRENT": 31,
    "NOT_CURRENT": 0,
    "NOT_SECURE": 0,
    "NOT_SUPPORTED": 1,
    "REVOKED": 0,
    "UNKNOWN": 0
  },
  "details": {
    "NOT_SUPPORTED": {
       "admin_toolbar": "3.1.0"
    }
  }
}==
```

The "prefix" (`updates_log_statistics=`) is there to help filter and parse the data from the log entry.

### Site

[](#site)

The `site` identifies project. It is detected by using first non-empty item:

- `$settings['updates_log_site']`
- Env `PROJECT_NAME`
- Env `HOSTNAME`
- Env `DRUSH_OPTIONS_URI` + hostname extraction
- `"unknown"`

### Env

[](#env)

The `env` identifies environment (dev, staging, production, etc). It is detected by using first non-empty item:

- `$settings['updates_log_env']`
- Env `ENVIRONMENT_NAME`
- Env `WKV_SITE_ENV`
- Settings `simple_environment_indicator` + color removal
- `"unknown"`

Settings
--------

[](#settings)

You can add `$settings['updates_log_disabled'] = TRUE;` in your `settings.php` to stop updates\_log from reporting.

This is useful for sites that want to report updates in only one environment.

Development
-----------

[](#development)

### Setting up a development environment

[](#setting-up-a-development-environment)

1. Clone [drupal-project](https://github.com/wunderio/drupal-project) as a base:

    ```
    git clone https://github.com/wunderio/drupal-project.git
    cd drupal-project
    ```
2. Clone the `updates_log` project into the modules directory:

    ```
    git clone https://github.com/wunderio/drupal-updates-log.git web/modules/custom/updates_log
    ```
3. Edit `.lando.yml` to disable unneeded services and their proxies:

    ```
    # Disable: chrome, elasticsearch, kibana, mailpit, node
    ```
4. Start the development environment:

    ```
    lando start
    ```
5. Install dependencies:

    ```
    lando composer install
    ```
6. Set up the Drupal site:

    ```
    lando drush site-install
    lando drush en updates_log
    ```
7. Run cron to test the module:

    ```
    lando drush cron
    ```

    Or bypass time checks for testing:

    ```
    lando ssh
    UPDATES_LOG_TEST=1 drush cron
    ```

### Testing and quality assurance

[](#testing-and-quality-assurance)

The module includes automated tests and code quality tools:

1. Run code quality checks:

    ```
    lando grumphp run
    ```
2. Run PHPUnit tests:

    ```
    lando phpunit --group=updates_log
    ```

### Making releases

[](#making-releases)

See the [PR template](.github/PULL_REQUEST_TEMPLATE.md) for the release process.

Troubleshooting
---------------

[](#troubleshooting)

### Testing without time restrictions

[](#testing-without-time-restrictions)

Use the `UPDATES_LOG_TEST` environment variable to bypass the time requirement for testing:

```
UPDATES_LOG_TEST=1 drush cron
```

or

```
UPDATES_LOG_TEST=1 drush eval 'updates_log_cron();'
```

This applies to both hourly and daily functional modes. After running this, you should get full statistics in logs, and if there are any state changes, these should have their own log entries too.

### Debugging the Drupal update module

[](#debugging-the-drupal-update-module)

If you're experiencing issues with the update module:

1. Verify the update settings:

    - Make sure `/admin/reports/updates/settings` loads and is configured correctly
    - Save the form again to ensure settings are applied
    - Check the status at "Available updates" report - is it red or green?
2. Debug update data:

    ```
    drush eval 'var_dump(update_get_available(TRUE));'
    ```

    This should return a large array.
3. Check project data:

    ```
    drush eval '$available = update_get_available(TRUE); $project_data = update_calculate_project_data($available); var_dump($project_data);'
    ```
4. Reset update module state (try these solutions in order until one works):

    ```
    # Solution 1: Clear the update fetch task
    drush php:eval "\Drupal::keyValue('update_fetch_task')->deleteAll();"

    # Solution 2: If Solution 1 doesn't work, try uninstalling and reinstalling the update module
    drush pm-uninstall -y update && drush pm-enable -y update

    # Solution 3: If Solutions 1 and 2 don't work, try the full reset
    drush ev '\Drupal::keyValue("update_fetch_task")->deleteAll();'
    drush sqlq 'truncate batch'
    drush sqlq 'truncate queue'
    drush pm-uninstall -y update; drush pm-install -y update
    drush sdel update.last_check
    ```

### Debugging Updates Log module

[](#debugging-updates-log-module)

Check the state of the Updates Log module:

```
drush sget updates_log.statuses --format=json
drush sget updates_log.last
drush sget updates_log_statistics.last
```

Known issues
------------

[](#known-issues)

### Drupal core bug

[](#drupal-core-bug)

There is a Drupal [core bug](https://www.drupal.org/project/drupal/issues/2920285) which in certain situations would not fetch new data, or would only fetch it for some projects but not others. This issue has been reported across multiple Drupal versions including Drupal 9, 10, and 11.

Symptoms of this issue include:

- "No update information available" message
- Only some modules showing update information while others don't
- Update information not refreshing even after running cron

The issue can sometimes be resolved by:

1. Applying the appropriate patch for your Drupal version (see installation instructions)
2. Clearing the update fetch task cache (see troubleshooting section)
3. Uninstalling and reinstalling the update module

This issue has been partially fixed in various Drupal versions, but may still occur. The patches and workarounds listed in this README have been reported to help in most cases.

Contributing
------------

[](#contributing)

Contributions to the Updates Log module are welcome! Please follow these steps:

1. Fork the repository
2. Create a feature branch
3. Make your changes
4. Run tests to ensure code quality
5. Submit a pull request

Please follow the coding standards and include tests for new functionality.

###  Health Score

37

—

LowBetter than 83% of packages

Maintenance30

Infrequent updates — may be unmaintained

Popularity32

Limited adoption so far

Community13

Small or concentrated contributor base

Maturity60

Established project with proven stability

 Bus Factor1

Top contributor holds 66.3% 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.

###  Release Activity

Cadence

Every ~43 days

Recently: every ~2 days

Total

26

Last Release

357d ago

Major Versions

1.1.0 → 2.0.0-rc12023-01-05

### Community

Maintainers

![](https://avatars.githubusercontent.com/u/3274758?v=4)[Wunder](/maintainers/wunderio)[@wunderio](https://github.com/wunderio)

---

Top Contributors

[![ragnarkurmwunder](https://avatars.githubusercontent.com/u/28702260?v=4)](https://github.com/ragnarkurmwunder "ragnarkurmwunder (116 commits)")[![Juhani-moilanen](https://avatars.githubusercontent.com/u/107038594?v=4)](https://github.com/Juhani-moilanen "Juhani-moilanen (49 commits)")[![tormi](https://avatars.githubusercontent.com/u/146800?v=4)](https://github.com/tormi "tormi (7 commits)")[![artursv](https://avatars.githubusercontent.com/u/1763464?v=4)](https://github.com/artursv "artursv (3 commits)")

---

Tags

logsecuritydrupalupdates

### Embed Badge

![Health badge](/badges/wunderio-updates-log/health.svg)

```
[![Health](https://phpackages.com/badges/wunderio-updates-log/health.svg)](https://phpackages.com/packages/wunderio-updates-log)
```

###  Alternatives

[monolog/monolog

Sends your logs to files, sockets, inboxes, databases and various web services

21.4k964.9M7.0k](/packages/monolog-monolog)[psr/log

Common interface for logging libraries

10.4k1.2B9.2k](/packages/psr-log)[symfony/monolog-bundle

Symfony MonologBundle

2.9k249.1M1.6k](/packages/symfony-monolog-bundle)[spatie/laravel-activitylog

A very simple activity logger to monitor the users of your website or application

5.8k45.4M309](/packages/spatie-laravel-activitylog)[sentry/sentry

PHP SDK for Sentry (http://sentry.io)

1.9k227.1M273](/packages/sentry-sentry)[sentry/sentry-laravel

Laravel SDK for Sentry (https://sentry.io)

1.3k114.3M154](/packages/sentry-sentry-laravel)

PHPackages © 2026

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