Hello @magustsf,
Sorry to hear you’re facing this issue.
Could you please share how this page was created on your end (https://rookwoodstudios.com/artist/)? For example, are you using a specific shortcode, template, or custom setup? This will help us understand the source of the issue more accurately.
As for the loading issue, we’ve already worked on a fix and will be releasing an update tomorrow.
Best regards,
Moumita
The page is currently a toolset views page so I can control the way the shop cards are displayed.
This is not what is causing the issue as it still occurs if I use the build in shortcode to display the stores list. The same list shows, just with a different layout but the behaviour remains, with 1 extra issue. Using the MVX shortcode the view store link appears as ‘url/artist//storename’ (notice the double forward slash) and clicking the link will take us to the store page as long as the option to hide suspended stores is not selected.
I’ve double checked the settings in MVX and the storefront base is populated correctly. I rolled back to before the plugin was updated and did notice that during the upgrade the plugin page suddenly showed a red 530 error message on the plugin card stating that the site was busy so maybe related?
Hi @magustsf , Thank you for sharing the details. From what we understand, you are currently facing two separate issues, so let’s address them one by one.
1. Double “//” in store URL
We have checked the store links on your site, and we were unable to reproduce the issue where the URL contains a double forward slash (//). The store links appear to be generating correctly on our end.
Could you please recheck this from your side and confirm if the issue is still occurring? If possible, sharing a specific store link where this happens would help us investigate further.
2. 302 redirect issue
Regarding the 302 behavior you mentioned, we’ll need a bit more clarity to properly identify the cause.
Would it be possible for you to share a short screen recording showing:
- The steps you are taking
- Where the redirect happens
This will help our team accurately reproduce the issue and provide a proper fix.
Once we have these details, we’ll be able to assist you more effectively.
Looking forward to your update.
Hi
I have added a clone of the page to use your [marketplace_stores] shortcode do highlight the // issue. This is available at https://rookwoodstudios.com/artists2.
the video is available here
Hi there,
Thank you for your patience and help till now.
We kindly request that you update MultiVendorX to version 5.0.1.
In this update, we’ve addressed the issue with the double forward slash (“//”) in the store URLs, ensuring the links display correctly. Additionally, on the vendor list page, only active stores will now be visible, resolving the previous issue of suspended stores appearing.
Please update your plugin, and let us know if you encounter any further issues. We’re here to assist you!
thanks for the update, it has resolved the issue with the double slash in the view store link. However the 302 redirect still occurs if suspended stores are hidden. It still takes the user to the WC shop page with a heavily reduced product list.
I have left that option enabled so you can see the issue on https://rookwoodstudios.com/artists2
I will leave the setting enabled for 1 hour, but will need to unset it to restore functionality.
Hi @magustsf,
As per our default flow, only active stores are displayed on the store listing page.
From your setup, it seems that the vendor list created via Toolset might also be including suspended stores. Since the option “Hide store and products” is enabled (https://prnt.sc/Ne75r5kKgF-O), clicking on such stores will not take users to the store page and instead redirect them to the shop page.
Could you please confirm if the stores in question are currently set to suspended?
my toolset view filters out suspended stores by default. the page I linked /artists2 shows only enabled stores using your shortcode as does the views page /artists. Neither shows the suspended stores if the option is enabled, but trying to visit any store from either page results in the 302 error.
Hi @magustsf ,
Thank you for reporting this.
We’ve been able to recreate the issue on our end, and our team is currently working on a fix. We will be releasing an update shortly to resolve this.
In the meantime, you can track the progress of this issue here:
https://github.com/multivendorx/multivendorx/issues/1701
We appreciate your patience and will keep you posted once the fix is released.
Thanks for the update. On another note, I cannot find anywhere in settings to change how many products are shown per page for the stores. Is this changeable or will I need to have a modified template in my theme files.
Hi,
MultiVendorX 5.0 has been built following standard WooCommerce and WordPress practices.
Currently, the store listing is controlled by the “Blog pages show at most” of WordPress setting. However, ideally, the store/shop page should follow Appearance → Customizer → Products per page. We’ve identified that this is not working as expected and will address it in our next update.
Additionally, we’ve fixed the issue related to store status.
If you’d like to get the updated working version before the official release, please feel free to contact us here.
Three times now, since the initial 5.0 update, all our non legacy vendors get deleted from the user store and their mvx stores no longer appear on our views page as it parses users with the store-owner role. The only stores that still show are the legacy stores setup when the plugin was still called woocommerce multi vendor.
Every time this happens I have to restore the users table in the database to get the accounts restored, and then reset their role to store owner.
In the mvx stores list in the admin backend, when viewing the store settings page, all stores show the product count for the entire site, not their store.
We would also like to know how to get the store description visible on the storefront page for each vendor, as it was in the previous version.
Hi @magustsf,
Thank you for sharing the detailed information – we understand how frustrating this must be.
When migrating from version 4.2.42 to MultiVendorX 5.0, the plugin runs a one-time migration process. During this:
- All vendors are converted to store owners
- Corresponding stores are created
- Existing products are mapped and assigned to their respective stores
So ideally, all vendor data and mappings should remain intact after this process.
In your case, we’re not entirely clear what you are referring to as “legacy vendors.” Also, please note that after the initial migration to 5.0, no further migration process runs in subsequent updates. So repeated issues during updates are not expected and suggest that this may be a site-specific or environment-related issue, rather than a general behavior.
To better understand what’s happening on your end, could you please share a screen recording demonstrating the issue? This will help us trace the exact flow.
Alternatively, you can reach out to us directly here so our team can assist you more closely:
https://multivendorx.com/contact-us/
We’ll be happy to investigate this further and help you resolve it.
when I say legacy vendors, I mean vendors that were created when the plugin was still called woocommerce multi vendor, before the rebranding to MultiVendorX. All of our stores and their corresponding user accounts were setup through the woocommerce multi vendor/multivendorx plugin admin pages which created the corresponding user as part of the process. In this new version the user account must already exist and be linked as the store owner when adding a new store.
The only user accounts that get deleted are the ones created after the rebrand to MultiVendorX.
The only thing I would be able to show you in a screenshot/recording would be the fact that the product counts on the backend store settings pages display the total count of all products and outstanding orders rather than those only belonging to that store. That is until the accounts get deleted again.
Hi @magustsf,
It appears that the migration from version 4.2.42 to 5.0 may not have completed on your end.
The good news is that the migration process runs via cron jobs. You can also trigger or verify this manually using a plugin like WP Crontrol. Please look for the cron event named mvx_full_migration (as shown here: https://snipboard.io/lDR5h1.jpg).
Could you please check whether this cron job is present and running on your site, and let us know the status?
