I am trying to:
Access admin/dashboard after updating to 4.6.4. I was able to log in going directly to /login.php, but still receive the error attempting to access anything other than the front-end. All translations are ok on the front-end, just cannot access admin dashboard without fatal error reported below. I can access admin/dashboard in local dev environment, but not after deploying to WPEngine staging environment with a clone of prod data.
Link to a page where the issue can be seen: hidden link
I expected to see:
Admin Dashboard
Instead, I got:
Fatal Error
/plugins/sitepress-multilingual-cms/classes/container/class-config.php on line 63 and defined in /nas/content/live/eenstaging/wp-content/plugins/sitepress-multilingual-cms/classes/user/UsersByCapsRepository.php:18
Stack trace:\n#0 /wp-content/plugins/sitepress-multilingual-cms/classes/container/class-config.php(63): WPML\\User\\UsersByCapsRepository->__construct(Object(wpdb), Object(WPML_Language_Pair_Records))
#1 [internal function
PHP Fatal error: Uncaught TypeError: Argument 2 passed to WPML\\User\\UsersByCapsRepository::__construct() must be an instance of WPML\\User\\LanguagePairs\\ILanguagePairs, instance of WPML_Language_Pair_Records given, called in /wp-content/plugins/sitepress-multilingual-cms/classes/container/class-config.php on line 63 and defined in /plugins/sitepress-multilingual-cms/classes/user/UsersByCapsRepository.
Languages: English (English )French (Français )Arabic (العربية )
Timezone: Pacific/Easter (GMT-06:00)
Hello,
Thank you for contacting WPML support team,
Before sharing a possible fix for this, could you please specify how exactly have you updated WPML ? Was it done from the WP dashboard or from our installer OTGS
We recently got a similar case that was related to OPCACHE, and it was fixed by restarting the PHP server, you need to restart the PHP-FPM from your server side.
Your hosting provider should be able to run this command.
----
Furthermore, we would like to ask you to enable debug information for this matter, which will provide us with more insights about your website. You may refer to this link for instructions on how to do this: http://wpml.org/faq/provide-debug-information-faster-support/
Please let me know how the plugin was updated and if the PHP restart helped.
Our plugin updates are managed via a repository using pipelines to deploy to WPEngine. WPML was update by manually downloading the latest release, applying and testing in a local environment, committing to a repo, then deployed via pipeline to the staging environment at WPEngine.
I contacted WPEngine to see if restarting PHP / PHP-FPM was possible. Unfortunately, they are unable to do so. They did force NGINX reset, but it was unsuccessful.
I cannot provide complete debug info via the admin UI as it is unaccessible, but I can provide the following environment info:
Tried PHP8 and reverted to PHP 7.4
Wordpress 6.2.2
Languages: English (English )French (Français )Arabic (العربية )
Timezone: Pacific/Easter (GMT-06:00)
Hello,
Thanks for the details and patience,
1. After seeing the deployment process, it makes sense that something could go wrong, so first I would check that the new files are present.
The expected content is in this file:
/wp-content/plugins/sitepress-multilingual-cms/classes/language/class-wpml-language-pair-records.php
If the file is correctly placed, it should contain this in line 14:
class WPML_Language_Pair_Records implements ILanguagePairs {
If the file was not correctly deployed, it will contain the old code in the line 13 (shifted one line):
class WPML_Language_Pair_Records {
This would indicate a problem in the deployment process, and you need to check it.
2. If you see the file content is correct, then you can alternatively invalidate OPCache for that specific file. (I assume WPEngine uses OPCache, since I saw they have some post about it for PHP7.4)
You need to run this from a http-served script (not CLI/SSH):
3. If still you don't get it working, please send us the content of your phpinfo(), we can then figure out what setting is preventing the code refresh.
1. Deployment process is fine. Can you explain why 'it makes sense that something could go wrong' when using continuous integration and deployment instead of installer OTGS? Is it something specific to the plugin?
Regardless... The file was correctly deployed and I have verified ALL files in the plugin are the most recent.
Would the file loading process and caching be any different when using the installer OTGS in the staging environment? If so would we run into the same issue when deploying files from staging to the production environment instead of using the installer OTGS in production environment as well?
2. Unfortunately, opcache_invalidate() is in the list of disable_functions at WPEngine, so cannot be run using it directly or via wordpress' wp_opcache_invalidate() function.
3. phpinfo can be viewed at the following link: hidden link
Languages: English (English )French (Français )Arabic (العربية )
Timezone: Pacific/Easter (GMT-06:00)
Hello again,
Thanks for your reply,
My apology for not making this clear enough, what I tried to say is that we tried to replicate this issue using OTGS installer and Manual update, we weren't able to replicate the issue in either cases.
When you specified that you used a pipeline deployment, the dev team conducted that this specific method along with OPcache caused the class to not refresh. WordPress kept loading the old class.
With that said, I cannot really confirm myself if the installer OTGS in the staging environment could have the same issue without trying it.
Overall, I still do not have all the details yet, however, I'm sharing your phpinfo file and will see if they have another workaround instead of the opcache_invalidate(), there might be something there that could explain all this.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: Europe/Madrid (GMT+02:00)
Hi,
my name is Marcel, and I will reply to you in the meanwhile as my colleague Ilyes is off today.
Based on your provided phpinfo, the OPCache configuration seems good. Given the configuration, this is a trivial question, but I have to make it: Did you try to wait at least 10 seconds until you get the fatal error and then try to reload? This is the time period set for revalidated files. You can find it in your phpinfo as "opcache.revalidate_freq)".
We might suspect that if you try and roll back immediately when you see the first fatal error, it will not give to OPCache to refresh. Otherwise, as you mentioned, we suggest using the installer on the staging environment.
