🇺🇸United States @andyg5000

andyg5000 → created an issue.

andyg5000 → created an issue.

Thanks for the update. I was actually leaning towards using yours as a base for my project :)

I see that you've already set this project as "No longer developed by its maintainers", so I'll close this out.

andyg5000 → created an issue.

andyg5000 → created an issue. See original summary → .

andyg5000 → created an issue.

We're still having this issue with multiple submits (see logs below)

I'm going forward with a patch to disable the submit button when the form is submitted (attached) and will report back if we're still experiencing this.

xxx.xxx.xxx - - [01/Nov/2024:20:43:11 +0000] "POST /checkout/21117/review HTTP/1.1" 303 422 "https://site.net/checkout/21117/review" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Edg/130.0.0.0"
xxx.xxx.xxx - - [01/Nov/2024:20:43:15 +0000] "GET /checkout/21117/payment HTTP/1.1" 302 342 "https://site.net/checkout/21117/review" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Edg/130.0.0.0"
xxx.xxx.xxx - - [01/Nov/2024:20:43:16 +0000] "POST /checkout/21117/review HTTP/1.1" 303 422 "https://site.net/checkout/21117/review" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Edg/130.0.0.0"
xxx.xxx.xxx - - [01/Nov/2024:20:43:18 +0000] "GET /checkout/21117/payment HTTP/1.1" 302 342 "https://site.net/checkout/21117/review" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Edg/130.0.0.0"
xxx.xxx.xxx - - [01/Nov/2024:20:43:19 +0000] "POST /checkout/21117/review HTTP/1.1" 303 422 "https://site.net/checkout/21117/review" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Edg/130.0.0.0"
xxx.xxx.xxx - - [01/Nov/2024:20:43:21 +0000] "GET /checkout/21117/payment HTTP/1.1" 302 342 "https://site.net/checkout/21117/review" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Edg/130.0.0.0"
xxx.xxx.xxx - - [01/Nov/2024:20:43:21 +0000] "GET /checkout/21117/complete HTTP/1.1" 200 81607 "https://site.net/checkout/21117/review" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Edg/130.0.0.0"

Patch and MR up!

andyg5000 → created an issue.

I didn't even realize, but the pager configuration is still available on views data export displays. It moves it to the far right column. Since it wasn't in the middle, I didn't pay attention :) This is unnecessary when you use a pager config.

Patch and MR attached

andyg5000 → created an issue.

Here's a patch we're using that solves the problem.

andyg5000 → created an issue.

Here's a temp patch I'm using for now until we can get the module maintainers eyes on this. I don't think we need to reference any of the drush.services.yml stuff and removing it fixes the duplicate hook registrations.

The init hook is getting registered twice by Drush because of a drush.services.yml and the auto-discovery service that Drush invokes. We should remove the command in drush.services.yml and let the auto-discovery handle registering the commands.

I would like the module maintainers to review this before making an MR because there are several commands that are impacted by this.

I went ahead and added the condition so we're good either way.

Good point. Let me confirm that an empty string would break this request and I'll add a condition if necessary.

Thanks Ryan!

Once we have some feedback on 🐛 Error 33: Email is required (and E00027) Needs review , we should update this MR to include the customer->email element to the request.

Merge request for this module submitted. We're just adding the customer->email to the request as an array which works and solves the problem. However, we can also coordinate with the upstream library (commerceguys/authnet) for which I have a pull request to add the data type https://github.com/commerceguys/authnet/issues/39. Since having that merged and a release rolled will likely take some time, I setteld for the "quick and dirty" fix here. If it is merged, we'll change this to :

   use CommerceGuys\AuthNet\DataTypes\Customer;
...
    $transaction_request->addDataType(new Customer([
      'email' => $order->getEmail(),
    ]));

🐛 Error on refund if payment hasn't been settled Needs review should also be updated to include this in the void request.

andyg5000 → created an issue.

Hey @smustgrave ,

Just to clarify... You were unable to reproduce the issue following my steps in #53? I know for sure we had the issue with Vimeo videos and that configuration.

I see other recent comments mentioning steps from #7, but the separate sub-domain seems to be the culprit so wanted to verify.

andyg5000 → created an issue.

Hey Ryan,

Thanks for maintaining the issue queue.

Just for other's that might see this, the SOAP rate API is not being turned off this week.

Here's the notice from their site showing it's just tracking and address validation:

Caution: FedEx Web Services Tracking, Address Validation, and Validate Postal Codes WSDLS will be disabled on August 31, 2024. The SOAP based FedEx Web Services is in development containment and has been replaced with FedEx RESTful APIs. To learn more and upgrade your integration from Web Services to FedEx APIs, please visit the FedEx Developer Portal.

Still important to get the update in place if you haven't already!

Hey Nicolas,

Is your custom solution based on the commerce forms loaded for /user/[uid]/payment-methods for something custom?

If the former, I'm curious how you got by the logic in https://git.drupalcode.org/project/commerce/-/blob/8.x-2.x/modules/payme... without exposing the form during checkout.

Hey guys,

Thanks for clarifying the workflow is required alternate payment methods supported by stripe payment element. That's the answer Nick and I were trying to uncover.

Again, I was never proposing to change the workflow only that commerce core doesn't support what we're trying to do without adding an "add-payment" form property.

It sounds like a commerce core will need to be created and merged before we can move forward with this.

Hey Tom,

Thanks for the feedback. The MR above does address "Allowing customers to create payment methods in their profile".

For the MOTO thing, if a stripe developers are required to enforce this, we should reject admins from accessing `/user/[uid]/payment-methods` for the payment element form. In my opinion, the MOTO is up to the store owner to maintain and not our requirement. Most payment gateways, including stripe, have a virtual terminal for merchants to charge the customer on their behalf. I don't see this feature as being any different. Perhaps a new configurable access check and warning need to be added to commerce payment modules if this is an actual requirement. All of the major payment gateway modules for Drupal Commerce do not have this limitation (to my knowledge) and allow adding payment methods as admin.

I understand the difference in checkout flows you mention above, my MR does NOT run a PaymentIntent, it runs a SetupIntent, so the customer is not charged until the order is submitted and it functions the same as them selecting an previous payment element payment method. The can cancel, return, abandon, etc...

I'm not suggesting we ditch the contemporary flow, only that commerce core doesn't support solving the main issue here currently (Allowing customers to create payment methods in their profile). See my comments on SupportsCreatingPaymentMethodsInterface above. If we can solve that, then simply removing the add-payment property commit (5499e95c8b2c7621319b5c1d6053c3eef02dbef7) from my MR and updating the interface to match a core change (e.g. my example of SupportsCreatingOrderlessPaymentMethodsInterface) is all that's needed.

Let me know your thoughts and I'll work to update this MR accordingly.

Hey Shawn,

Thanks for making the update and explaining the preprocess. I think all of this makes sense.

Thanks,
Andy

Hey Nicolas,

Sorry for potentially hijacking your issue here. The merge I built basically adds all the things you asked for, making the "payment element" behave more like "card" and providing an "add-payment" form so users can add payment methods outside of the context of an order. It does not answer your question about why it was built the way it was initially, and I too am trying to get that question answered.

You can see in my comment #11 above that I'm pointing out the one commit that changes the functionality we're both questioning. The problem is that without that commit, Commerce Core doesn't support a form that can be used on /user/[uid]/payment-methods, but not available in checkout. With the commit, the core form includes the payment element during checkout at the same position as other on-site (and existing stored payment methods). The review pane is simply skipped when a stored payment method is selected from that step. This commit can be omitted from the MR, but I believe core will need another issue to support this.

My goal here is to get your original question answered and add the missing functionality that I need. Knowing that, feel free to rename the issue back as you see fit. If you could test the MR, that would be nice too, assuming you still need part of the functionality. Hopefully Centarro will chime in soon.

Thanks,
Andy

andyg5000 → created an issue.

I have updated the merge request to address points 1 and 2 from my previous comment.

Billing information is now passed to Stripe from both the checkout form and the add payment form (from a user dashboard).

I added the core onsite base form to the "add-payment" method for the StripePaymentElement payment gateway plugin (commit 5499e95c8b2c7621319b5c1d6053c3eef02dbef7). This change allows payment methods to be added during checkout, to a back-end order, and by customers on the payment methods page. Using this commit replaces the review stage payment processing that the payment gateway handled prior to my merge request. Everything still works, but the payment form is now loaded on the payment page rather than the review page. I'm not sure why it functioned that way before, but this approach aligns with the other payment flows (like the base Stripe plugin in this module).

It looks like they were already on the issue but hidden previously. Revealing them now :)

Rolled #34 into a MR

I can confirm this is still and issue and that the patch in #34 solves the problem.

To reproduce the issue, you must set up a different sub-domain for your oembed/iframe on /admin/config/media/media-settings.

This is a recommend setting by Drupal core for security best practices. If we don't want to just allow iFrame fullscreen for all elements, we should add it as an option that can be enabled to add the dom attribute.

Hey Tom,

I pushed up the work (to issue branch) to add the StripePaymentElement SetupIntent form which can be used by the customer (or admins) to add a payment method to the account.

One issue is that `SupportsCreatingPaymentMethodsInterface` is required to access this form on the user account page and this is also what checkout uses. We don't want this form to load during checkout, only on Add Payment Method. I mentioned a possible solution above, but that requires an update to core. Note this form actually works in checkout just fine with my code, but it doesn't follow the same process as the existing implementation that puts the stripe form on the review page. I'm actually not sure the reasoning behind the existing pattern, but I'm sure there is one : )

If you like this approach, we'll need to:

1) Address the SupportsCreatingPaymentMethodsInterface issue above
2) Add javascript to send the billing information when not using an existing profile (e.g. new address)
3) Write tests.

Let me know your thoughts and I can pick back up on this!

Hey Tom!

Yep, SetupIntent, basically the same as the Stripe payment method, but using the PM interface.

Thanks for providing the additional info regarding MOTO. I'll push my updates for `add-payment-method` shortly and we can determine the best route to go for MOTO. Maybe an option that's basically a permission for adding cards on-behalf of customers. FWIW, the Stripe payment gateway plugin already does this by allowing admins to add payment methods for the customer via the CC form.

Warning: The patch in #11 can cause issues with media_library widget. It causes the ajax/form-submit logic to break when clicking "apply filters" in the media library widget on a node form.

The error is:
Path: /admin/content/media-widget/image?name=sdf&sort_by=created. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: The opener ID parameter is required and must be a string. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 115 of /var/www/html/docroot/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

Updating the title since I think the main goal here is to add support for adding payment methods via "Stripe Payment Element" from the user payment method page. I've realized that we don't need an "add-payment" form, but if you have 0 payment methods with that form, the add payment tab on the commerce order throws a 403 and doesn't let you select from saved payments or click the "add a new payment method" button. I'll look at commerce core for that issue separately.

Assigning to me because I have this mostly working locally and will commit to a MR branch ASAP.

I need to implement Payment Element and meet the following goals:

1) Use Stripe Payment Element as the payment interface during checkout (works out-of-the-box)
2) Allow customers to add/delete payment methods from their account.
3) Allow administrators to add payments to a back-end order.
4) Allow administrators to add/delete payment methods for a customer.

Adding the following to the @CommercePaymentGateway annotation/definition for StripePaymentElement solves goals 3 & 4:

 *   forms = {
 *     "add-payment" = "Drupal\commerce_payment\PluginForm\OnsitePaymentAddForm",
 *     "add-payment-method" = "Drupal\commerce_stripe\PluginForm\Stripe\PaymentMethodAddForm",
 *   },

The condition in PaymentMethodAddForm is what prevents goal 2. It requires that the payment method implement SupportsCreatingPaymentMethodsInterface. However, the checkout PaymentInformation checkout pane also uses this interface to determine if a credit card form should be rendered on the checkout pane. Since Stripe Payment Element uses its own OffsitePaymentGatewayBase based workflow, this doesn’t work.

An option to fix this is to define a new interface for payment gateways that's only checked in PaymentMethodAddForm and not in the PaymentInformation checkout pane. Something like SupportsCreatingOrderlessPaymentMethodsInterface. Then the PaymentMethodAddForm logic could look like this:

$payment_gateways = array_filter($payment_gateways, function ($payment_gateway) {
  return $payment_gateway->getPlugin() instanceof SupportsCreatingPaymentMethodsInterface || $payment_gateway->getPlugin() instanceof SupportsCreatingOrderlessPaymentMethodsInterface;
});

After making the changes above, I can achieve all my goals. Note that the payment form on the admin and customer payment method pages is the Stripe iframe payment form and not the fancy one that's rendered in checkout, but it works!

Wouldn't you know... all the stuff we needed was there all along.

Looks like this was introduced with #3190799: ProductVariationContext is causing extra generate sample images to be generated → would be helpful to only have this fire in the context of a layout builder interface. Not sure the best way to handle that. I guess route match is an option, but sounds kinda ugly.

My comment in #2 above doesn't work. If you really want to kill this on your instance, remove the following from commerce_product.services.yml

   calls:
     - [ setSampleEntityGenerator, [ '@?layout_builder.sample_entity_generator' ] ]

I've had complaints about `--commerce--layout-content-max-width` too. Not sure why that's constrained to 52rem. It affects the column layout of all the commerce pages like product edit form and order edit form.

It just broke the column layout on our admin order page. Not a big deal imo, but end users did have a moment of panic. Just a heads up to check custom templates in the release notes should be fine I think.

Hey Guys, Thanks for the work on this. This requires an update for anyone that's customized the admin order template. May want to put something in the release notes about that.

It looks like this is related to the variation being passed to those classes with `in_preview` as `TRUE`. So maybe it's as simple as figuring out why that's being set upstream.

andyg5000 → created an issue.

Looks like the current release supports this functionality. We were using 🐛 Unable to resolve path on node in other language than default Needs work patch 66 and it was causing the issue.

andyg5000 → created an issue.

Our initial use case was also anonymous checkout. The problem with adding a checkbox is that this should be an automatic process that fires after checkout. Perhaps, the action happens by default when the uid is 0, but there's a checkbox when manually moving an order?

Finally, I'm not sure what it means for the subscription to be reassigned but the payment method be someone else's

`Drupal\commerce_payment\EventSubscriber\OrderAssignSubscriber` is already moving the payment entity in commence core :)

Can you update this to include the duplicate issue you're referencing?

andyg5000 → created an issue.

andyg5000 → created an issue.

Forgot to upload. Also forgot to upload the screenshot referenced in #15 (see attached)

Thanks!

Hey @zviryatko

Thanks for the reply. It looks like the notices were being caused by an index with multiple entity types where some of those entity types didn't have an override (see attached).

While working on it, I realized that this patch is reusing a significant amount of the code from search_api's `TypeBoost` processor. I updated updated the working patch to extend that class and the notices are gone.

Here's what my update does:

1) Fixes the notices shown in my last post
2) Adds the default boost that I believe was missing from the original patch
3) Simplifies update by extending existing class

* Note if using this, the config key is changed from the original patch, so make sure to update config.

If we don't want to extend the search_api class, I think we still need to address 1 & 2 above.

Merge request is in and patch attached here for easy review.

Patch is doing what it's supposed to do 👍, but I'm getting the following errors notices when all of the index content entity types aren't configured. Should add a !empty check. Don't have time to update the patch today, but will try to tomorrow!

andyg5000 → created an issue.

I have to agree with @jeni_dc on this one. We should follow the variables that commerce provides allowing the user to customize the commerce message from the admin interface and not hard coding this in the theme. It took me a minute to figure out why my custom message wasn't showing and this is why.

I have a MR up that matches the commerce template so you can see the checkout complete message defined in the pane config.

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

I was able to fix this by aborting the init when the view display is a data export. It seems like you wouldn't ever have VBO as part of a data export anyway. I'm not sure this is the best approach, but it does fix this issue and I can still export the data.

If you didn't want to go this route, I believe you will need to split $this->viewData into an array of views data instances based on the view display. Or maybe even not use the service container for that since it's the same object that's reused across multiple views displays being loaded in a single request.

It looks like attaching a Views Data Export display to the same view as the VBO is causing this. Not sure which module should be responsible for fixing it, but it seems like it's probably VBO's responsibility. Here's what's happening:

Somewhere between `ViewsBulkOperationsBulkForm` and `ViewsBulkOperationsViewData` the object expected as $this->view is losing it's reference to being the same object.

ViewsBulkOperationsBulkForm calls :

<?php 
    $action_options = $this->getBulkOptions();
    if (!empty($this->view->result) && !empty($action_options)) {

      // Get bulk form keys and entity labels for all rows.
      $entity_data = $this->viewData->getViewEntityData();
...

And in `ViewsBulkOperationsViewData`, the $this->view->result is null event though checked !empty above

$base_field = $this->view->storage->get('base_field');
    foreach ($this->view->result as $row_index => $row) {

If I remove the data export as an attachment to the VBO view, the issue goes away.

In my instance $this->view->result in https://git.drupalcode.org/project/views_bulk_operations/-/blob/4.2.x/sr... is null unless I add $this->view->execute(); right before it.

Not sure if that's the best solution, but will work up a patch once I have something to share.

Filing a potential regression caused by this one, see 🐛 Missing checkboxes in 4.2.6 Active .

The issue appears after applying the commit form 📌 Create API for view provider modules to provide entity labels and bulk form keys Fixed

andyg5000 → created an issue.

Thanks for everyone that worked on this.

Whenever a major bug that can cause data to be deleted is fixed/merged, can we get a new release with it? Please.

Thanks to everyone that worked getting this rolled out. I wanted to drop an edge case here for others that may be experiencing an issue I came across:

If you embed your view in a template like using twig_tweak (e.g. {{ drupal_view('my_view','block_1', term.id) }}), caching on the view will prevent your facets from being displayed. Moving the view earlier in the page building cycle, like normal block placement, resolves the issue and views caching + facets works as it should.

As a warning to anyone using this patch, like myself, this can prevent shipping from being added to orders when the addressbook is used. Since the patch checks `empty($triggering_element['#recalculate'])`, it prevents the shipping pane from running the rate calculations when the pane is initially loaded.

Lukas has some good points. I'm happy to work up a patch to push this further, but would like the logic to be reviewed/approved by maintainers before writing something up.

Confirmed this is a good one. Thanks everyone

Here's a patch that's fixing the issue for me.

andyg5000 → created an issue.

Looks like this was already done on 2.x just need a release.

andyg5000 → created an issue.

Here's an updated patch that removes the rest.

The ones that were used were:

classy/indented
classy/node
classy/search-results
classy/file

If we want any of those items, we could just create our own.

Here's a patch that loads the correct object.

andyg5000 → created an issue.

This has been fixed in the latest 2.x release

andyg5000 → created an issue.

Looks like a few more things need to be done here https://git.drupalcode.org/search?search=classy&nav_source=navbar&projec...

Can we get a release that includes this 🤗?

andyg5000 → created an issue.

Bump : )

Let me know if I can help.

It looks like this was already fixed in https://git.drupalcode.org/project/commerce_ups/-/commit/22d8e72f8aed429...

Thanks for the patch!

Hi @pankaj1390. The patch is on the HEAD of the 2.0.x branch (as it should be) and doesn't apply directly to the current release. If you want to use the merge request you'll need to do `composer require drupal/path_redirect_import:dev-2.0.x`

The merge fixes my issue and includes updates to ensure migrate_tools version is pinned. The patch just changes the `use` statement. Merge looks good to me.

I've uncovered an interesting "bug" or misunderstanding in PHP with my first patch (https://twitter.com/AndyG5000/status/1699833476701450692)

Passing items by reference in a foreach loop are incorrectly read when looping again with the same variable name,