- This topic has 34 replies, 2 voices, and was last updated 2 weeks, 5 days ago by
.
-
Posts
-
-
You haven’t always answered our question. For over two years, we haven’t been able to perform direct updates on our site. You have to make corrections on the test site, and then we upload the corrected plugin to our production site. We would like to know if this has been fixed so that we can now perform updates directly on our production site with a final fix included in version 5.0. Also, regarding the update, I remind you that we have had customizations on our child theme. I would just like to know if this will cause any problems after the update. Regarding the custom plugin, we temporarily disable it, but the most important thing is that it works with the new version for a while. When you remove the customizations for a while, it’s fine.
-
-
Hello Kevajo,
Thank you for getting back to us.
I want to begin by saying that we truly understand how challenging and frustrating your update experience has been over the past couple of years—especially with issues like memory limits disrupting the process. We sincerely appreciate your patience and the trust you’ve continued to place in us throughout this time.
The concern you highlighted has been one of the major factors behind the architectural improvements we’ve introduced. With the release of MultiVendorX 5.0.0, we’re confident that these memory-related issues have been addressed, and the update process should now be much smoother—even on a production environment.
That said, we completely understand your concern regarding existing customizations. Since the plugin has undergone significant changes, the older hooks and filters may no longer behave the same way. As we don’t have direct visibility into the customizations implemented on your end (particularly within your child theme or any custom plugins), adjustments might be needed to ensure everything works as expected.
To make this process as safe and seamless as possible, we would strongly recommend testing the update on a staging environment first. This will give you the flexibility to temporarily disable customizations, check compatibility, and make any necessary adjustments without impacting your live site.
If you need assistance reviewing or adapting your customizations, we kindly suggest reaching out to our custom development team. They will be in a better position to analyze your setup and guide you accordingly.
For MultiVendorX Pro, we are releasing MultiVendorX Pro 2.0.0 today. Once the release is complete, you will be able to download the latest version of the plugin from here: https://multivendorx.com/my-account/api-downloads/
We recommend testing it on a staging site along with the latest version of the MultiVendorX free plugin to ensure everything is working properly before deploying it to your live site.
If you have any further queries or need any assistance, please feel free to let us know.
-
-
-
Hi There,
We are glad to inform you that we have already added fixes for the mentioned issues related to the notices and Blocker 1 in MultiVendorX 5.0.5 and MultiVendorX Pro version 2.0.2.
Kindly update both plugins to the latest versions on your end and check the flow accordingly. If you need any further assistance from our end, please do let us know. We will be happy to assist you further.
-
-
Hello,
Thank you for getting back to us, and we are glad to hear that the new MultiVendorX version is helping you cover many of your previous custom requirements through the default flow. We truly appreciate your feedback.
Regarding your query about manual commission payments in MultiVendorX 5.0.0, the flow has been updated compared to the previous versions. While the earlier “Mark as Paid” option is no longer available in the same way, you can still manage vendor payouts manually from the Transaction History section.
To proceed with manual commission disbursement, kindly navigate to:
Admin Dashboard → MultiVendorX → Transaction History
From there, you can review the commission transactions and disburse the commission amounts accordingly based on your manual payment process to vendors (https://www.awesomescreenshot.com/image/60569613?key=95bd272fded393d30f9e86c14df162eb). This allows you to continue managing payouts manually on your end while maintaining proper transaction records within MultiVendorX.
For more details about the payout and disbursement flow in MultiVendorX 5.0.0, you can also refer to our documentation here:
https://multivendorx.com/docs/knowledgebase/disbursement-of-payments/If you have any further questions or if you need assistance with any customization related to your payout workflow, please feel free to let us know. We will be happy to assist you further.
-
-
Hello there,
Thank you for reaching out and providing the detailed information regarding the issue.
We are sorry to hear that you encountered this duplication after migrating from MultiVendorX v4 to v5.
To help us investigate this further, could you please confirm whether the duplicate store profile issue is occurring for all vendor stores on your marketplace or only for specific vendors?
Additionally, to properly review the migration data and identify the root cause, we would appreciate it if you could provide access to a staging environment where the issue can be reproduced. Please share temporary WordPress admin and FTP access so that our team can thoroughly examine the store records and migration process.
Once we have access to the requested details, we will investigate the issue and assist you with the safest resolution approach.
Also, while sharing the access details, please do not forget to mark your reply as private to ensure that the credentials remain secure.
We look forward to your response.
-
-
Hi there,
Thank you for sharing the site access with us.
As mentioned in our earlier response, could you please confirm whether the store duplication issue is occurring for all existing vendor stores on your site or only for specific stores?
If it is limited to certain stores, it would be very helpful if you could share the names of the affected stores so we can investigate more precisely.
Additionally, please confirm whether we have your permission to temporarily deactivate plugins and switch themes (if required) during our investigation. This will help us perform a more thorough troubleshooting and identify the root cause efficiently.
We look forward to your update.
-
-
-
Hi there,
We checked your site.
We are a bit confused because when we initially tested the migration on your shared site to verify the flow, we did not observe any store duplication issue. Additionally, for other users who have upgraded from earlier versions to the latest release, we have not received similar reports of duplicate store entries.
Since this behavior is only occurring on your setup, we would like to understand if there were any additional actions performed apart from updating MultiVendorX from the earlier version to the latest one. For example, was there any manual migration run, database operation, or plugin/theme change carried out during or after the update?
At the moment, we are not seeing any known trigger in the current migration flow that would result in store duplication under standard upgrade conditions. This is why we would like to carefully review any extra steps or environment-specific changes that may have contributed to this behavior.
Looking forward to your update so we can investigate this further and assist you in resolving it.
-
-
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.
-
-
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=6bbfb9e9b71cf65dbe715054d9a8e1f8We 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.
-
-
-
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.
-
-
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.
-
-
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.
-
-
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.
-
-
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.
-
-
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.
-
-
Hi Kevajo,
Thank you for sharing the details about your migration run and your findings.
Based on the information you’ve provided, the issue appears to be related to these specific user accounts rather than a functional problem with the MultiVendorX migration process itself.
In MultiVendorX versions prior to 5.0.0, vendors were assigned the dc_vendor role. During the upgrade to MultiVendorX 5.0.0, vendors created through the standard MultiVendorX vendor registration flow are automatically migrated to the new Store Owner role.
Since the migration has worked successfully for the majority of vendors on your site and only a specific set of users continues to be affected, this generally indicates that those particular accounts may not have been created through the default MultiVendorX workflow.
In such cases, the users may have been added through custom code, a third-party integration, manual database modifications, or another custom process. Because the migration utility is designed to recognize vendors created through the standard plugin flow, it may not automatically migrate accounts that do not match the expected structure.
We therefore recommend reviewing how these specific vendor accounts were originally created and checking whether any customizations or manual processes were involved.
As this appears to be a user-specific data issue rather than an issue with the migration functionality itself, our support team is unfortunately unable to perform detailed debugging or database-level investigations for these custom-created records. If you require assistance with this, you may reach out to our Custom Development team (https://multivendorx.com/custom-development/). They can review your custom implementation, investigate the underlying database structure, and provide guidance or a tailored solution based on your site’s specific setup.
-
-
- You must be logged in to reply to this topic.
