On updating a module to a version that has a dependency on an earlier version of Drupal core, update.php cannot be run.
Steps to reproduce
It has been suggested that the update module detects the missing dependency and rolls back the update. Alternative suggestions to resolve this issue include providing dependency metadata in the module obtained from the module's .info file or backing up the currently installed module before updating and reverting if necessary.
To develop a method of checking dependencies prior to upgrading modules.
None
None
On a Drupal 7.7 site I've updated Menu Block from 7.x-2.0-beta4 to 7.x-2.3 and now cannot run update.php because Menu Block requires Drupal 7.11 or higher.
Is there a way update.module can detect this missing dependency earlier and rollback the update to the module?
Closed: outdated
11.0 🔥
update.module
The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.
After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Marking outdated. Automatic updates handles this, and the feature to install modules via URL is in the process of being removed from core.
📌
Remove adding an extension via a URL
Fixed
📌
Remove UI and routes for the ability to update modules and themes via update.module and authorize.php
Active