[Risolto] WPML 4.9.0 causes 504/memory exhaustion on wp-admin pages

Hello,

Thank you very much for reporting this issue!

Take kindly note that to investigate this issue, we need access to your site, as this issue can be very site-specific.

It would be ideal if you could provide access to a staging site. If you do not have a staging site available or can not provide one, I can offer to take a local copy of your site if you provide me with admin access. I would enable a private reply form in this case.

About the error:
DebugBackTrace is a utility class used by multiple parts of WPML.

The DebugBackTrace class provides a 'forensic map' of function calls to help WPML understand the current code context. In complex Elementor pages with many widgets, WPML is forced to generate hundreds of these massive 'maps'—often containing the same 150+ lines of history—faster than the server can clear the memory. This leads to the memory exhaustion you are seeing.

Diagnostic workaround:
Please note: This is a diagnostic workaround to verify the cause of the memory error. This change will be overwritten if you update the plugin, so please keep a backup of the modified file.

File to Edit: wp-content/plugins/sitepress-multilingual-cms/addons/wpml-page-builders/classes/Integrations/Elementor/WPML_Elementor_Translate_IDs.php

Task: Modify the should_translate_template method to capture the stack only once per check.

Replace the existing function with this code:

private function should_translate_template() {
    // 1. Manually update the backtrace exactly once for this check
    $this->debug_backtrace->get_backtrace();

    // 2. Perform all checks without refreshing the stack again (passing false)
    return $this->debug_backtrace->is_class_function_in_call_stack( 'ElementorPro\Modules\Library\WP_Widgets\Elementor_Library', 'widget', false )
        || $this->debug_backtrace->is_class_function_in_call_stack( 'ElementorPro\Modules\Library\Classes\Shortcode', 'shortcode', false )
        || $this->debug_backtrace->is_class_function_in_call_stack( 'ElementorPro\Modules\Library\Widgets\Template', 'render', false )
        || $this->debug_backtrace->is_class_function_in_call_stack( 'ElementorPro\Modules\Forms\Classes\Ajax_Handler', 'ajax_send_form', false );
}

It only affects how WPML handles Elementor IDs. If applying this workaround will solve the memory exhaustion issue, please let me know.

Final test:
Check a page that uses Elementor Global Widgets and Templates after applying the code. If the Global Widgets and Templates still translate correctly, the workaround is perfect.

Site access:

I will be glad to test this for you on a staging site or a local copy of your site and request temporary access (wp-admin and FTP) to the website to investigate the issue further.

You'll find the necessary fields below the comment section if you log in to leave the next reply. The information you provide will be private, meaning only you and I can see and access it.

IMPORTANT
Please be sure to create a backup of the website and database before granting us access.

If you don't see the "wp-admin / FTP" fields, your login credentials for the post and website will be set to "PUBLIC." Do NOT publish the information unless you see the required wp-admin / FTP fields.

The private reply form looks like this:
link nascosto

When replying again, click "I still need assistance".

Video:
link nascosto

Please note that we are required to request this information individually on each ticket. We are not permitted to access any login information that was not specifically provided in the private reply form for this ticket.

Best regards
Andreas

I am glad to hear that the issue appears to be solved!

The latest update WPML 4.9.2 fixed an issue with missing custom fields in translations and an issue where Full Site Editing templates were not applied to translated pages.

In your case the issue seems to have been related to Elementor and the prior WPML 4.9.1 update had various fixes for Elementor:

https://wpml.org/it/download/wpml-multilingual-cms/?section=changelog

Indeed, but this function that is mentioned in your error could be connected to one of the fixed issues in the last two updates for WPML.

In case the issue occurs again, just reach out to us and we will be glad to look into this.

Hello,

I'd like to request temporary access (wp-admin and FTP) to the website to investigate the issue further.

You'll find the necessary fields below the comment section if you log in to leave the next reply. The information you provide will be private, meaning only you and I will be able to see and access it.

IMPORTANT
Please be sure to create a backup of the website and database before granting us access.

If you don't see the "wp-admin / FTP" fields, your login credentials for the post and website will be set to "PUBLIC." Do NOT publish the information unless you see the required wp-admin / FTP fields.

I may need to install a plugin called "All In One WP Migration" to create a copy of the website on which I can investigate the problem more thoroughly.

I would also be very grateful if you could provide a staging site on your server for this purpose.

If you have any questions about creating such a staging site, please contact your hosting provider. Please ensure that WPML is also registered on this staging site at https://wpml.org/de/account/websites/.

If you are unable to provide such a copy of the website for testing, please let me know on this ticket.

The private reply form looks like this:
link nascosto

When replying again, click "I still need assistance".

Video:
link nascosto

Please note that we are required to request this information individually on each ticket. We are not permitted to access any login information that was not specifically provided in the private reply form for this ticket.

Best regards
Andreas

The staging lost its database connections. It looks like someone recently edited the wp-config.php file. Please verify and let me know once the site is running again.

On this staging site, WordPress was not updated, and there were 22 plugin updates available. This seems to have solved the issue.

Please, before reporting an issue, always make sure that all components are updated.

My apologies for the misunderstanding, but I did not see the wrong website.

I said:
On this staging site, WordPress was not updated, and there were 22 plugin updates available. This seems to have solved the issue.

What I am trying to say here is that I ran the updates already, and the issue does not occur anymore.

Am I misunderstanding the issue?

1) Go to WooCommerce > Ordini
2) Open an order that has "Fattura Numero"
3) Click on "PDF Fattura" in the right sidebar

This works without any 504 error on the staging now.

The only thing unexpected is how the preview of this email is rendered, but this is not related to WPML.