never mind, this has been fixed in dev already.
benstallings → created an issue.
The submodules also need their core_version_requirement updated.
I'm now seeing,
Call to deprecated method generateImageStyle() of class Drupal\flysystem_s3\Flysystem\S3. Deprecated in flysystem:2.2.0 and is removed from flysystem:3.0.0. Adapters should use generateImageUrl() to enable non-blocking image uploads.
on line 227 of S3.php. I'll see if I can fix it.
When I try to run eck_make_type_revisionable(), I get
The entity type report_template does not have an "revision_created" entity revision metadata key."
This occurs on the final line of the function, $definition_update_manager->updateFieldableEntityType($entity_type, $field_storage_definitions, $sandbox); even though revision_created is defined in both of the variables.
benstallings → created an issue.
Thanks to both of you! I just incorporated your patches into a MR.
benstallings → made their first commit to this issue’s fork.
Thanks for all your work on this! It looks really promising.
After patching the current 2.x dev with this, I had a duplicate preSave() method in EckEntity.php.
After deleting the duplicate, I get
The entity type facility does not have an "revision_created" entity revision metadata key.
when running any drush command. (This is a site that has existing ECK entity types.)
benstallings → made their first commit to this issue’s fork.
I was not able to inject the dependency in CustomFieldFormatterManager because I don't fully understand what's going on there.
I did not inject the dependency in CustomFieldDate because that part of the code is already deprecated.
benstallings → created an issue.
Thanks, @gausarts! Setting a skin in the field display formatter did the trick.
benstallings → created an issue.
Hi, @DYdave. I am no expert on this issue, unfortunately. My (limited) understanding is that once a class implements create(), it is preferable for any extending class to also use create() and not re-implement __construct(). Unless, that is, it uses AutowireTrait, in which case you want to implement __construct() and not create()! https://www.drupal.org/node/3396179 → It's a dilemma. I defer to the judgment of someone who better understands the goals of this particular module.
@dieterholvoet I wound up just writing custom code to solve my immediate need rather than using this module, so I don't know, sorry!
benstallings → created an issue.
benstallings → created an issue.
benstallings → created an issue.
benstallings → created an issue.
benstallings → created an issue.
benstallings → created an issue.
unassigning myself for review
benstallings → created an issue.
OK, MR !68 should now pass phpstan level 0 with no changes in functionality.
benstallings → created an issue.
Oops, I see this is fixed already in 2.1. Never mind!
benstallings → created an issue.
Thank you for this, @peter törnstrand!
I updated this to work with 4.2 and made a merge request.
benstallings → made their first commit to this issue’s fork.
Great work, @apmsooner, that works perfectly as far as I can tell. Thank you!
@dieterholvoet thank you for pointing that out! I'll see if I can adapt that 2.0 fix for 3.0. Let's leave this ticket open until we have a 3.0 fix.
This appears to be fixed in 5.5.0.
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.