- Issue created by @alexpott
- πΊπΈUnited States smustgrave
That test relevant to this change? I can't re-run
- π¬π§United Kingdom alexpott πͺπΊπ
@smustgrave yes I think it is.
- π―π΅Japan ptmkenny
I'm not sure if this is related, but I also ran into trouble getting field_encrypt 4.x, which requires
^11.1
in the module.info.yml, working locally.In my case, when I tried using the constraint
drupal/core: "^11.1.0-alpha1"
,composer install
worked, 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:Unable to install modules: module 'field_encrypt' is incompatible with this version of Drupal core.
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"
. - π¬π§United Kingdom alexpott πͺπΊπ
@ptmkenny that module is why I discovered this issue and started to work on this :)
- π―π΅Japan ptmkenny
@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.
- π¬π§United Kingdom alexpott πͺπΊπ
@ptmkenny both of those things will be fixed by this.
- π―π΅Japan ptmkenny
Perfect!
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.
- π«π·France andypost
Probably it was a cause of 2.8.1 composer regression https://github.com/composer/composer/pull/12109#issuecomment-2400181869
- π¬π§United Kingdom oily Greater London
Tried 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 βI believe this tests that the fix works. Changing to 'RTBTC'.
- π¬π§United Kingdom oily Greater London
Tried installing the field_encrypt module version 3.2.0 on Drupal 11.x:
screenshot: Drupal 11.x failed composer install β
Then tried to install it on Drupal 11.1.x:
screenshot: Drupal 11.1.x failed composer install βI believe this tests that the fix works. Changing to 'RTBTC'.
- π·πΊRussia Chi
Isn't this a duplicate of π Update Drupal::VERSION in dev branch Active ?
- π¬π§United Kingdom oily Greater London
@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.
- π·πΊRussia Chi
@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 π Update Drupal::VERSION in dev branch Active as duplicate.
The relevant Slack conversation:
https://drupal.slack.com/archives/C1BMUQ9U6/p1729010405763549Note that we will have to update that version to 11.3-dev once 11.3.x branch is open for development.
- π¬π§United Kingdom oily Greater London
@chi Ah, that makes sense. Thanks!
- π¬π§United Kingdom 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. -
longwave β
committed 4650172f on 11.x
Issue #3487150 by alexpott, oily, ptmkenny: \Drupal::VERSION on 11.x not...
-
longwave β
committed 4650172f on 11.x
Automatically closed - issue fixed for 2 weeks with no activity.