🇺🇦Ukraine @gilmord

I have contacted maintainer with SA permission, lets see what he thinks on this

To do that we need maintainer with permission to opt project under SA to enable this on project edit

Looks like @joelpittet has it

SA will allow posting security issues and maintainers have to react on it during a week

@TomTech in the payment intent I see the payment method ID in the stripe dashboard, when I go to /logs and search by the payment method ID I only see one log from Stripe:

It says:

card_declined
The card returned a decline code of generic_decline and did not provide any additional details.

The customer may need to contact their card issuer for more information.

And body is:

{
  "error": {
    "code": "card_declined",
    "decline_code": "generic_decline",
    "doc_url": "https://stripe.com/docs/error-codes/card-declined",
    "message": "Your card was declined.",
    "param": "",
    "request_log_url": "https://dashboard.stripe.com/logs/req_XXXXXX",
    "type": "card_error"
  }
}

Let me tell again the entire flow, I will try to reproduce step by step what is happening to me:
- on checkout page I enter card details with wrong CVV code
- I click pay
- immediately in my banking application I see attempt to pay, which is canceled with "Wrong CVV message"
- right after that I see one more payment in my banking app, which is success
- in Drupal I receive request from Stripe with "card_declined" code
- as Card is declined - commerce tries to redirect me to order information step, but I see the error there InvalidArgumentException: Invalid credit card type ""
- this is because payment method was not created
- I fixed this error for myself - I just comment this lines so at least I do not see error
- now I am redirected to the order information step with "Card declined" (something like that) validation message
- order stays Draft for me
- in stripe logs I see the error I pasted at the top of this message
- in stripe transactions I see successful transaction for this order

@vmarchuk i contacted stripe support - there is no way to reproduce this in a test mode using test cards

I was able to reproduce it with a real card in a live mode only

I can not consider forcing cvv check as potentially we can loose clients
"User pays and order stays unpaid in drupal" is better for business then "user tries to pay, see validation error and leave the site instead of trying to pay again"

Also according to what Stripe support said there is something wrong on our side - there is one payment which fails and returns to drupal "card_declined" and after that is the next payment which triggers 3d secure and is success

Please check conversation in the discord support chanel

@TomTech I am trying to find out more details on this issue in the Stripe Discord channel, here the link to the conversation, maybe support or other developers will give any advises:

https://discord.com/channels/841573134531821608/841573134531821616/12714...

@

So debugging this process I see the exception "Your card was declined" thrown in the stripe SDK:

{
"error": {
"code": "card_declined",
"decline_code": "generic_decline",
"doc_url": "https://stripe.com/docs/error-codes/card-declined",
"message": "Your card was declined.",
"param": "",
"request_log_url": "https://dashboard.stripe.com/logs/req_XXXXXX?t=XXXXXXX",
"type": "card_error"
}
}

After that the Card::buildLabel is invoked and tries to CreditCardHelper::getType but $payment_method->get('stripe_card_type')->getString() that is passed as param is empty, so no credit card type and exception Invalid credit card type ""

If I fix this manually for test, just commenting exception and returning in CreditCardHelper::getType something like $types['mastercard'] - there is no whitescreen error for the user instead he is redirected to checkout/XXXXX/order_information with the message "Payment failed at the payment server. Please review your information and try again."

Here is a Stripe doc saying it is ok if CVV fails and payment is successful, also the same is true for postal code verification

So on the Stripe side all is OK but Drupal module is not ready to handle this cases

What I am not sure is ok - why are there two payments in my banking account, one is failed with "CVV invalid" message and one is successful. Is it how Stripe and banking works or should I be concerned - not sure

Setting to "Active" from "Postponed (maintainer needs more info)", I think we have enough details now

@TomTech I was able to reproduce this issue by accident

I was testing other functionality

So on credit card form I:
- filled card number and date using google chrome stored cards suggestions
- I did not check if CVV was entered, and I have dynamic CVV (updated every 30 minutes) configured on my credit card
- I clicked Pay
- I saw popup with spam check "are you human?" and clicked checkbox
- I see error page on this URL /checkout/XXXXXX/review/return?payment_intent=pi_XXXXXB&payment_intent_client_secret=pi_XXXXX&redirect_status=succeeded as a drupal user
- error is "Invalid credit card type "" in Drupal\commerce_payment\CreditCard::getType() (line 31 of /var/www/html/web/modules/contrib/commerce/modules/payment/src/CreditCard.php)."
- as a user I stay on error page with order being Draft and not paid/placed
- in stripe I see that all is good and paid
- in my banking app I see one error charge "wrong CVV" and one success charge right after it

Also I was thinking on 3d secure issue, as those orders mostly have 3d secure, but I can see two orders in stripe, both with 3d secure and exact same "Events and logs" in Stripe dashboard, one is Paid in Drupal with payment method and the other is not and no payment method

I use the "Stripe Payment Element"
I tried to check if the payment method was reused or new (it looks like new but I can not confirm) and I noticed a strange thing - for the broken orders (and currently I see like 6 of them for the past few weeks) there is no Payment Method in Drupal. I see the payment methods for the orders paid both in Stripe and Drupal.

I did not dig into it (yet) - maybe a payment method is created when order is paid and this is why no PM (as order stays unpaid in Drupal), but maybe this is part of the problem. Maybe PM is not created due to PHP error I mentioned in the issue.

Can you provide the webhook event type for the events that are being skipped with this message?

• payment_intent.succeeded
• payment_intent.payment_failed
• charge.refunded

Are you seeing some successful events, or are you seeing all SKIPPED?

I see only one in "Success" status, which looks like we can ignore it, all the other are SKIPPED

Is the Stripe account used exclusively by Drupal Commerce, or are payments created in other applications/systems?

Only Drupal is used for this Stripe account

This issue looks really strange to me, I am going to debug the process of "payment - webhook - corn" to see where and why it is skipped, I will get back with more details after that.

This is strange it happens to me only, or maybe no one else checks the webhook logs, as for the users all looks ok - payment accepted, order is paid, and in the Stripe dashboard all looks good also.

Thanks all

gilmord → created an issue.

gilmord → created an issue.

Not sure why this is postponed and why it needs more info. Views display plugins can return anything as a row property, it can be any contrib or custom module, and there is @todo in code to make it customizable - Merge Request adds this feature.

You can use it as a patch like this:
https://git.drupalcode.org/project/rest_export_nested/-/merge_requests/4...

The suggested patch in comment #2 does fix the error but does not make the module usable.
Please check the merge request - added ability to customize rows property, for example, module views_rest_serializer_extra uses "results" instead of "rows".

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

Sorry, I opened issue in the wrong module.

gilmord → created an issue.

https://www.drupal.org/project/editablefields/issues/3425802 🐛 Fix event handling for subelements (e.g. checkboxes for boolean fields) RTBC

This one seem to be related

Thanks for the patch, I will review and test it during next couple days.

I would appreciate of anyone can test&review it asap so I can merge it , please make sure it does not break other form elements

@Aaron Bauman no way, 12 years old fix does not work for you???
With no jokes - search for auto submit issues for fresh versions of the module. Drupal 8-9-10 version was done from scratch, it is a complete rewrite of D7 version.
Please do not ping such outdated issues - surfer fresh issues or create one if does not exist.

Tested, works for me

@gorkagr looks like it is same issue and your changes fix it, tested it

gilmord → created an issue.

Js file was update, but library version not updated
So button disabled with php code in stripe review payn, and js stays cached by cloudflare, varnish etc

This needs to be fixed.

I updated commerce_stripe module, and now payment button is disabled, I assume this is due to this issue
No special steps - add to cart, go to checkout, enter billing information, on payment step fill card details - unable to submit, button is disabled

gilmord → created an issue.

gilmord → created an issue.

+1

bohart → credited gilmord → .

All my webhook events are in Skipped status
But when I manually add them to the process queue and run the queue worker - they are Succeeded now

Other question:
the payment entity related to the Succeeded webhook is not "authorized"

I expect this to work like this:
- user pays
- payment entity created
- webhook processed on queue
- some visual result in the payment

Am I wrong?
Or some changes to payment entity will only be done if with webhook is something wrong?

We used this service: https://instant.page/

it prefetches links on hover

Hi, please create a fork and prepare a merge request, so I can review and merge it
thanks!

Here are instructions:
https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →

Views field configuration:

Result:

The "Fields that trigger ajax" - this is array keys of the widget form, you can check here how it is used:
https://git.drupalcode.org/project/editablefields/-/merge_requests/13/di...

And the "Event that will trigger an ajax" - is a javascript event to be bind to trigger submit

@tonka67 a few things to check:
- make sure you use the latest dev version of the module
- use Inspect Element in browser developers tools and check the event is attached to the field in the view

- if the event IS there and does not work - check the javascript console output, maybe there are some errors
- if the event IS NOT attached - please use xdebug or any other way to debug the inside of "foreach ($fields_ajax as $field_ajax) {" loop to check if the value you set in "Fields that trigger ajax" is in the $form

One more thing - for the cases when the entire view is wrapped in a form element (for example if you use Views Bulk Operations) you have to set the "Select behavior" of the field to "Form in popup" instead of the default "Inline form"

By the way visually all looks good - order is paid, user is charged, user sees no errors

I have noticed the issue when enabled commerce_stripe_webhook_event and checked the webhook logs at /admin/commerce/config/stripe-webhook-events

I checked the commerce paypal module, they create payment in the onReturn method of the payment gateway plugins:

Example 1

Example 2

Example 3

Looks like this part is missing for the Commerce Stripe and payment is created in "Payment process" pane and not on the onReturn of the gateway plugin

Here is my checkout flow:

I have added sleep(1) in StripePaymentElement::processWebHook which is a horrible solution but it works

checking on how the other payment gateways are dealing with the same issue

I use commerce core 2.38.0 and commerce_stripe dev-1.x, and I face this issue on every payment

gilmord → created an issue.

Thanks, looks good, works good, merged

Hi @rodrigoaguilera, good idea

A couple of suggestions:
- implement getter for protected $form_mode
- move getters above buildForm method, so we have all getters in one place

Thanks!

Thanks, released

Pushed 1.0.2, need testing

gilmord → created an issue.

Thanks!

merged into dev branch, it will get into the next release

$instance['label'] = '';

This code was in drupal7, it is not supported by the maintainers, so we can skip this unless comunity implement solutions for title/description for d7 version

Perfect, Entity Form/Display Field Label can now handle both title and description.
Looks like we do not need $instance['label'] = '' this code and can relay on external modules to interact with the wigets.

Thanks @paulrad, closing this issue.

This module relays on what you have configured in the form mode, ot dea not interact with the widget and only renders it.

Consider hiding description on the form mode level

See this issue as a reference:
https://www.drupal.org/project/editablefields/issues/3390633#comment-154... ✨ Ability to hide field label in views Active

You are looking for https://www.drupal.org/project/editableviews →

It wraps the entire view with the form

And this module keeps each field as a separate form, one submit will be hard to implement without hacks

@joelpittet yeah, my bad, it is a form mode indeed

Found this module, but have not tested it:
https://www.drupal.org/project/entity_form_field_labe →

I think we should use some eternal/core functionality to handle labels, as this module totally relays on what you have set up in your form mode and does not interact with the widget selected and only renders it based on form mode settings

This is far from perfect, but at least something
It works for the simple cases, and should be a good starting point

Thanks!

Merged in dev version

Merged in dev version

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

gilmord → created an issue.

bohart → credited gilmord → .

Thanks, released in 1.0.6
https://www.drupal.org/project/paragraphs_sets_plugins_ui/releases/1.0.6 →

Thanks, released in 1.0.6
https://www.drupal.org/project/paragraphs_sets_plugins_ui/releases/1.0.6 →

Thanks, released in 1.0.6
https://www.drupal.org/project/paragraphs_sets_plugins_ui/releases/1.0.6 →

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

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

gilmord → created an issue.

gilmord → created an issue.

Hi, submitted a MR review, please check

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

gilmord → created an issue.

In any case this does not seem to be a good approach to force domains. Imagine having millions of nodes and only small part of it is domain-restricted - node_access table will be flooded with millions of useless records. If there are translations - the number will be doubled/tripled/etc

I think this issue should be handled and it should not work like that by design.

For now, I have just disabled the hooks, works well so far.

/**
 * Implements hook_module_implements_alter().
 */
function YOUR_MODULE_module_implements_alter(&$implementations, $hook) {
  // Before the issue is resolved we disable access hooks
  // to allow content in all domains.
  // @see: https://www.drupal.org/project/domain/issues/3047514
  $disable_hooks = [
    'node_access_records',
    'node_grants',
  ];
  if (in_array($hook, $disable_hooks)
    && isset($implementations['domain_access'])
  ) {
    unset($implementations['domain_access']);
  }
}

Just faced this issue - I only need domain_access for users, all the content is shared between domains. I have deleted the fields but node_access table is still full of grants.

There is no built option to disable this module for content, content is locked to the active or default domain. According to attached issue I have to grant nodes to all domains which will make useless access checks as it always should be accessible.

I would say a propper option here is to disable grants and access records hooks so if domain_access is not needed for content it can be disabled.

@jmauricio thanks!

By the way I noticed interesting thing - this module successfully replace toolbar not only for Gin theme but for any theme.

In my case it worked for adminimal and for my custom theme.

Maybe we should consider replacing it with a global module, not limited to Gin theme

I did not dig why, but this patch (https://git.drupalcode.org/project/gin_toolbar_custom_menu/-/merge_reque...) + patch from related issue (https://git.drupalcode.org/project/gin_toolbar/-/merge_requests/38.patch) did the trick for me - I have regular adminimal toolbar on one domain and I have gin toolbar + custom menu for it on gin theme domain.

gilmord → created an issue.