Open
Reported for: WPML Multilingual CMS 4.6.13
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.