The \Drupal::VERSION on 11.x is 11.0-dev whereas on 11.1.x the version is 11.1.0-dev. This means a module that declares itself incompatible with 11.1 can be installed on 11.x which I don't think makes sense. I think 11.x should always have a future version constraint.
Try installing field_encrypt version 3.2.0 on 11.1.x and 11.x. This module requires a lot of work to be compatible with 11.1 because of the hooks changes and therefore is also completely borked on 11.x.
Change \Drupal::VERSION constraint on 11.x
N/a
N/a
N/a
N/a
N/a
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | Screenshot 2024-11-22 at 21.19.15.png | 390.59 KB | oily |
| #13 | Screenshot 2024-11-22 at 21.00.03.png | 360.49 KB | oily |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !10164
Comments
Comment #3
alexpottComment #4
quietone commentedComment #5
smustgrave commentedThat test relevant to this change? I can't re-run
Comment #6
alexpott@smustgrave yes I think it is.
Comment #7
ptmkenny commentedI'm not sure if this is related, but I also ran into trouble getting field_encrypt 4.x, which requires
^11.1in the module.info.yml, working locally.In my case, when I tried using the constraint
drupal/core: "^11.1.0-alpha1",composer installworked, but when I tried to re-initialize my site (I have a drush script that resets the datebase and reimports config), the config import failed with the error:The same thing happened with the constraint
"drupal/core": "11.x-dev@dev".The module can be installed with composer and in Drupal with
"drupal/core": "11.1.x-dev@dev".Comment #8
alexpott@ptmkenny that module is why I discovered this issue and started to work on this :)
Comment #9
ptmkenny commented@alexpott Yep, I saw that. But note that my comment seems to be that the reverse is also the case.
field_encrypt 3.2, which has a constraint "do not install on 11.1", can be composer required with 11.x-dev, even though it won't work. (your report)
But field_encrypt 4.0, which has a constraint "at least 11.1", can be composer required with 11.x-dev, but the module can't be enabled (giving the message "incompatible with this version of Drupal core")-- it seems it still thinks it is 11.0.x?.
So I'm not sure if this behavior should be a separate issue or part of this one.
Comment #10
alexpott@ptmkenny both of those things will be fixed by this.
Comment #11
ptmkenny commentedPerfect!
I just tested this MR locally and can confirm that my problem reported in #7 (composer require of a module that needs 11.1 works, but actually enabling the module in drupal fails) is fixed.
Comment #12
andypostProbably it was a cause of 2.8.1 composer regression https://github.com/composer/composer/pull/12109#issuecomment-2400181869
Comment #13
oily commentedTried installing the field_encrypt module version 3.2.0 on Drupal 11.x:
screenshot: Drupal 11.x successful composer install
Then tried to install it on Drupal 11.1.x:
screenshot: Drupal 11.1.x failed composer install
Comment #14
oily commentedComment #15
oily commentedTried installing the field_encrypt module version 3.2.0 on the issue fork of Drupal 11.x:
screenshot: Drupal 11.x failed composer install
I believe means that the fix works. Changing to 'RTBTC'.
Comment #16
chi commentedIsn't this a duplicate of #3481012: Deprecate \Drupal::VERSION and use \Composer\InstalledVersions::getVersion('drupal/core')?
Comment #17
oily commented@chi Do the screenshots indicate it fixes #3481012? If your not sure please reproduce and I think you could action #3481012 in accordance with your findings. Reading it, there is clearly overlap but not sure if the fix here addresses all the cases that need to be dealt with under #3481012 nor does this seem to implement the possible solution mentioned in #3481012.
Comment #18
oily commentedComment #19
chi commented@oily that one was about setting Drupal version to 11.2-dev for 11.x branch. That's exactly what MR in this issue does. I am fine to close #3481012: Deprecate \Drupal::VERSION and use \Composer\InstalledVersions::getVersion('drupal/core') as duplicate.
The relevant Slack conversation:
https://drupal.slack.com/archives/C1BMUQ9U6/p1729010405763549
Note that we will have to update that version to 11.3-dev once 11.3.x branch is open for development.
Comment #20
oily commented@chi Ah, that makes sense. Thanks!
Comment #21
alexpott@chi yes this is a dupe but it is at rtbc and has code so let's leave this one open. That said perhaps we could re-focus your issue to deprecate \Drupal::VERSION and use
Composer\InstalledVersions::getVersion('drupal/core')instead.Comment #22
longwaveCommitted 4650172 and pushed to 11.x. Thanks!