I tried uninstalling the required_api module altogether and then re-enabling just required_by_content_moderation_state and required_api, with the same result - the field is displayed as required when it should not be. I then uninstalled again and re-enabled just required_by_role and required_api, and had the same result. So I'm starting to think version 3 of this module just doesn't work at all. I'll stick with version 2 for now.
I tried changing one of the fields to use the Core required strategy and to not be required; the red asterisk went away. I then changed it back to required by state, and the asterisk came back. I also tried changing it to required by role with a role the current user does not have, and again the field showed as required when it should not be. So this is not a problem with the submodules, it's with the API module.
benstallings → created an issue.
Update
benstallings → created an issue.
benstallings → made their first commit to this issue’s fork.
I can confirm that MR!21 can now be installed with composer and enabled in Drupal 11.
@markconroy I have, yes, but the status is Needs Review because someone besides me needs to review it. :)
OK, thanks for the additional info. The theme should now be installable in D11 without the contrib stable theme. Please confirm.
This is out of my comfort zone:
Error: Class "Drupal\flysystem\Decorator\FlysystemDrupalFileSystem" not found in /var/www/html/web/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 #0 /var/www/html/web/core/lib/Drupal/Component/DependencyInjection/Container.php(177): Drupal\Component\DependencyInjection\Container->createService()
#1 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(289): Drupal\Component\DependencyInjection\Container->get()
#2 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(253): Drush\Runtime\LegacyServiceInstantiator->resolveFromContainer()
#3 [internal function]: Drush\Runtime\LegacyServiceInstantiator->resolveArgument()
#4 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(223): array_map()
#5 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(193): Drush\Runtime\LegacyServiceInstantiator->resolveArguments()
#6 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(167): Drush\Runtime\LegacyServiceInstantiator->instantiateObject()
#7 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(117): Drush\Runtime\LegacyServiceInstantiator->create()
#8 /var/www/html/vendor/drush/drush/src/Runtime/LegacyServiceInstantiator.php(54): Drush\Runtime\LegacyServiceInstantiator->instantiateServices()
#9 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(242): Drush\Runtime\LegacyServiceInstantiator->loadServiceFiles()
#10 /var/www/html/vendor/drush/drush/src/Boot/DrupalBoot8.php(218): Drush\Boot\DrupalBoot8->addDrupalModuleDrushCommands()
#11 /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php(211): Drush\Boot\DrupalBoot8->bootstrapDrupalFull()
#12 /var/www/html/vendor/drush/drush/src/Boot/BootstrapManager.php(397): Drush\Boot\BootstrapManager->doBootstrap()
#13 /var/www/html/vendor/drush/drush/src/Application.php(219): Drush\Boot\BootstrapManager->bootstrapMax()
#14 /var/www/html/vendor/drush/drush/src/Application.php(185): Drush\Application->bootstrapAndFind()
#15 /var/www/html/vendor/symfony/console/Application.php(284): Drush\Application->find()
#16 /var/www/html/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRun()
#17 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#18 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#19 /var/www/html/vendor/drush/drush/drush.php(140): Drush\Runtime\Runtime->run()
#20 /var/www/html/vendor/bin/drush.php(119): include('...')
#21 {main}
benstallings → made their first commit to this issue’s fork.
Looking at https://www.drupal.org/project/flysystem/issues/3378738 🌱 Planning for Release 3.0.0, Drupal 10.3+ Compatibility, Flysystem v3.1 Compatibility Needs work , it looks like there's no chance Flysystem v3 will be ready anytime soon, so I drop my objection. I'll see if I can make this work with the 2.2.x-dev MR at https://www.drupal.org/project/flysystem/issues/3433330 📌 Automated Drupal 11 compatibility fixes for flysystem Needs review .
@markconroy because after repeated searching I cannot find any evidence that stable9 has a future -- all the docs I can find specify Drupal 9 or 10 and do not mention 11+. The only link to documentation in the README file for stable9 actually specifies Drupal 8 in its URL rather than the current link supplied with Olivero. Can you please point me to some evidence that stable9 is not deprecated? Thank you!
@shashi_shekhar_18oct as I said above, the dependency on version 2.0 of flysystem module, which does not support Drupal 11, means that this version of flysystem_s3 cannot be installed with composer into a Drupal 11 site. This module needs to be made dependent on a version of flysystem that supports D11.
@markconroy I think you will find the contrib version of stable is named stable and not stable9. I've added a composer.json file that requires that dependency, and the theme now installs with composer and can be enabled in D11. Please confirm.
benstallings → made their first commit to this issue’s fork.
I can confirm that MR!77 can be installed and enabled in D11.
I'm not able to reopen this ticket, but it is not completed because the core version specified in services.info.yml is still 10 and not 11. I will see if I can make a new MR.
I'm unable to install this fork in D11 with composer due to its dependency on flysystem v2 which is not D11 compatible. It needs to be dependent on version 3, or at least this MR: https://git.drupalcode.org/issue/flysystem-3451092/-/tree/fix-merge-error
@borisson_ thank you for your vote of confidence! I am taking the liberty of changing the status to "Reviewed & tested by the community" on your behalf.
benstallings → created an issue.
I stand corrected, just changing the type in the database is not enough, you also have to populate all of the tables with their non-stripe equivalents:
insert into commerce_payment_method__stripe_card_exp_month select cem.* from commerce_payment_method m join commerce_payment_method__card_exp_month cem on cem.entity_id = method_id left join commerce_payment_method__stripe_card_exp_month scem on scem.entity_id = m.method_id where stripe_card_exp_month_value is null;
insert into commerce_payment_method__stripe_card_exp_year select cey.* from commerce_payment_method m join commerce_payment_method__card_exp_year cey on cey.entity_id = method_id left join commerce_payment_method__stripe_card_exp_year scey on scey.entity_id = m.method_id where stripe_card_exp_year_value is null;
insert into commerce_payment_method__stripe_card_number select cn.* from commerce_payment_method m join commerce_payment_method__card_number cn on cn.entity_id = method_id left join commerce_payment_method__stripe_card_number scn on scn.entity_id = m.method_id where stripe_card_number_value is null;
insert into commerce_payment_method__stripe_card_type select ct.* from commerce_payment_method m join commerce_payment_method__card_type ct on ct.entity_id = method_id left join commerce_payment_method__stripe_card_type sct on sct.entity_id = m.method_id where stripe_card_type_value is null;
and then clear the cache.
OK, never mind, this seems to be a problem with old data left over from before an upgrade. A card that has been entered recently receives payment method type "stripe_card" and can be reused, no problem. The problem is if you try to reuse a card with payment method type "credit_card," because that type (from commerce_payment module) does not define the isReusable() method.
If you are experiencing this problem, run the following:
`drush sqlq 'UPDATE commerce_payment_method SET type="stripe_card" WHERE type="credit_card"'`
That should fix it. It would be nice to have fixed this in an update hook when the module updated, but that proverbial ship has sailed.
In case anyone else is looking, the issue appears to be this one: https://www.drupal.org/project/slick/issues/3467129 📌 Incompatibility with Drupal 11/jQuery 4 Fixed
I resolved the merge conflict on MR!8.
See MR!16. When there is only one result, it is neither necessary nor desirable to filter and sort. :)
Nope, changing the execution order didn't help, but suspicions point to this commit: https://git.drupalcode.org/project/layout_options/-/commit/713828b8dafb1...
I'm seeing this problem and suspect it may have to do with theme_switcher module needing to run its hooks before this module's hooks. I will try changing the execution order and see if that helps.
@steven jones MR!53 does not incorporate the fix on MR!45. MR!45 is the one we should consider for merge.
Thanks, @maxilein, MR!45 now incorporates that change.
I can confirm that MR!6 can be installed and enabled in Drupal 11.
With the addition of a composer.json file, MR!5 now installs & can be enabled in Drupal 11. Somebody please confirm. Thanks!
benstallings → made their first commit to this issue’s fork.
I can confirm that MR!10 can be installed and enabled in Drupal 11.
benstallings → made their first commit to this issue’s fork.
dev now supports Drupal 11
I can verify that MR!3 can be installed and enabled in Drupal 11.
I made @enchufe's patch into a merge request and can verify that MR!12 can be installed and enabled in Drupal 11.
Changing target version
benstallings → made their first commit to this issue’s fork.
I can verify that MR!97 can be installed & enabled in Drupal 11.
benstallings → made their first commit to this issue’s fork.
I had to add a composer.json file, but then I was able to install & enable this MR in Drupal 11.
benstallings → made their first commit to this issue’s fork.
I can confirm that this MR can be installed and enabled in Drupal 11.
benstallings → made their first commit to this issue’s fork.
benstallings → created an issue.
Updated for alpha 4
I can't vouch for all the functionality, but I was able to install and enable the MR!501 in Drupal 11.
I can't vouch for all of the functionality, but I was able to enable the module in Drupal 11 without error.
benstallings → created an issue.
benstallings → created an issue.
Thanks for catching my mistake, @zeeshan_khan!
@emilorol thanks for the fix. See MR!47.
I'm able to install and enable this in Drupal 11.
I can verify that 2.x-dev is installable with composer in Drupal 11 and can be enabled. Thanks for merging this, @sjerdo!
I can confirm that this installs in Drupal 11 and can be enabled.
I added a composer.json file so that the module can be installed with composer in Drupal 11.
benstallings → made their first commit to this issue’s fork.
I can verify that the project-update-bot-only branch installs in Drupal 11 and can be enabled!
However, I notice there are dire warnings that we are not supposed to change this branch because it can be overwritten at any time. So maybe make a new branch? :)
Thanks, @grevil!
BenStallings → created an issue.
Note that drupalcode indicates this branch has a merge conflict, but that does not appear to actually be the case.
BenStallings → created an issue.
MR!9 installs with composer and can be enabled in Drupal 11. Since the testing errors are on the release branch as well, I'm going to assume they're out of scope of this ticket.
MR!50 installs with composer and can be enabled in Drupal 11. Since the release branch also fails testing, I'm going to consider the testing problem to be outside the scope of this ticket.
It looks like the tests are passing now! With the addition of a composer.json file, the module now installs with composer and can be enabled in Drupal 11. Just need someone else to confirm, please.
BenStallings → made their first commit to this issue’s fork.
This works for me!
MR!15 can now be installed & enabled in Drupal 11.
once I resolved the merge conflict, this worked fine!
BenStallings → made their first commit to this issue’s fork.
BenStallings → created an issue.
OK, should be working now!
needs a composer.json. I'm on it.
It works for me!
Looks like this has been merged! Thanks, lussoluca!
BenStallings → made their first commit to this issue’s fork.
BenStallings → made their first commit to this issue’s fork.
It works!
BenStallings → made their first commit to this issue’s fork.
BenStallings → made their first commit to this issue’s fork.
BenStallings → made their first commit to this issue’s fork.
MR!10 adds a composer.json so that the fork can be installed with composer.
When I try to install this with composer, I get
No valid composer.json was found in any branch or tag of https://git.drupalcode.org/issue/email_confirmer-3451035, could not load a package from it.
No luck, mradcliffe... with my composer.json repositories set up like so
{
"type": "vcs",
"url": "https://git.drupalcode.org/issue/theme_switcher-3434980.git"
},
{
"type": "composer",
"url": "https://packages.drupal.org/8"
}
I get
$ composer require drupal/theme_switcher:3434980-gitlabci-dev
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires drupal/theme_switcher 3434980-gitlabci-dev, found drupal/theme_switcher[dev-8.x-1.x] but it does not match the constraint.
OK, somebody else please test my MR!20. Thank you!
I spoke too soon, this still needs work:
web/modules/contrib/geofield_map/src/Form/GeofieldMapSettingsForm.php 151 Call to deprecated function format_size(). Deprecated in drupal:10.2.0 and is removed from drupal:11.0.0. Use Drupal\Core\StringTranslation\ByteSizeMarkup::create($size, $langcode) instead.
web/modules/contrib/geofield_map/geofield_map.info.yml 3 Value of core_version_requirement: ^9.3 || ^10 is not compatible with the next major version of Drupal core. See https://drupal.org/node/3070687.
web/modules/contrib/geofield_map/modules/geofield_map_extras/geofield_map_extras.info.yml 3 Value of core_version_requirement: ^8.8 || ^9 || ^10 is not compatible with the next major version of Drupal core. See https://drupal.org/node/3070687.