Install

Works with Drupal: ^10.6 || ^11.3

Using Composer to manage Drupal site dependencies

Alternative installation files

Download tar.gz 25.29 KB
MD5: d2188342cfae5b06cbb6a8462d53b1b7
SHA-1: 6ef892d8406d1c0ba48ff73f63cf268b9fd2dfc8
SHA-256: c0a00f10a625c8934fbb48ba12201c5ef56af513e68388f13e658518cb199fc3
Download zip 35.06 KB
MD5: 19c6c9c89d01a717495fcc26f505b811
SHA-1: bef3d7696a471b252c37bbca8af6e7a3db794069
SHA-256: 665b90b4e13d69e21a3c0d2c5be3a984f967e624fe3eec13d3ecdfb4a0293b50

Release notes

Declares the PHP floor in composer.json. No code change; nothing to do on update.

Changed

composer.json now declares "php": ">=8.1". It previously specified no PHP constraint at all, so the effective floor came only from whatever core happened to require — the supported surface was implied rather than stated, and a reader had to trace Drupal's own requirements to find it.

8.1 is the real floor, checked rather than assumed: PHPCompatibility reports the codebase clean from 8.1 upward, Drupal 10.6 requires >=8.1.0, and neither drupal/key nor drupal/encrypt declares a PHP constraint of its own. It is already verified as well — the drupal.org previous-major lane runs this suite on PHP 8.1.34 and passes, so this is a claim CI exercises rather than one it merely tolerates.

This changes no resolution outcome today, because ^10.6 || ^11.3 already implies the same floor. What it changes is that the claim is stated where Composer and a human both read it, and it stops moving silently if core's floor moves or this module adopts newer syntax.

Upgrading

No code, schema or configuration change. Nothing to do.

Created by: jmcerda
Created on: 30 Jul 2026 at 20:33 UTC
Last updated: 30 Jul 2026 at 20:33 UTC
Bug fixes
Unsupported

Other releases