Resolved
Reported for: WPML Multilingual CMS 4.6.13
Resolved in: 4.7.6
Overview of the issue
A file naming issue in the Yoast/Whip vendor library included with WPML is causing an error on case-sensitive server environments (e.g., Ubuntu). The problem arises because the folder names were changed from lowercase (e.g., facades) to capitalized (Facades) in WPML 4.6.12. During updates, case-sensitive file systems may retain both folder versions, resulting in conflicts and a 500 error.
PHP Fatal error: Uncaught Error: Failed opening required '.../wp-content/plugins/sitepress-multilingual-cms/vendor/composer/../yoast/whip/src/Facades/wordpress.php' (include_path='.:/usr/share/pear:/usr/share/php') in .../wp-content/plugins/sitepress-multilingual-cms/vendor/composer/autoload_real.php:78
Workaround
Please, make sure of having a full site backup of your site before proceeding.
Reinstall WPML
- Go to the WordPress Dashboard > Plugins.
- Deactivate and delete WPML.
- Reinstall the latest version of WPML from the official website.
Hello!
Is this your final solution? Should I be waiting for a patch of a fix in the form of a new minor revision after the publication the following version?
Version 4.7.0-b.1 – December 16, 2024
I am a little perplexed with the idea of putting my production site offline, in a continuous development workflow where my plugins are in version control, not abstractions I download from an administrative dashboard.
My definition of done for this issue is testable, repeatable, can be deployed over git without manual interventions. If I cannot see the fix happening in my pre-production environment after code deployment that contains of a patched version of WPLM, I am not going there.
In the current state of things, anything after 4.6.5 crashes my Jenkins/Kubernetes builds
Please kindly report.
Hello there,
This issue has been escalated to our devs and they are aware of this situation. However, I can’t offer you an ETA as it entirely depends on their development roadmap.
I’ll keep this erratum updated.
Thank you for your understanding.
My understanding of the situation is that for a licensing issue (yes, our site keys and licenses are up to date), On the go Systems decided to break every site using version control to update plugins. The only way I was able to update plugins was through the usage of the OTGS installer, after punching in a new site key for every specific environnement my site needs to be tested in, one by one.
I can update my plugins locally, but if i commit the result to git and push it on my CICD pipeline, I will crash every one of my site instances (with the error above), including my production, eventually.
The minute I take a snapshot of my production db to reinstall it locally, I m confronted with have to register my local site key in the database again. The location and method to punch in a specific key for a given site instance in a given environnement is cryptic, undocumented, difficult to access and the UX to do so is broken. It needs work.
Please consider upgrading and better documenting this process in top level documentation for registered users, updating this plugins was a serious waste of time and stressful experience for me this time.
Hello there,
Thanks for your detailed feedback. We’re sorry for the inconvenience this caused. Removing the offending folders or deleting and reinstalling WPML should fix the issue.
This has been escalated to our developers.
Since you frequently switch between development and production environments, this documentation might help.
You can set the site key in
wp-config.phpusingOTGS_INSTALLER_SITE_KEY_WPML.Also, if you’re restoring database snapshots, this guide explains the difference between “Site Moved” and “Site Copied”. You probably know that already but in most cases, “Site Moved” is the right option.
If you need further assistance, please open a chat on our support forum. We’ll be happy to assist you.
Hello,
I faced the same issue. If you use git to manage plugins.
– Delete the wpml plugin or move it to another folder
– Push to git
– Copy again or move back the plugin to the plugin folder
– Push to git
It solved my problem.
Hi there,
Thanks for sharing your solution! I’m sure it’ll be helpful to others facing the same issue while our devs are working on a definitive fix.
Hi WPML,
I would like to confirm you are working on a fix for this still. I would love to update WPML, but I can’t afford to delete the plugin to reinstall WPML.
My content is Git Controlled. I was originally told there would be a fix as of 4.7.2, but that doesn’t seem to be the case.
Thanks for you help with this matter!
Hi Amber,
Thanks for reaching out. The fix hasn’t been implemented yet but is planned for the next development sprint. We appreciate your patience and will keep this page updated.
Hi WPML Team,
I’m following up to ask if there’s a timeline for the fix you previously mentioned — I believe you said it was planned for an upcoming sprint?
Like Amber, I’d really like to update WPML and its associated plugins, but I can’t risk having to delete and reinstall the plugin, especially with our Git-controlled setup. Additionally, I need to update WordPress core to 6.8, and holding back on WPML updates could impact compatibility going forward.
Can you confirm if there’s a fix included in version 4.8, or if it’s scheduled for a later release?
Thanks in advance for your help — I appreciate your support on this.
Best regards
Hi there,
Thanks for following up. I checked with our developers, and this was originally implemented to support older PHP versions. However, since then, we’ve (and WP) updated minimum PHP requirements.
While I don’t have an exact ETA, this dependency should be removed in WPML 4.8.
Hi all,
I confirm that in version 4.7.4, with php 8.2, you can’t activate the plugin in Unix environment for the same problem.
Here is an excerpt of the log:
PHP Warning: require(/*****/plugins/wpml-multilingual/vendor/composer/../yoast/whip/src/Facades/wordpress.php): Failed to open stream: No such file or directory in *****/plugins/wpml-multilingual/vendor/composer/autoload_real.php on line 78
[20-May-2025 07:59:29 UTC] PHP Fatal error: Uncaught Error: Failed opening required ‘*****/plugins/wpml-multilingual/vendor/composer/../yoast/whip/src/Facades/wordpress.php’ (include_path=’.:/usr/share/php’) in *****/plugins/wpml-multilingual/vendor/composer/autoload_real.php:78
Stack trace:
#0 *****/plugins/wpml-multilingual/vendor/composer/autoload_real.php(61): composerRequirecae5c4903bcc218a3f2d9bdcbd83a504()
#1 *****/plugins/wpml-multilingual/vendor/autoload.php(7): ComposerAutoloaderInitcae5c4903bcc218a3f2d9bdcbd83a504::getLoader()
#2 *****/plugins/wpml-multilingual/sitepress.php(59): require_once(‘…’)
#3 *****/wp-admin/includes/plugin.php(2387): include_once(‘…’)
#4 *****/wp-admin/includes/plugin.php(673): plugin_sandbox_scrape()
#5 *****/wp-admin/plugins.php(60): activate_plugin()
#6 {main}
thrown in *****/plugins/wpml-multilingual/vendor/composer/autoload_real.php on line 78
Hi,
Yes, this does appear to be the same issue. Please note that the errata is still open, and a fix is expected in WPML 4.8. We’ll keep this page updated with any progress. In the meantime, please continue using the suggested workaround.