🇳🇱Netherlands @ndf

Instead of try/catch, named parameters would be a better IMO. With the order of Commerce 3.x

$event = new CustomerProfileEvent(order_item: $order_item, customer_profile: $customer_profile);

PHP 8 is required for this, which is already declared in composer.json.

3.x constructor of Drupal\commerce_tax\Event\CustomerProfileEvent.php

/**
  * Constructs a new CustomerProfileEvent.
  *
  * @param \Drupal\commerce_order\Entity\OrderItemInterface $order_item
  *   The order item.
  * @param \Drupal\profile\Entity\ProfileInterface|null $customer_profile
  *   The initially selected customer profile, NULL if not yet known.
  */
public function __construct(OrderItemInterface $order_item, ?ProfileInterface $customer_profile = NULL) {
  $this->orderItem = $order_item;
  $this->customerProfile = $customer_profile;
}

2.4 constructor of Drupal\commerce_tax\Event\CustomerProfileEvent.php

/**
   * Constructs a new CustomerProfileEvent.
   *
   * @param \Drupal\profile\Entity\ProfileInterface $customer_profile
   *   The initially selected customer profile.
   * @param \Drupal\commerce_order\Entity\OrderItemInterface $order_item
   *   The order item.
   */
  public function __construct(ProfileInterface $customer_profile = NULL, OrderItemInterface $order_item) {
    $this->customerProfile = $customer_profile;
    $this->orderItem = $order_item;
  }

This is actually fixed in the DEV version in this commit:

https://git.drupalcode.org/project/commerce_avatax/-/commit/d79662a0685b...

    try {
      // Allow the customer profile to be altered, per order item.
      $event = new CustomerProfileEvent($customer_profile, $order_item);
    }
    catch (\Throwable $t) {
      // The order of parameters changed in Commerce 3, this is our way of
      // supporting both versions.
      $event = new CustomerProfileEvent($order_item, $customer_profile);
    }

Now knowing this, I think we should either set commerce:^2.0 as requirement on the stable version of commerce_avatax. Or up the stable version to include the support of both commerce core version in the stable branch of commerce_avatax.

Without it one cannot add items to the cart with commerce_avatax stable + commerce_core 2.0

Problem/Motivation

When a product is added to the cart (i.e., a brand-new order is created in "draft" state), there are no billing or shipping profiles
available on the order. Drupal Commerce’s Order::collectProfiles() method thus returns an empty array. The AvaTax module attempts to resolve a shipping/billing profile, but encounters a null (empty) profile and subsequently triggers an error:

TypeError: Drupal\commerce_tax\Event\CustomerProfileEvent::__construct(): Argument #1 ($order_item) must be of type Drupal\commerce_order\Entity\OrderItemInterface, null given, called in /var/www/html/docroot/modules/contrib/commerce_avatax/src/AvataxLib.php on line 509 in Drupal\commerce_tax\Event\CustomerProfileEvent->__construct() (line 38 of /var/www/html/docroot/modules/contrib/commerce/modules/tax/src/Event/CustomerProfileEvent.php).

This issue arises specifically during the add-to-cart action, prior to any checkout steps that collect billing or shipping addresses.

Steps to reproduce

1 Install and enable Drupal Commerce 2.x and commerce_avatax.
2 Configure AvaTax settings.
3 Add a product to the cart (or create a new order with no shipping/billing information).
4 Observe the error, as no profiles exist on the brand-new draft order at that stage.

Proposed resolution

• Update AvaTax’s AvataxLib::prepareTransactionsCreate() logic to gracefully handle cases where a shipping or billing profile is not yet present on the order item. This prevents a null reference from being passed to CustomerProfileEvent.
• Alternatively, add checks in resolveCustomerProfile() to ensure that an empty profile is skipped if it doesn’t exist.

Remaining tasks:

• [ ] Discuss how AvaTax expects to handle orders at an early "add to cart" stage.
• [ ] Decide whether focus should be on gracefully handling missing profiles or preventing AvaTax from being applied to incomplete draft orders.
• [ ] Provide patch or merge request in the commerce_avatax repository.
• [ ] Write tests confirming that the order can still be placed into the cart with no fail when no billing/shipping profile is present.

API changes:

None anticipated. The solution only adds safety checks around order item profiles.

Data model changes:

None anticipated.

Additional information:

• This behavior is consistent with Drupal Commerce 2.x, as new orders initially have no stored address profile.
• The error occurs only when the AvaTax integration tries to calculate tax for a brand-new order with no addresses.

https://git.drupalcode.org/project/prepopulate/-/merge_requests/5.diff contains the change to USAGE.md which is RTBC.
It would be nice if the maintainer can merge that change.

The tests are still to do.

ndf → created an issue.

This is more difficult than I expected.
I copied the gitlab-ci template from https://www.drupal.org/project/commerce_paypal →

Apart from codestyle issue, the functional test now all fail.

Hi Thomas, thank for the patch.

On first sight it looks good to me.

I noticed that the automated tests don't run. Just now I created 📌 Commerce Mollie GitLab CI for automated tests Active to fix this.
The automated test suite has test-coverage for the payments states handling that is changes in this ticket. So we for merging the test-suite is a blocker.

ndf → created an issue.

Thank you all.
Just merged #10 + #3 in a new release branch 7.x-2.x and a tagged release 7.x-2.0
Additionally deleted the deprecated V1 API that was shipped with the module.

Important & Critical Change

• Added “Libraries” and “X Autoload” as required dependencies
  Previously, these modules were listed in the README as requirements for the Mollie API, but were not strictly enforced. In this release, we have updated the module’s .info file to mark Libraries and X Autoload as hard dependencies. This ensures proper loading of the Mollie API library and avoids errors or missing class autoloading.

Please ensure you have both Libraries and X Autoload installed and enabled before upgrading to or installing this version.

https://www.drupal.org/project/commerce_mollie/releases/7.x-2.0 →

Another question; doesn anyone know there drop-in replacements from other providers? For example PayPal.

Module maintainer here.

Just set the priority to critical.

Thanks for the patches and the work done!

With the patches the Mollie-api must be installed with Composer. Composer is not available for many Drupal 7 projects.
I am not sure if we can install the Mollie-api standalone without Composer. If that is possible, it would be better IMO and we can ship the v2 api with the module code.

Additionally is there anything else that needs to be reconfigured when moving to v2? For example new api-keys.

FYI A client sent us this Mollie mail today:

Mollie API V1 zal worden uitgeschakeld

De V1-versie van de Mollie API bereikte zijn einde van de levensduur in juli 2023 en zal volledig worden uitgeschakeld op 31 december 2024.

Alle klanten die nog de Mollie API V1 gebruiken, moeten upgraden naar onze huidige V2-versie. Het wordt sterk aanbevolen om zo snel mogelijk te upgraden om eventuele impact te voorkomen.

Zie onderstaande FAQ voor meer informatie.

Hoe weet ik of ik nog de Mollie API V1 gebruik?

 

Elke betaling die via de Mollie API V1 is gedaan, zal een melding hebben in het Mollie Dashboard op de betaling-pagina.

 

Hoe upgrade ik naar de Mollie API V2?

 

Maakt u gebruik van een platform (zoals een webshop systeem) of een integratie/plugin? Neem dan contact op met de aanbieder. Zij kunnen u helpen om te upgraden naar Mollie API V2.

Als u een directe integratie met de Mollie API heeft, kunt u uw code updaten om de V2 API te gebruiken. Meer informatie over de technische veranderingen tussen V1 en V2 is beschikbaar in onze technische documentatie.

I have this bug too, no fix, but to debug I use this snippet.
This does allow for the View to load.
In my case after the views_migration the relationship for Flag and VotingApi are not correctly migrated and broken.

# \Drupal\views\Plugin\views\query\QueryPluginBase::getEntityTableInfo

    // Include all relationships.
    foreach ((array) $this->view->relationship as $relationship_id => $relationship) {
      // Start issue #3458813 Comment #6
      if ($relationship->pluginId === 'broken') {
        // Log a warning if the relationship is broken.
        \Drupal::logger('views')->warning('The relationship %relationship is broken.', ['%relationship' => $relationship_id]);
        continue;
      }
      // End issue #3458813 Comment #6
      $table_data = $views_data->get($relationship->definition['base']);
      if (isset($table_data['table']['entity type'])) {

ndf → created an issue.

Thanks for the patch, it does prevent the WSOD.

ndf → made their first commit to this issue’s fork.

Just now I tested the media_migration with a standard drupal 7 installation; and then the image field is migrated to a media field.

As expected because of the media_migration module description: "Image and file fields of the Drupal 7 source instance are migrated as media reference fields in Drupal 8|9|10."

So my case above in [3302125#comment-15866766] is a bug that happens is certain cases.

We have a similar (or same issue) on a migration from Drupal 7 to Drupal 9.5 with media_migration 1.x-dev (of today d369908a)

Problem/Motivation

• Media entities are successfully created for image fields.
• On the node level, the image field remains as an image field (type file) instead of being converted to a media reference field (type entity_reference).
• The image field on the node is empty and does not reference the migrated media entities.

Expected Behavior

• The image field should be transformed into a media reference field.
• The field should reference the corresponding media entities.

Steps to Reproduce

1. Migrate nodes with image fields using media_migration.
2. Check the destination node fields after migration.

Proposed Resolution

Update the migration process to properly transform image fields into media reference fields and link them to migrated media entities.

Tested this manually and this works in our migrations.

```
diff --git a/entityreference_migration.module b/entityreference_migration.module
index d0b8e61..3529095 100644
--- a/entityreference_migration.module
+++ b/entityreference_migration.module
@@ -286,6 +286,9 @@ function _entityreference_migration_references_field_to_entityreference_field_cr
'handler' => 'base',
'handler_settings' => array (
'target_bundles' => $target_bundles,
+ 'sort' => array(
+ 'type' => 'none',
+ ),
),
'handler_submit' => 'Change handler',
'target_type' => $target_type,
--
```

ndf → created an issue.

Hi, I still want to take over ownership.

@forestmars can you add me as maintainer?

Awesome! Thanks

Hi avpaderno, we forgot to tag the existing articles for the DrupalPlanet feed :/
But now that is done. https://codelift.ai/planet/feed has been updated.

There are 4 articles in the feed that are relevant and interesting for DrupalPlanet.

Hopefully this is now all fine.

Sorry, I used the wrong template.

This request is meant to add the feed to Drupal Planet.

ndf → created an issue.

Link to project: https://www.drupal.org/project/twigify →

Hi FM and avpaderno,

I (ndf) would still like to do the maintainership for the Twigify module. Actually I run a fork of the module and activate use that.

Last year in November I had contact about this with Cameron Tod, but I got lost track of the mails and forgot to make the follow-up changes in the issue queue.

So please, if possible, make me the maintainer of the Twigify module.

Thanks in advance, Niels (ndf)

Jean-Paul Vosmeer → credited ndf → .

While running the migration (import) you can patch web/core/modules/image/image.module with

  if ($entity->isSyncing()) {
    return;
  }

  // Added temporary fix for #3306941.
  if (!is_array($default_image) || !isset($default_image['uuid'])) {
    return;
  }
  // End fix #3306941.

  $uuid = $default_image['uuid'];

BramDriesen → credited ndf → .

@Keshev Patel, thanks for the MR. Can you please explain why you opted for the required parameter solution? This is helpful for other people to review your MR.

ndf → created an issue.

ndf → created an issue.

ndf → created an issue.

@diqidoq Hi I just created https://www.drupal.org/project/popperjs → . It is a drop-in replacement for library core/popperjs
To use it install the module and in *.libraries.yml replace core/popperjs with popperjs/popperjs

ndf → created an issue.

Instead of refactoring to a new library I created the module https://www.drupal.org/project/popperjs → which contains the library popperjs/popperjs.

This bug report is based on comment #23 from mihai_brb in 📌 Automated Drupal 10 compatibility fixes Fixed

ndf → created an issue.

Just stumbled on this one when working on 🐛 Select2 css not applied inside off-canvas because Drupal core reset.css removes it (since Drupal core 10) Active

Does someone knows a workaround that can be used?
Maybe a method to replace core reset.css with an application specific one.

And imagine we have the exclusion class. How will the css of contrib look? Something like this:

button.contrib-module {border: 2px solid grey}
.drupal-off-canvas-wrapper-noreset button.contrib-module {border: 2px solid grey}

Wouldn't that mean that all contrib css that might be rendered inside the off-canvas must be duplicated with the exclusion class prefixed. 🤔

ndf → created an issue.

Hi kristiaanvandeneynde, RTBC it's finally happening!

What a major accomplishment for you personally and a great gift to the wider Drupal community.
I know you have been working on this for years (2016? 📌 Add a container parameter that can remove the special behavior of UID#1 Fixed , ✨ Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter() Needs work ) and you kept on going and find your way.

Thanks a lot!

ndf → created an issue.

ndf → created an issue.

The fix is merged and included in release https://www.drupal.org/project/public_preview/releases/8.x-1.0 →

composer require 'drupal/public_preview:^1.0'

I merge the changes in the info file, but I remove the separate dependencies in this module's composer.json.

Why;
- ext-PDO
- symfony/dependency-injection
- symfony/http-kernel

are all dependencies of drupal core, so it's simpler to rely on the core dependency.

Thanks guys!

ndf → created an issue.

Thanks Kristen!

Yes, good improvement

Looks good to me.
I didn't do a manual check though.

Sure! Great you want to help here colinstillwell

I'll add you as co-maintainer.

I noticed your recent PRs are for the 7.x branch,
Are you planning to work on the current branch too? (8.x, which is compatible with Drupal 9 and 10).

The MR only sorts by id, when the queue_order module is not installed.

ndf → created an issue.

Hi alain_bastard_csf, I cannot reproduce your issue. With core 9.5.3 and module 8.x-1.2
I did install the module and logged in multiple browsers with different accounts.

This test-site has the following cache modules enabled: Internal Page Cache, Internal Dynamic Page Cache.
I also cannot reproduce it with only Internal Page Cache enabled.
And I cannot reproduce it with only Internal Dynamic Page Cache enabled.

That's a cache issue indeed. The problem you describe was fixed a couple of years ago in https://git.drupalcode.org/project/welcome_username/-/commit/fa52d823c79...

What Drupal core version are you on?
And what version of this module are you on?

It's not in the 1.10 release of today, but only in the develop branch.
So that people have time to test this on their multi-language websites.

Thanks mvdve, I just committed the patch as is.

After the patch we have this updated test:

@@ -167,7 +167,7 @@ class MolliePaymentOffsiteFormTest extends CommerceBrowserTestBase {
     $this->assertEquals('2', $last_transaction['metadata']['order_id']);
     // The commerce locale resolver tacks the current language to the store
     // country.
-    $this->assertEquals('fr_US', $last_transaction['locale']);
+    $this->assertEquals('fr_FR', $last_transaction['locale']);
     $this->assertEquals($this->store->getName() . ' order 2', $last_transaction['description']->__toString());
   }

where indeed fr_FR seems a lot better as default then fr_US.
This happens when a customer buys a product on the following url: /fr/product/1

Thanks!

It's in this new 2.10 release [#2261853]

Hi svendecabooter, thanks you want to help maintaining this module. I have just given you the maintainer permissions.

Regarding this patch, I have one question regarding the change in the getNotifyUrl method.
Can you please check that?

@mvdve what do you think from my comment above?

Another thought; the supported list on Mollie is:
Possible values: en_US en_GB nl_NL nl_BE fr_FR fr_BE de_DE de_AT de_CH es_ES ca_ES pt_PT it_IT nb_NO sv_SE fi_FI da_DK is_IS hu_HU pl_PL lv_LV lt_LT

We now not have en_GB nl_BE fr_BE de_AT (and probably more)

What if we keep the commerce.current_locale logic for the making the locale code,
but if it's not in Mollie's supported list we remove it.
So when the lang-code is not in the valid list, we don't send $transaction_data['locale'].
Then the following happens: When this parameter is omitted, the browser language will be used instead if supported by the payment method.

mvdve, this looks good thanks.
One more question. What is the reason to use \Drupal::languageManager() instead of \Drupal::service('commerce.current_locale')

The default locale resolver of commerce seems to do a very similar thing see \Drupal\commerce\Resolver\DefaultLocaleResolver::resolve

  public function resolve() {
    // The getCurrentLanguage() fallback is a workaround for core bug #2684873.
    $language = $this->languageManager->getConfigOverrideLanguage() ?: $this->languageManager->getCurrentLanguage();
    $langcode = $language->getId();
    $langcode_parts = explode('-', $langcode);
    if (count($langcode_parts) > 1 && strlen(end($langcode_parts)) == 2) {
      // The current language already has a country component (e.g. 'pt-br'),
      // it qualifies as a full locale.
      $locale = $langcode;
    }
    elseif ($country = $this->currentCountry->getCountry()) {
      // Assemble the locale using the resolved country. This can result
      // in non-existent combinations such as 'en-RS', it's up to the locale
      // consumers (e.g. the number format repository) to perform fallback.
      $locale = $langcode . '-' . $country;
    }
    else {
      // Worst case scenario, the country is unknown.
      $locale = $langcode;
    }

    return new Locale($locale);
  }

Lets add a comment that we intentionally not use that resolver.

I'll do that on commit.

With the example: drupal installation in German, visitor is in the Netherlands,
what would be the correct langcode for Mollie?

Is it a correct assumption that the langcode is used by mollie to display their dialogs in the visitor language?
If that's the case indeed the drupal interface-language should be used.

NB we have a test that now fails \Drupal\Tests\commerce_mollie\Functional\MolliePaymentOffsiteFormTest::testPaymentTransactionData
which assumes the following:

    $language = ConfigurableLanguage::createFromLangcode('fr');
    $language->save();
// ... doing a transaction ...
    // The commerce locale resolver tacks the current language to the store
    // country.
    $this->assertEquals('fr_US', $last_transaction['locale']);

So this was actually all the time wrong and it should be:
$this->assertEquals('fr_FR', $last_transaction['locale']);
Is that correct?

Committed fixes for this and created a new release https://www.drupal.org/project/unused_modules/releases/8.x-1.5 →

I checked the bamboo twig module locally ($ composer require drupal/bamboo_twig), but I cannot reproduce the problem.

The error you see is triggered here:

// Remove "drupal/" prefix for Drupal modules, because that breaks
// the table output in the report.
if (!str_starts_with($packageName, 'drupal/')) {
  $error_message = "Could not parse Composer information for module '" . $module->getName() . "'";
  throw new UnusedModulesException($error_message);
}

Do you have anything special with the composer setup? Symlinks or complete git checkout for each modules?

The only common thing I found is they all are located in a sub-folder below the main module.

Right now composer installated sub-modules are only found within following directory structure: <MODULE_NAME>/modules/<SUB_MOBULE_NAME>.
An example that works: web/modules/contrib/PARAGRAPHS/modules/PARAGRAPHS_DEMO for the paragraphs module.

Can you please share the paths and the way how to install these modules/extensions? That way it can be debugged.

It is a php 8.1 deprecation error.
Good to fix it.

Committed and a release containing the Drupal 10 support will be there any moment.

Thanks guys,
on commit I changed the logic a little bit so that submodules of packages are reported correctly.

Tested:
- composer require drupal/paragraphs -> all submodules in report
- composer require non-drupal package -> not in report
- composer require drupal package, but overridden (local development unused module) -> not in report

The following composer:

"require": {
    "php": "~8.1.0",
    "composer/installers": "^1.9",
    "cweagans/composer-patches": "^1.7",
    "danielstjules/stringy": "^3.1",
    "drupal/admin_toolbar": "^3.3",
    "drupal/asset_injector": "dev-2.x",
    "drupal/core": "^9.5",
    "drupal/core-composer-scaffold": "^9.5",
    "drupal/paragraphs": "1.x-dev",
    "drupal/unused_modules": "*",
    "drush/drush": "^11.0",
    "vlucas/phpdotenv": "^5.1",
    "webflo/drupal-finder": "^1.2"
},
"repositories": {
    "unused_modules": {
        "type": "path",
        "url": "/Users/ndf/WebWork/DrupalModules/unused_modules"
    },
    "drupal": {
        "type": "composer",
        "url": "https://packages.drupal.org/8"
    }
},

The result:

08:55 $ drush um modules all
 [warning] Message: Could not parse Composer information for module 'unused_modules'

+----------------------------+-----------------------------------+----------------+-----------------------------+--------------------------------------------+
| Project                    | Module                            | Module enabled | Project has Enabled Modules | Project Path                               |
+----------------------------+-----------------------------------+----------------+-----------------------------+--------------------------------------------+
| _NO_PROJECT_INFORMATION_   | unused_modules                    | Yes            | Yes                         |                                            |
| admin_toolbar              | admin_toolbar                     | Yes            | Yes                         | modules/contrib/admin_toolbar              |
| admin_toolbar              | admin_toolbar_links_access_filter | No             | Yes                         | modules/contrib/admin_toolbar              |
| admin_toolbar              | admin_toolbar_search              | No             | Yes                         | modules/contrib/admin_toolbar              |
| admin_toolbar              | admin_toolbar_tools               | Yes            | Yes                         | modules/contrib/admin_toolbar              |
| asset_injector             | asset_injector                    | No             | No                          | modules/contrib/asset_injector             |
| entity_reference_revisions | entity_reference_revisions        | No             | No                          | modules/contrib/entity_reference_revisions |
| paragraphs                 | paragraphs_demo                   | No             | No                          | modules/contrib/paragraphs                 |
| paragraphs                 | paragraphs_library                | No             | No                          | modules/contrib/paragraphs                 |
| paragraphs                 | paragraphs_type_permissions       | No             | No                          | modules/contrib/paragraphs                 |
| paragraphs                 | paragraphs                        | No             | No                          | modules/contrib/paragraphs                 |
+----------------------------+-----------------------------------+----------------+-----------------------------+--------------------------------------------+