Skip to content Skip to sidebar

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 17:00 9:00 – 17:00 9:00 – 17:00 9:00 – 17:00 9:00 – 17:00 -
- - - - - - -

Supporter timezone: Europe/Warsaw (GMT+01:00)

Tagged: 

This topic contains 4 replies, has 0 voices.

Last updated by HANS 5 days, 11 hours ago.

Assisted by: Łukasz Rydygel.

Author Posts
January 26, 2026 at 4:13 pm #17763545

HANS

When trying to export orders reports from WooCommerce using a non-default currency, the export fails.
The issue is that when the report generation is initially queued, the currency is not properly determined.
We already implemented a fix in our project, but it would be really nice if you could fix the plugin.
The problem is, that our current implementation relies on debug_backtrace() to get the currency from the ReportCSVExporter object, because in prepare_data_to_export() the currency is not passed to the woocommerce_export_report_data_endpoint filter and it is contained in a protected property.
This means, that for a proper fix you probably need the help of the WooCommerce authors.
I'll attach the patch, if possible.

January 27, 2026 at 5:20 am #17764866

Prosenjit Barman
WPML Supporter since 03/2023

Languages: English (English )

Timezone: Asia/Dhaka (GMT+06:00)

Hi there!

Thanks for contacting WPML Support.

I'm Prosenjit from the WPML Development Team, and I'll be happy to help you resolve this issue.

I completely understand the problem you're having. Based on your description, I tried to replicate the issue following these steps — please let me know if I'm missing anything:

1. Added USD as a secondary currency
2. Made an order using that secondary currency
3. Completed the purchase
4. Set the order status to "Completed" from WooCommerce → Orders
5. Went to Analytics → Orders
6. Selected the secondary currency from the Currency dropdown
7. Clicked the Download button to export the orders

In my environment, the orders in the secondary currency were exported without any issues. In the CSV file, I can see the currency and all other details displaying correctly.

Since I wasn't able to replicate the issue with these steps, could you please confirm whether the steps I followed are correct? Are there any additional steps included to replicate the issue?

Could you please share the exact steps you're taking when the error occurs? A short video showing the process would be incredibly helpful, as it would allow me to replicate the issue exactly as you're experiencing it.

I really appreciate you sharing the patch. However, before we can proceed with implementing a global fix, it's essential for us to replicate the issue in a minimal environment first. This ensures we're addressing the root cause and that any fix we implement works correctly across all scenarios. I hope you understand.

Once you share the replication steps, I'll test it on my end and work on providing you with a proper solution.

Looking forward to your response!

Best regards,
Prosenjit

January 30, 2026 at 7:22 am #17775874

HANS

Hi Prosenjit,

I can't really provide you with a MRE / step by step reproduction.
The customer, we developed the patch for does not want to pay for that.

I can tell you that one precondition is, that the currency, which is used in prepare_data_to_export() needs to have more orders than the one which is used during processing.
This then causes the final progress percentage to be at above 100%, and because the mail is only sent at exactly 100 %, in these cases it is not sent at all.

The main problem is that the ReportExporter triggers ReportCSVExporter()->prepare_data_to_export() two times and one time, the currency differs from the other time.
One time is in ReportExporter->queue_report_export() (here the wrong currency is used) and the other in ReportExporter->export_report().
The api request where the currency is wrong happens in ReportCSVExport->prepare_data_to_export().
The first time it is called directly, the second time indirectly via ReportCSVExporter->generate_file().

If you look at the api request, which is sent in prepare_data_to_export() you can see that the currency in the params differs.

The currency configuration we have is that the default currency is CHF and the shop also accepts EUR.
The problem then only occurs, when trying to create a report for EUR.
In this case the first api request has the currency set to CHF instead of EUR.

I hope that helps you develop a fix.

Kind Regards

January 30, 2026 at 1:29 pm #17778349

Prosenjit Barman
WPML Supporter since 03/2023

Languages: English (English )

Timezone: Asia/Dhaka (GMT+06:00)

Hi,

Thank you for the detailed technical analysis and for sharing that. I've reviewed the code flow you described and understand the issue with prepare_data_to_export() being called twice with different currency contexts.

However, I've been unable to replicate this issue using the standard WooCommerce Analytics export workflow. When using the built-in "Download" button in "Analytics → Orders", the export happens directly (via JavaScript) without going through the queued/batch process (ReportExporter::queue_report_export()). Could you please try that?

The code path you've described — where the export is queued, and an email is sent upon completion — is triggered only in specific scenarios:

- When the export is initiated via REST API with the email: true parameter
- When using certain third-party reporting plugins that utilize the queued export functionality

Could you please clarify:

- Which plugin or method are you using to trigger the "Email me when done" export functionality?
- Are you using any third-party reporting or export plugins alongside WCML?

Additionally, to investigate this further and verify the exact behavior in your environment, would it be possible to provide temporary admin and FTP/SSH access to your staging site? This would allow us to:

- Reproduce the exact workflow you're experiencing
- Debug the currency values at each step
- Validate the fix before implementing it globally

I've enabled the Private box for you so that you can securely share the access.

We want to make sure that any fix we apply correctly addresses the root cause and works reliably across all scenarios. I hope you understand and can cooperate with us on this.

Looking forward to your response.

Best regards,
Prosenjit

February 9, 2026 at 4:06 pm #17806237

HANS

Hi Lukas,

you can now access the wue000single-s user via your ssh key.

Kind regards