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.
This topic contains 5 replies, has 2 voices.
Last updated by bhavinG 1 year, 9 months ago.
Assisted by: Subash Chandra Poudel.
| Author | Posts |
|---|---|
| August 30, 2023 at 2:01 pm #14314491 | |
 bhavinG |
Hi, i'm the developer working with the account owner (Ashley). We've been having a problem with the latest version of sitepress-multilingual-cms WPML plugin, after we upgraded to PHP 8.2 and enabled OPCache. We also have WP Super Cache plugin installed. The problem: Entire site crashes with a silent error and no pages (not even wp-admin) can be loaded. But this only happens after a certain WPML file gets cached in OPCache, and even then...its only sometimes. Not sure why yet. The problematic file: sitepress-multilingual-cms/vendor/wpml/fp/core/traits/Curryable.php After a day of debugging this issue I was able to trace it from the top: index.php ...and during plugin init, it gets into: WPML\ST\TranslationFile\Hooks ... and eventually into: WPML\Container\make What I'm seeing is that when you do your late bindings in Curryable, someting in there is crashing PHP or creating a non-recoverable error. Specifically, I did debug bracketing in: ./wp-content/plugins/wpml-string-translation/classes/MO/Hooks/Factory.php and it fails on this call: DomainsRepository::getByStringIds() It never returns from that method call and there is no error or exception shown in the PHP log, even when we turn on WP_DEBUG and / or WP_DEBUG_LOG. I did more debug bracking inside there, and that's how I figured out that something is going wrong in Curryable. Now I'm about to get our web page going again for a few minutes every time, by just invalidating this file: sitepress-multilingual-cms/vendor/wpml/fp/core/traits/Curryable.php but after a few minutes, our site gets visited, files get cached by OPCache, and the crash returns 🙁 I guess I could edit our WordPress to just have an opcache call to always invalidate that file, but I would prefer to see this plugin get fixed so we don't have to have a branched version of WordPress. 🙁 I'm still debugging this and I'll update here as I learn more. (^_^)/ |
| September 1, 2023 at 10:37 am #14326041 | |
 Subash Chandra Poudel |
Hi Michael, We currently have a performance issue with the latest version of the WPML string translation plugin in some cases as explained in the next link: This case might be related or not, but we now have a beta version of the plugin fixing the issue can you please try the following and see if it helps: - Backup the site completely first to prevent any issues or data loss. - Go to wp-admin -> Plugins -> Add New -> Commercial ( tab at the top ) - For "Updates channel" select "Beta" and update WPML and String Translation to the latest release. If the issue persists, can you please do the following tests as well and let me know how it goes: - Downgrade PHP to 8.1 or 8.0 and see how it goes, If it does not help also downgrade to 7.4 and see how it goes. - Test with all plugins except WPML plugins deactivated and with a default theme like twenty twenty-three and see how it goes. ( Make sure to test this on a staging site if possible ). Looking forward to your reply. Regards, |
| September 6, 2023 at 2:05 pm #14353139 | |
|
bhavinG |
Thanks, working through those now. I did upgrade to 4.6.6 just this morning. I think the bug is still reproducing, but I'm confirming now. I will try the other stuff, but we have limited options for downgrading, we have strict requirements for security so going backwards is not really an option. I'm also trying to narrow down how that late closure binding is failing. Currently (after the upgrade), I'm seeing a lot of this error in the log: [06-Sep-2023 13:58:58 UTC] [WARNING] lvl: 8192 | msg:Creation of dynamic property WPML_LS_Menu_Item::$current_item_ancestor is deprecated | file:/var/www/html/public_html/wp-includes/nav-menu-template.php | ln:540 I'm not sure it's directly related to WPML...but WPML seems involved 🙁 Still investigating...I'll keep you updated... |
| September 6, 2023 at 2:07 pm #14353145 | |
|
bhavinG |
This error is also coming up a lot: [06-Sep-2023 14:06:02 UTC] [WARNING] lvl: 8192 | msg:Creation of dynamic property wpml_cms_nav_cache::$name is deprecated | file:/var/www/html/public_html/wp-content/plugins/wpml-cms-nav/inc/cache.class.php | ln:36 |
| September 6, 2023 at 2:41 pm #14353339 | |
|
bhavinG |
I might have something, I'm seeing this which is from a custom theme plugin (3rd party). I'll dig in and see if its something I can fix/remove. I think what makes this hard to work through is that it doesn't happen until it gets cached...and you can only see the error exactly once, when it gets cached. After that the code doesn't "parse"...because its cached...so it still fails, but you don't see the error. So, you have to be watching the log with the right order of operations to even spot the shutdown error. I'm digging... The traceback: [06-Sep-2023 14:36:19 UTC] X: back from Closure::bind(). [06-Sep-2023 14:36:20 UTC] [ERROR ON SHUTDOWN] Stack: #0 [internal function]: {closure}() |
| September 6, 2023 at 3:48 pm #14353995 | |
|
bhavinG |
Starting to look like the problem is elsewhere, I finally found the log file where the the missing error messages were going, and it had: [Wed Sep 06 15:40:49.393900 2023] [core:notice] [pid 2640546] AH00051: child pid 3014313 exit signal Segmentation fault (11), possible coredump in /opt/extras-php-8.2 A core dump would explain a lot! 🙂 I hadn't thought it was a crash, because the code kept going dark in the very same place, every time. But this morning, after the upgrade, I couldn't replicate that...but was still seeing the crash. I chased down other errors in the system, and I got to the point where there was no visible error being reported; even by the shutdown function. There were errors, but its just "deprecated" kind of stuff. So, I'm thinking now what was and is happening, is a crash. Not clear where exactly or why; I'll try to get the system (its Ubuntu) configured to at lesat write out the core file somewhere, and maybe I can get that into a low level debugger to at least get a call stack. That might give some clues about the context. |
| September 6, 2023 at 6:51 pm #14354911 | |
|
bhavinG |
Hey, so I was able to recompile everything with debug info, then reproduce and get a core file, and load that in GDB, and...looks like the issue is a legit SIGSEGV in opcache. Specifically, if I completely disable JIT...crashes don't happen. We have other issues, but no crashes if JIT is not enabled. From the opcache logging; seems to happen after you get enough stuff loaded. Its not interned string buffer overflow...we did have that as well, but I increased that buffer size and now the only issue seems to be JIT. So, this is not a WPML thing. Since I can turn the crashes on/off by enabling/disabling JIT...there is a bug in OPCache 🙁 I'll close this issue here, since I don't there is anything you guys can do about it...this is a core PHP bug. Even if WPML is doing something bad, PHP is not supposed to crash. Thanks for your support though! (^_^)/ |