🇳🇱Netherlands @ndf

Hi, I've updated the patch.

Now 1 thing is changed; the addition of the expanded property.

In the original #3 patch there were some extra lines removed, probably unintentionally.

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

Thanks for the report and the bug fix!

Pushed to branch 8.x-1.x and a new tagged release 8.x-1.12 "Bug fix for version 8.x-1.11 + Commerce 2.x"

https://www.drupal.org/project/commerce_mollie/releases/8.x-1.12 →

Hi Serhii, yes ip2country module sounds like a better option! So that module already has the IP country data in it and fetches it regularly from ARIN.

Then we need a module that combines both; i.e. 'advban_ip2country' with a UI for administrators to select banned countries, and code that fetches the country ip-ranges from the ip2country module.

ndf → created an issue.

I ended up by overriding \Drupal\file\Plugin\migrate\source\d7\File::initializeIterator()

That methods reads the public and private paths from variables in the source (Drupal 7) database. And these are then used to process the file migrations. And that triggered to this error:

 message = "file_copy: File '/pdf-file.pdf' does not exist"
 *Exception*string = ""
 code = {int} 0
 file = "/var/www/html/docroot/core/modules/migrate/src/MigrateExecutable.php"
 line = {int} 462
 *Exception*trace = {array[19]} 
 *Exception*previous = null
 level = {int} 1
 status = {int} 3
$id_map = {Drupal\migrate_tools\IdMapFilter} 
$msg = "d7_file_private:uri:file_copy: File '/pdf-file.pdf' does not exist"

Instead I override it with hardcoded paths. In the example below the original code in still in place for reference.

# docroot/core/modules/file/src/Plugin/migrate/source/d7/File.php
# \Drupal\file\Plugin\migrate\source\d7\File::initializeIterator
/**
 * {@inheritdoc}
 */
protected function initializeIterator() {
  $this->publicPath = $this->variableGet('file_public_path', 'sites/default/files');
  $this->privatePath = $this->variableGet('file_private_path', NULL);

  // Patch start: override public and private paths with ddev mounts inside the target container.
  $this->publicPath = '/var/www/html/drupal7_migration_mounts/public_mount';
  $this->privatePath = '/var/www/html/drupal7_migration_mounts/private_mount';
  // Patch stop: override public and private paths with ddev mounts inside the target container.

  return parent::initializeIterator();
}

Thomas, the test-suite of the module now works (again) 📌 Commerce Mollie GitLab CI for automated tests Active and Commerce v3 support is added 📌 Commerce 3.0 campatibility Active

Can you check if you still experience the bug?

NB The patch right now makes the test-suite fail, because of a mismatch of states ('authorization' vs 'new' and possibly more differences).

/rebase

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?