🇫🇷France @GuillaumePacilly

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

Thanks for the release !

Sorry I was not very clear, I meant to improve the handling of saferpay error to rpvoide better feedback to the customer, like on cancellation by example. I started a new issue with a quick suggestion here: https://www.drupal.org/project/commerce_saferpay/issues/3522722 ✨ Improve Saferpay response error handling Active

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

Duplicate of https://www.drupal.org/project/field_group/issues/3491233 🐛 Drupal 10.4 RC1 error with field_ui.js Active .
Fixed on 4.x

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

Updated patch for 5.1 with additional clean up.

I know this was long merged, but we are still using 5.1 version for now to avoid migration to bootstrap 5.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

Thanks! we checked again and the error is gone, probably due to our own environment. Closing the issue

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

guillaumepacilly → created an issue. See original summary → .

Thanks :-)

Thanks for the update!

I agree with your approach.
But the single return URL also makes it difficult to properly catch failed or cancelled payments.
I would like to add an Handler to at least catch cancellation from the user and redirect him properly.

But I would prefer creating a separate issue and MR for this, based on this one.
Do you think this can be merged soon? Or should we work directly on this MR?

guillaumepacilly → created an issue.

Issue was unrelated, changes are not necessary

I am using version 1.0.0-beta3, but the issue is on all version, including 2.x

guillaumepacilly → created an issue.

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

Hi @beunerd

I ran into the same issue. I checked the core issue → you mentioned

While it indeed looks like a core issue, I feel unconfortable to patch core this way, as it could have an impact on many other things.

Other modules had a similar issues and suggested that each module should be responsible to deliver properly formatted value to the WidgetBase, see https://www.drupal.org/project/eca/issues/3457773#comment-15699522 🐛 An error occurred while trying to build an inline entity from submitted form values Fixed

I have create a MR with this approach, what do you think?

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

guillaumepacilly → created an issue.

guillaumepacilly → created an issue.

@tcrawford I have created the MR with your suggested changes and added an api.php file to provide some example.

I added an index variable to the hooks to facilitate the order_items array manipulation, let me know if you have a better idea.

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

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

Applied patch modifications into a MR and cleaned up references and annotations.

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

Applied original patch modifications to MR

guillaumepacilly → changed the visibility of the branch 3476192-fix-must-be to hidden.

guillaumepacilly → created an issue.

@DiDebru thanks for your update, worked fine for me! I added your changes to the MR of this issue, and added another hook to alter payment page initialization data as I need it on my projects.

guillaumepacilly → created an issue.

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

Thanks for the patch!
Updated for Commerce 2.4

guillaumepacilly → changed the visibility of the branch 3425346-views-caching-provide to hidden.

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

GuillaumePacilly → created an issue.

GuillaumePacilly → created an issue.

GuillaumePacilly → created an issue.

GuillaumePacilly → created an issue.

I had the same need and solved it by using custom tokens. Then you can apply conditions inside your hook_tokens().

/**
 * Implements hook_token_info().
 */
function mymodule_token_info() : array {
  $info = [];

  $info['types']['my_custom_tokens'] = [
    'name' => t('Custom Tokens'),
    'description' => t('Tokens available for specific use on this website'),
  ];

  $info['tokens']['my_custom_tokens']['custom_token'] = [
    'name' => 'Custom token',
    'description' => t('Custom token with conditions'),
  ];

  return $info;
}

/**
 * Implements hook_tokens().
 */
function mymodule_tokens($type, $tokens, array $data, array $options, BubbleableMetadata $bubbleable_metadata) : array {
  $replacements = [];

  if ($type == 'my_custom_tokens') {
    foreach ($tokens as $name => $original) {
      switch ($name) {
        case 'custom_token':
            $node = $data['node'];
            // Add your logic here.

            $replacements[$original] = $title;
          }

          break;

        default:
          break;
      }
    }
  }

  return $replacements;
}

Then just use your custom token in the auto_entitylabel configuration

@Drupalengue I added a MR with a possible approach. It gives the opportunity to activate or not the popup features for each ief widget.

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