Mark Parnell

Thanks Andrés, that looks to have fixed it. Appreciate all your work here.

Hi Andrés,

Yes, the updated version of class-wcml-currency-switcher.php you provided fixes the display of the currency switcher on grouped products. It’s just the display of the grouped products in the archives when a secondary currency is selected that’s still tripping us up here.

Hi Andrés,

Thanks for looking into this. If you have a look at a store archive page (e.g. https://pink-flute.sandbox.otgs.work/shop/ or https://pink-flute.sandbox.otgs.work/product-category/uncategorized/) initially you can see both the grouped product and the sub-products. However if you go into one of the products and switch the currency selection to USD, then when you return to the archive pages only the sub-products are displayed. This is particularly a problem as we plan to auto-select the currency based on the user’s location, so they just won’t see the grouped products in the first place.

It looks like the same logic that was applied to the single product page around the display of the currency selection needs to also be applied to the filters that control which products are shown on the archive pages.

Thanks Andrés, that does seem to fix the issue with the display of the currency selector on the grouped products. We have however discovered a related issue – the grouped products still don’t show in the product archives etc when the secondary currency is selected.

Thanks Andrés. The client is keen to get this up and running – any idea what sort of timeframe we might be looking at so I can manage their expectations?

Thanks Andrés. Have added a basic Grouped product to that sandbox and enabled the “Show only products with custom prices” option and confirmed that the same issue occurs – the currency switcher is available on the sub-products if we view them directly, but it’s not available on the parent product.

Please let me know if you need any more details.

Thanks again. We got it working, though native support in the plugin for file uploads would be fantastic.

Thanks for that. I was hoping the plugin already had a mechanism in place to handle file uploads, but it sounds like we’ll have to do that ourselves. Appreciate your help.

Thanks for the quick response. Yes, we are hooking into ns_cloner_process_finish to handle our custom fields and have everything working for other fields – we just can’t work out how to access the file upload, as ns_cloner_request() only seems to look at $_GET and $_POST, not $_FILES. The only thing the POST data seems to have for the file is a dummy path (something along the lines of C:\\\fakepath\\\filename.png).

Ultimately what we are trying to do is to add the image to the media library for the new site and then store it as the value for a theme option. I’m confident that if we can just manage to access the file details in the first place the rest of it should be smooth sailing.

Hey @umbrellaweb, thanks for the report. We’ve just released version 1.3.2 which fixes this notice (along with a few other minor issues).

Hi @umbrellaweb,

We’ve just released version 1.3.0 which adds the ability to filter failed submissions by ID, error message or IP address.

Thanks once again for the feedback!

Hi @webstationone, thanks for the question! Can you provide some more detail as to what problem you’re trying to overcome?

The email notification is sent after multiple failures, so I’m not sure I entirely understand your request – are you wanting it to list those details for all of the recent failures, or just the last one? What exactly are you trying to achieve?

We can of course add additional details to the email – I just want to make sure I understand the purpose so we can ensure the solution fits the problem. ??

We’ve just released version 1.2.0 which adds the ability to delete failed submissions (either bulk or individually), as well as a few other new features.

FYI filtering submissions didn’t quite make it into this release, but it’s top of the list for the next update.

Thanks @icc0rz – we had exactly the same problem with the latest version of Smush.

For anyone else who runs into this problem you can tell Smush to leave the H5P iframes alone using the Classes & IDs setting in the Lazy Loading section of the Smush dashboard. Just add .h5p-iframe to the list.

That way you can still run Smush, including lazy-loading, without it breaking H5P.

Deleting records is something we’re already looking at – we have been thinking more about the privacy implications, but your point about bloat makes sense too. And being able to filter the records would definitely be a great addition too, both on its own as well as in conjunction with deletion.

We’ll definitely look at including both of those in the next update.