[Sangita Support Squad]

Hi there,

To access the Pro features, you’ll first need to activate your MultiVendorX Pro license on your site. Please use your API credentials from the following page to activate the license:

https://multivendorx.com/my-account/api-keys/

Once the license has been activated successfully, you will be able to use all the Pro features.

If you have any further questions or need any assistance from our end, please let us know. We’re always happy to help.

[Sangita Support Squad]

Thank you for sharing the details. Kindly allow us some time to review everything thoroughly. We will investigate the matter and get back to you with an update accordingly.

[Sangita Support Squad]

Hi there,

Thank you for sharing the access details with us.

However, we’re currently unable to access the site using the URL you provided. Could you please verify the link and share the correct URL or updated access details with us?

We look forward to hearing back from you so that we can continue our investigation.

[Sangita Support Squad]

Hi Igan,

This is quite surprising, as we’ve tested the latest version on our end and have not been able to reproduce the issue.

The store breadcrumbs are displaying correctly on the store frontend page, as shown in the screenshot below:
https://www.awesomescreenshot.com/image/61247983?key=629fbccaf1d6845431c11a4f9d8c22d8

Additionally, we are not seeing any console errors during our testing.

Since you’re still experiencing these issues, could you please share access to a staging site where the problem can be reproduced? This will allow us to investigate the behavior directly and assist you more effectively. When sharing the credentials, please remember to mark your reply as private to keep the information secure.

Regarding the product category filtering, you can achieve this by adding the MultiVendorX Store Category widget to the MultiVendorX Store Sidebar. Once the widget is added, a product category filter will automatically appear on the vendor’s store page, allowing customers to filter products by category.

If you have any further questions or need additional assistance, please let us know. We’ll be happy to help.

[Sangita Support Squad]

Hi there,

Since you already have the new staging site set up and are aware of the vendors who were affected during the previous migration, we kindly request that you run the migration on this new site and allow it to complete successfully.

Once the migration is finished, please compare the results with your earlier migration and verify whether the same vendors are still experiencing the issue. If they are, kindly share those details with us.

Having this information will help us reproduce the issue more reliably on our end, giving us a clear starting point for debugging and allowing us to investigate the root cause effectively.

We appreciate your cooperation and request that you perform these checks and share the requested details with us. We look forward to your update.

[Sangita Support Squad]

Hi there,

The console errors and breadcrumb-related issue have already been resolved in the latest MultiVendorX version 5.0.8. Please make sure that you’re using this version on your site, as these issues should no longer be present after updating.

Regarding the issue you’re experiencing with your third-party plugin on the store pages, we’d like to clarify how the latest architecture works.

For custom MultiVendorX pages – such as the Store Frontend and Store List pages etc.- we no longer rely on WooCommerce’s endpoints. These pages are built using MultiVendorX’s own architecture and routing system.

Because of this architectural difference, third-party plugins that are designed specifically for WooCommerce endpoints may not work as expected on these custom MultiVendorX pages. If you would like those third-party functionalities to work on our custom pages as well, some level of custom development or integration will likely be required to make them compatible with the MultiVendorX implementation.

We hope this clarifies the behavior.

[Sangita Support Squad]

Hi there,

Thank you for sharing the access details with us.

You can proceed with upgrading the plugin on the shared staging site and allow sufficient time for all the data to migrate completely. Once the migration has finished, we kindly ask you to verify whether the same users who experienced the issue during the previous migration are still encountering the problem.

After you’ve completed the verification, please share the details of the affected users with us. This information will help us investigate the issue further from our end and determine the appropriate next steps.

We look forward to your update.

[Sangita Support Squad]

Hi there,

Thank you for getting back to us and for setting up the new staging site for the investigation.

To help us move forward, please follow the steps below:

1. Run the migration on the new staging environment.
Since your site contains a large amount of data, the migration may take some time to complete. We recommend allowing the process to finish fully before verifying the results or performing any additional testing.

2. Share the staging site access with us.
In the meantime, please provide the staging site credentials along with the FTP and database access details in this support thread. For security reasons, kindly make sure to mark your reply as private when sharing the credentials.

3. Verify the affected users after the migration.
As you’re already aware of the vendors who were affected during the previous migration, please check whether those same users continue to experience the issue once the new migration has completed.

If the problem persists for the same users, it will help us determine whether the issue is specific to those user records. Based on these details, we’ll be able to continue our investigation and proceed with the appropriate next steps from our end.

We appreciate your cooperation and look forward to your update.

[Sangita Support Squad]

Hi there,

Thank you for getting back to us.

Since you have a database dump of your site, could you please perform one additional verification?

If possible, set up a fresh test environment using the database dump and run the migration from the older MultiVendorX version to the latest version again. After the migration completes, please check whether the same users are still failing to convert from the dc_vendor role to the store_owner role.

This verification will help us determine whether the issue is consistently tied to those specific user accounts or whether it is influenced by some other factor during the migration process.

We would appreciate it if you could share your findings with us once you’ve completed this test.

We look forward to hearing back from you.

[Sangita Support Squad]

Hi there,

Thank you for your quick response and for sharing your detailed findings.

We have already identified that the store_id is being set to 0 because the affected users’ roles are not being converted from the legacy dc_vendor role to the store_owner role during migration. Since the role conversion does not occur, no corresponding store is created, which in turn results in the associated commissions having a store_id of 0. However, the key question is why this role conversion is being skipped only for certain vendors while it completes successfully for others within the same migration run.

From our internal testing, the migration process has consistently converted vendor roles and created the corresponding stores without issue. If there were a generic problem in the migration logic, we would expect all vendors to be affected rather than only a specific subset.

Technically, the vendor-to-store conversion relies on the user meeting the expected migration conditions and metadata checks. Since a large number of vendors on your site were successfully converted to store_owner, there appears to be some distinguishing factor causing these remaining users to be excluded from the conversion process.

To help us identify the root cause, it would be extremely useful to understand whether these affected vendors differ from the successfully migrated ones in any way. For example:

— Were these vendor accounts originally created through the standard MultiVendorX registration flow, or imported from another source?
— Have their roles ever been manually modified or changed to another role and then switched back to dc_vendor?
— Were they created or managed using any custom user role or membership plugins?
— Do they have any custom metadata, role assignments, or user configurations that differ from vendors that migrated successfully?

Any information regarding how these specific vendor accounts were created or managed over time would be very helpful. Our goal is to identify the exact condition that prevents these users from being converted to store_owner so that we can reliably reproduce the behavior and work on an appropriate fix.

We appreciate your continued cooperation and look forward to your response.

[Sangita Support Squad]

Hi there,

Our development team has carefully reviewed the information you provided. As mentioned in another case where we observed store_id being set to 0, we were able to identify the affected user. However, despite further investigation, we have not been able to determine the underlying cause.

We have also performed extensive testing and multiple dry runs in our own environment, but we have not been able to reproduce a scenario where valid vendors are migrated without an associated store. Because of this, we have not yet identified a consistent pattern or root cause that explains why the mapping fails for certain vendors while succeeding for others.

From a technical standpoint, the migration process relies on the available vendor and store associations during conversion. If there is a specific condition in the source data or migration sequence that causes the expected mapping to fail, we first need to reproduce that condition before we can confidently investigate and implement a fix. At this time, our internal testing has not exposed any behavior that would result in store_id = 0 for only a subset of vendors.

Based on the examples you shared, it appears that the issue affects specific vendors rather than all migrated records. To help us investigate further, could you identify any common characteristics among the affected vendors or provide any additional information that might explain why those particular mappings fail? For example:

— Whether the affected vendors were created or modified differently from the others.
— Whether they have any unique taxonomy, metadata, or ownership relationships.
— Whether there were any specific migration steps or historical changes that distinguish them from vendors that migrated successfully.

Without a reproducible scenario or a clear pattern that consistently leads to this behavior, it is very difficult for us to develop and validate a reliable fix.

We appreciate your cooperation and look forward to any additional information you can provide.

[Sangita Support Squad]

Hi there,

Thank you for getting back to us with the details.

I will share the informations with our development team and get back to you with an update as soon as possible.

Thank you for your patience, understanding, and continued support.

[Sangita Support Squad]

Hi there,

Thank you for reaching out and for providing the detailed information. Our responses to your queries are provided inline below:

1. Is the store_id = 0 linking failure a known migration issue, and is it fixed in a newer release? We are already on the latest Free and Pro, and it is reproducible on a clean single migration.
2. Is there a supported way to repair / regenerate the commission-to-store links and rebuild store_users after migration, without creating duplicates?

>> You are the second user to report this issue to us about the store_id set to 0. Our team has already investigated it, but so far we have not been able to reproduce the behavior on our end. Without a reliable way to reproduce the issue, it becomes difficult for us to identify the root cause and implement a fix.

If possible, could you please share the exact steps or any specific trigger that consistently reproduces the issue? Any additional details, logs, or observations would be greatly appreciated and will help our team investigate and resolve it more effectively.

3. For both the admin and vendor lists, can the default ordering be set to newest-first, and are the sorting / pagination / date-filter behaviors known issues?

>> We have tested this on our end, and by default the listings are already sorted from newest to oldest. You can refer to the following screenshots for reference:

https://www.awesomescreenshot.com/image/61186784?key=91af8df65d3c17ec3d23af522feeb1d0
https://www.awesomescreenshot.com/image/61186795?key=6bbfb9e9b71cf65dbe715054d9a8e1f8

We also verified the pagination functionality, and it appears to be working correctly in our testing environment.

Since these behaviors are not reproducible on our end, could you please perform a quick compatibility check by temporarily activating only the default required plugins (WooCommerce, MultiVendorX, and MultiVendorX Pro) and switching to a default WordPress theme? This will help determine whether another plugin or the active theme is influencing the behavior.

Regarding the store_id = 0 issue, we would really appreciate it if you could share any additional information or a reproducible scenario that might help us replicate the problem. This will allow our team to investigate it further and work towards a resolution.

We look forward to hearing back from you.

[Sangita Support Squad]

Hi there,

We have already released MultiVendorX 5.0.0, which includes fixes for the issues you mentioned. You can update the MultiVendorX plugin to the latest version on your site and check.

Since MultiVendorX 5.0.0 is a major upgrade, we strongly recommend performing the update on a staging site first, especially if you’re upgrading from MultiVendorX 4.0.x to 5.0.x. This will allow you to confirm that everything is functioning as expected in a safe testing environment before applying the update to your live site.

Once you’ve verified that everything is working correctly on the staging site, you can proceed with updating your live website with confidence.

For additional guidance on the upgrade process, you can also refer to our documentation here:
https://multivendorx.com/release/.

If you encounter any issues during the upgrade or have any questions, please let us know. We’ll be happy to assist you further.

[Sangita Support Squad]

Hi There,

Thank you for getting back to us with the details.

After reviewing the situation, this appears to be an isolated case, as we have not received any report of store duplication from other users who have upgraded from MultiVendorX 4.0.x to 5.0.x.

Based on our analysis, this behavior seems to be related to a possible database inconsistency or corruption on your site, which may be causing unexpected data duplication during the upgrade process.

To move forward, we would recommend first addressing and resolving the database-level issue on your end. Once the database is stable and clean, you can proceed with the upgrade again.

If you have an in-house developer, they should be able to assist you in reviewing and fixing the database integrity. Alternatively, if you prefer, you may also reach out to our service team for assistance here: https://multivendorx.com/custom-development/ and they will be happy to help you resolve the issue.

Once the underlying database concern is resolved, the upgrade should work smoothly without any store duplication issues.

Please feel free to reach out if you need any further assistance—we’ll be happy to help.

[Author]

Posts