[Crisim]

This reply has been marked as private.

[Crisim]

Hello, we made a topic a few months ago regarding this plugin. Back when it was WCMP, things went swimmingly. We then migrated to MVX, bought a pro license, and then… everything crumbled. I’m back at tackling the problem again. I’m running a multisite, and I have created a template site with only the current plugins enabled:

-Wordpress 6.2
-X (Theme)
-Cornerstone (Needed to run the theme)
-Woocommerce
-MVX
-MVX Pro
-UberMenu 3
-Wordfence Security

That’s the raw minimum I can go down to.Everything is updated to the latest version.

The site runs at https://gapinnovation.com/template/

It works relatively ok. But as soon as the vendor logs in… things go bad.

I get a blank page.
If I try to visit any page, all CSS is broken. This only happens for the vendor account. Any other user will display fine. Also, trying to visit a non-existing page will load the 404 page correctly with all the proper CSS. So it’s only when trying to load a regular page that it breaks. (See screenshot)

There is no way to access the frontend vendor dashboard
The backend dashboard kinds of work, but trying to go click on frontend dashboard redirect to https://gapinnovation.com/, which is not https://gapinnovation.com/template/

So I have no way to set up payment info for the vendor.

As for payments from the users to us, we use Stripe Marketplace (the whole reason we updated to Pro), so the payments go through stripe, then commissions are split through the credentials set in the vendor dashboard (that we cannot access anymore). Setting it up in the admin dashboard is also a bit broken.

It used to work so well, so it’s a bit ridiculous that after a price hike and a rebranding everything is worst than before.

[NerdySupportExpert Moumita]

Hi @Crisim, sorry to hear that you have faced this issue.

Can you please create a staging site and share temporary admin, FTP access so we can assist you accordingly?
While sharing the access, don’t forget to mark the response as private.

[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]

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]

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.

[NerdySupportExpert Moumita]

@Crisi, not to worry at all.
We will check the issues in your staging and share fix so you won’t face the same issue in your live site.

Please do share a video if the issue so we can assist you there.

[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]

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]

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.

[NerdySupportExpert Moumita]

Hi, We will add the fix in our next update by tommorow.

We have also added a fix in our GitHub.
So, after downloading the plugin from here – https://github.com/multivendorx/MultiVendorX/archive/refs/heads/main.zip, follow these steps :
– Delete the installed MultiVendorX via wp-admin >> plugin
– Unzip the GitHub plugin
– Rename the folder as “dc-woocommerce-multi-vendor” and remove the master tag. Now, zip this folder again.
– Install this plugin on your site.
Please do keep us posted.

[Sangita Support Squad]

Its been long and we have not heard back from you. We assume your issue is solved now. We are closing this thread as of now. If you need help or face any issue please open a new thread.

[Author]

Posts