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.
Tagged: Bug
This topic contains 4 replies, has 0 voices.
Last updated by Itamar 2 weeks ago.
Assisted by: Itamar.
| Author | Posts |
|---|---|
| February 3, 2026 at 5:44 pm | |
|
dianaV-9 |
Hello WPML Support Team, I would like to follow up on a critical fatal error related to WPML, with additional confirmation from our hosting provider. Error message: Critical Uncaught Error: Maximum call stack size of 8339456 bytes File: This error occurs repeatedly and causes site instability. Hosting provider investigation (important) We have asked our hosting provider to fully investigate this issue on the server level. This is not a server-side or PHP configuration issue No recent server or PHP updates were made that could cause this behavior PHP version and stack/memory-related settings are correctly configured Modifying zend.max_allowed_stack_size would not be a real solution, as the root cause is an application-level infinite recursion The error clearly points to a logical issue inside the WPML plugin, or a compatibility conflict between WPML and another plugin or the active theme According to the hosting provider, the error indicates that a WPML internal function repeatedly calls itself in an infinite loop, which PHP interrupts for safety reasons. Environment details WordPress: latest stable WPML Multilingual CMS: latest version WPML add-ons: String Translation, Translation Management PHP version: 8.x (confirmed stable and supported by hosting) Hosting: cPanel-based environment Page builder: Elementor No custom code interacting with WPML hooks or filters Observations The error occurs during normal WordPress execution (admin and frontend) It sometimes coincides with WPML-related operations (translations, synchronization) Disabling WPML stops the error entirely (confirmed by testing) Questions Is this a known issue or regression in recent WPML versions? Are there known conflicts between WPML and Elementor that could trigger this recursion? Is there a recommended fix, patch, or workaround, or should we roll back to a specific stable WPML version? We are happy to provide: Full debug logs WPML debug information Temporary admin access if needed Thank you for your assistance — this issue is currently blocking stable operation of the site. Kind regards, |
| February 3, 2026 at 8:34 pm #17789574 | |
|
Itamar WPML Supporter since 02/2016
Languages: English (English ) Timezone: Asia/Jerusalem (GMT+02:00) |
Hi, I'm consulting our second-tier supporters about this issue and will update you here once I have their reply. Regards, |
| February 4, 2026 at 9:09 am #17790417 | |
|
dianaV-9 |
When can I expect some help with my 2 websites? It would be very important for the problem to be resolved and for me to finally be able to launch my ads. Because until my website is stable, I cannot run the ads. |
| February 4, 2026 at 9:23 am #17790436 | |
|
dianaV-9 |
Dear Andrey, Thank you for your message. I have added and saved the required PHP 8.3 settings on both websites via cPanel (MultiPHP INI Editor): zend.max_allowed_stack_size = 256K zend.reserved_stack_size = 48K After applying the changes, I cleared all caches and retested, but the critical fatal error / infinite recursion issue still persists. Could you please advise on the next troubleshooting step (e.g., what logs or debug information you would like me to provide)? Best regards, Balazs |
| February 4, 2026 at 10:24 am #17790758 | |
|
Itamar WPML Supporter since 02/2016
Languages: English (English ) Timezone: Asia/Jerusalem (GMT+02:00) |
Hi, Balazs. I didn't provide the workaround you mentioned above. It was my colleague in another ticket you opened here: https://wpml.org/forums/topic/critical-fatal-error-infinite-recursion-in-wpml-confirmed-not-server-side-issue-2/. For your information, there is no need to open more than one ticket per issue. In any case, our second-tier supporter suggests trying the workaround in this errata: 1. Take a backup of the site in case something goes wrong. zend.max_allowed_stack_size = -1 zend.reserved_stack_size = -1 4. Save the changes. Regards, |