MultivendorX Pro
-
Posts
-
-
When processing payment, a new crash appears when processing vendors during or after the payment, it’s unclear. I have compared with the previous version of the plugin, and found the source of the error.
In the stripe marketplace module, in the file abstract-mvx-stripe-payment-gateway.php, in the function prepare_source, the following line has been changed from
if ( ( $user_id && $this->saved_cards && $maybe_saved_card && ‘reusable’ === $source_object->usage ) || $force_save_source ) {
to
if ( ( $user_id && $this->saved_cards && $maybe_saved_card && MVX_Stripe_Helper::is_reusable_payment_method( $source_object ) ) || $force_save_source ) {
However, the is_reusable_payment_method method does not exist in the class-mvx-stripe-helper.php file in the same folder, causing the fatal error. I assume it was supposed to be a replacement to this ‘reusable’ === $source_object->usage statement, but it was not added properly in your latest release.
-
-
@Crisim, can you please ensure one thing, disable the “Save Cars” option from Stripe Marketplace settings and place an order.
Please keep us posted with the result.
-
I mean, obviously, if I change one of those settings to ensure that the code doesn’t reach the further &&’s on the line by having one of the variables be false, it will work, but I already patched the issue myself by creating the missing is_reusable_payment_method method and filling it with ‘return ‘reusable’ === $source_object->usage;’
It’s more so that your team is aware so that you may fix it yourself for other users. Because the is_reusable_payment_method is also called in two other places in that file, so it would crash there too.
-
There’s a second bug on checkout, that seems to be linked with PHP 8. I checked every single email of yours, and every single one, when it overrides the emails’s ‘object’ variable in the trigger() function, it does so by setting an object to that variable. Except in one specific email, causing a crash because of variable type mismatch.
It’s in class-mvx-email-admin-changer-order-status.php in the main mvx plugin.
In the trigger function, you set
$this->object = $order_id;
when it should be something like
$this->object = wc_get_order( $order_id );
You may not have ever seen a crash on your end, but when other plugins use the ‘object’ variable via filters and expect it to be an actual object and not an integer, then it crashes.
-
@Crisim, we have released our update today, where we have fixed this issue.
Kindly update the plugin MultiVendorX and MultiVendorX Pro to the latest version and check.
Please do keep us posted.
-
I updated both plugins, and I can confirm that both issues are fixed in your code now and I do not need to patch them anymore. I’m still having issues since the first update last week where, unlike when people pay with PayPal, some of my custom hooks are either not called anymore or called with a suborder id instead of the main order id, which breaks some of my custom backend processing of orders. But I can probably patch my code once I figure out what changed with your plugin to change the flow of hooks and actions.
-
The filter I’m using is mvx_commission_transfer_charge_amount
It seems the key mvx_stripe_marketplace_stripe_charge_id doesn’t exist anymore in the order metadata, so I don’t have a way to query the stripe charge API to receive all the information I need about the charge to do some custom fee re-calculation (because we need to split the payment processing fees in half between us and the vendor, and that it not an option in your plugin).
-
There is also another clear error on your end. So in order to inform our website of things from stripe, your code creates a stripe web-hook in this code, in mvx-pro/modules/stripe-marketplace/includes/WebhookHandler.php:
$response = WebhookEndpoint::create( [
‘url’ => home_url( ‘wc-api/mvx_stripe’, ‘https’ ),
‘enabled_events’ => $this->get_events(),
‘connect’ => false
] );
foreach ( WebhookEndpoint::all() as $hook ) {
if ( false !== strpos( $hook->url, ‘webhook=mvx’ ) ) {
$event = WebhookEndpoint::retrieve( $hook->id );
$event->delete();
break;
}
}I believe this code is meant to delete any existing web hook after creating one, in case there’s duplicates. But clearly it does not work, because a single purchase create 4 identical web hooks on stripe’s end, and after 4 purchases it reaches the limit of 16 web hooks. Our site happens to be especially slow (like 8 seconds to load a page), so all of those extra hooks being created and then pinged by stripe basically kills our server, and turns what should be a 16-20 seconds checkout process into a 40 seconds process after one purchase, then 1m 20 process, and eventually topping at 2min process when all 16 endpoint exist.
-
Hellothere, In our latest update, we’ve ensured that payments with Stripe marketplace function smoothly. While our focus was primarily on ensuring the payment flow works seamlessly, our team hasn’t had the chance to address other factors like webhook yet.
However, rest assured, we’re currently working on restructuring our plugin. As part of this process, we’ll also be optimizing Webhook configurations and other structures to enhance the user experience.
Thanks for your understanding.
-
Please LOGIN to reply to this topic