[Crisim]

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.

[Crisim]

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).

[Crisim]

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.

[Crisim]

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]

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.

[Crisim]

This fix does not work for us, unfortunately. Unless it’s some kind of caching issue server side that doesn’t generate a page with the fix included, but we don’t have any caching plugin installed anymore. Client side, I cleared all caches, just in case.

[Crisim]

I will add to the pile of people affected by this Stripe change, but being part of a small company myself, I understand that a small team can take more time to fix a bug than a bigger team with more resources, and it sucks in those rare moments where we had to our entire clientbase unable to use our products for bug reasons and we had to scramble for a fix. I hope you find your fix soon.

[Crisim]

Another example:
If the key ‘mvx_settings_general_tab_settings_en’ exists, has all the correct settings for the vendor dashboard page, the site acts as if those settings do not exist. If I copy its data into a new ‘mvx_settings_general_tab_settings’ key, then it works.

Again, I can see in the plugin source code places where you do not use mvx_get_option to read those settings

wp-content/plugins/dc-woocommerce-multi-vendor/classes/class-mvx-capabilities.php: , (array) get_option(‘mvx_settings_general_tab_settings’, array())
wp-content/plugins/dc-woocommerce-multi-vendor/classes/class-mvx-cron-job.php: $get_managements_data = get_option(‘mvx_settings_general_tab_settings’, array());
wp-content/plugins/dc-woocommerce-multi-vendor/includes/class-mvx-install.php: $general_settings = get_option(‘mvx_settings_general_tab_settings’);
wp-content/plugins/dc-woocommerce-multi-vendor/includes/class-mvx-install.php: update_option(‘mvx_settings_general_tab_settings’, $general_settings);

Bottom line:
-You should always use the mvx_get_option and mvx_update_option functions. You made them for a reason.
-The whole concept of using language based saving for settings is ridiculous and error prone. You should only have one set of settings for all options that shouldn’t be translated (which is almost all of them), so they stay consistant no matter the language that is used either in the backend or frontend. Then have the settings that could change based on language (like used defined strings for slugs and descriptions) be in their own set of settings, with a fallback to the base, non-language differenced setting, so if something isn’t set, it has something to use. Or even better, deal with translatable options on a case by case basic, so you know you’re only affecting those and not the options that should be global no matter the language. I applaud your desire to support multilingual sites, but please implement it correctly.

[Crisim]

In fact, I just found proof that it can break things.

Step 1:
Let’s start with a database that only has stripe-connect enabled, both with and without the WMPL plugin. WMPL is enabled. So the database has the following keys:

mvx_all_active_module_list_en = a:1:{i:0;s:14:”stripe-connect”;}
mvx_all_active_module_list : a:1:{i:0;s:14:”stripe-connect”;}

So, I go to the Payments page and the Stripe Connect tab, and of course, I see almost nothing there. (See screenshot 1) Normal.

Step 2:
Now I go in modules and activate stripe marketplace module. The database now has the following keys:

mvx_all_active_module_list_en = a:2:{i:0;s:14:”stripe-connect”;i:1;s:18:”stripe-marketplace”;}
mvx_all_active_module_list : a:1:{i:0;s:14:”stripe-connect”;}

But if I go back into the settings page for Stripe Connect, it’s still looking like the first screenshot.

Step 3: I disable the WPML module. And enable the stripe marketplace module. The database now has the following keys:

mvx_all_active_module_list_en : a:2:{i:0;s:14:”stripe-connect”;i:1;s:18:”stripe-marketplace”;}
mvx_all_active_module_list : a:2:{i:0;s:14:”stripe-connect”;i:1;s:18:”stripe-marketplace”;}

Step 4. I return once again in the Stripe Connect settings. This time all the options regarding Stripe Marketplaces are there (See screenshot 2). And If I activate WPML, it’s also going to be correct from that point on.

Conclusion: In that particular instance, to determine whether the stripe-marketplace module is active and display its settings, it only looks at the ‘mvx_all_active_module_list’ key, and not the ‘mvx_all_active_module_list_en’ key, so it doesn’t work as expected. When you do edit the stripe settings themselves, they are however saved and loaded correctly. This is likely caused by one of those instances where it uses get_option instead of mvx_get_option when reading the “mvx_all_active_module_list” option in the database.

[Crisim]

I have fixed mostly everything on my own by now, although I would check the issue with with using mvx_get_option vs get_option on your end in your codebase.

For example, for the ‘mvx_all_active_module_list’ option, almost all of the calls use mvx_get_option, except for those instances:

wp-content/plugins/dc-woocommerce-multi-vendor/admin/class-mvx-admin-setup-wizard.php: $active_module_list = get_option(‘mvx_all_active_module_list’) ? get_option(‘mvx_all_active_module_list’) : array();
wp-content/plugins/dc-woocommerce-multi-vendor/classes/class-mvx-cron-job.php: $active_module_list = get_option(‘mvx_all_active_module_list’) ? get_option(‘mvx_all_active_module_list’) : array();
wp-content/plugins/dc-woocommerce-multi-vendor/packages/mvx-buddypress/mvx-buddypress.php: $is_module_active = get_option(‘mvx_all_active_module_list’, true);
wp-content/plugins/dc-woocommerce-multi-vendor/packages/mvx-elementor/mvx-elementor.php: $is_module_active = get_option(‘mvx_all_active_module_list’, true);

This can certainly cause issues on sites with a language plugin active. There might be other cases with other others options being read, that’s just one example.

[Crisim]

I have gathered more proof that data in the database is corrupted. I had finished manually repairing on of the subsites and I began working on another, and I couldn’t activate modules. After a bunch of testing, I noticed the following problem:

In the database table wp_5_options, the option mvx_all_active_module_list was:
{}

which prevented the option from being edited, because wordpress loaded it as a string instead of an array.

I deleted the row and reloaded the webpage, and then the row returned, but this time with the following value:
a:0:{}

At that point, I could add and remove modules properly. If that kind of thing is possible, then anything is possible. The plugin could fail at any point due to database corruption.

Is there a way to remove anything related to wcmp and mvx in the database and start over? I’m not sure I can trust anything to work properly, even if it seems like all is working fine. All the historical data I care about is in wp_X_woocommerce_order_itemmeta, wp_X_woocommerce_order_item, wp_X_posts and wp_X_postmeta, so I don’t mind losing every option and setting, so long as I know that it’s all valid data.

Also, I noticed after installing the language plugin that settings are now saved with an appended _en in their name, and the regular, not _en setting was no longer updated, nor read. Wouldn’t that cause a desync if someone was to use the site in the second language (fr), and load incorrect settings? I also noticed places in the code where it used get_option instead of mvx_get_option to read an option from the DB, which would definitely read an out of sync value because it wouldn’t append the language code to fetch the key.

So yeah. I think there’a few bugs still in your codebase.

[Crisim]

The button did nothing because the option ‘dc_product_vendor_plugin_page_install’ already existed in my database (likely from the original WCMP install). So I deleted it, pressed the button, and it fixed the frontend… except the link to the vendor dashboard led to a page with the shortcode [wcmp_vendor]. Once again, I went into the database and fixed the newly created page with [mvx_vendor] and then it worked. I have access to the vendor dashboard, and the site is no longer broken for the vendor. Now I lost all of the vendor’s payment settings, but I suppose that’s expected since it’s no longer the stripe connect plugin that deals with it, but the stripe connect module that’s now part of the Pro version.

All of this leads me to think that when I upgraded my WCMP plugin via the plugin page and it became MVX, either some files were not updated properly, or you have missed something somewhere for it to still create wcmp_vendor pages. Either way, that’s a very poor migration experience that’s starting to cost us a lot of time and money. Here I am, having to fix things on my own because your code didn’t properly handle the migration.

[Crisim]

Before I give you access, I did some preliminary digging into the code. It seems that the root issue that it tries to load the frontend dashboard on any frontend page, while also loading the frontend page, and it does so because in the database, all the vendors customs pages are set to their default value of an empty string, which eventually trigger is_page() to return true, despite the page not being the vendor page.

So I came to the conclusion that when I updated my WCMP to MVX Pro by adding the plugin files directly into my plugins folder and activating them, a bunch of installation steps were not followed properly, such as creating vendor pages, and so the plugins are left in a weird in-middle state. I tried the Create Missing Pages button in the Settings page, but it doesn’t do anything.

So, if there’s no alternative ways to generate those missing pages, my current plan is to simply reinstall the entire plugins (both MVX and MVX Pro) from scratch. How would I do that, considering that the database already contains a bunch of data regarding those plugins? Restarting from a fresh wordpress install is not an option, it would take forever to setup all the products and everything again.

[Crisim]

This reply has been marked as private.

[Crisim]

This reply has been marked as private.

[Author]

Posts