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 thread is resolved. Here is a description of the problem and solution.

Problem: Client has defined the 'OTGS_INSTALLER_SITE_KEY_WPML' in every site's wp-config.php and migrates the site from production to dev every 24 hours.

After updating to WPML 3.9.4, when accessing the backend they get a 500 internal server error.

Solution: There have been issues with the new option in the registration when clients checked the new option, "Keep wpml.org up-to-date about which theme and plugins I use" .

Though the client had not enabled that option, rolling back to version 3.9.3 solved the issue.

Relevant Documentation:

This topic contains 3 replies, has 2 voices.

Last updated by Cristina 1 year, 4 months ago.

Assigned support staff: Cristina.

Author Posts
April 27, 2018 at 10:47 am #1857689

lilliR

Hi there,

we have a production ('prod') and development ('dev') environment where we define the 'OTGS_INSTALLER_SITE_KEY_WPML' in every site's wp-config.php. We migrate prod to dev every 24 hours (= copy all files, copy DB, perform wp-cli search-replace on dev DB).

Normally everything works fine, WPML is correctly registered on the dev site and plugin updates are possible from there. But today, when accessing the backend (frontend still works) we get a 500 internal server error. The PHP error log file contains something along the lines of:

Class 'OTGS_Installer_WP_Share_Local_Components_Setting' not found in wp-content/plugins/sitepress-multilingual-cms/vendor/otgs/installer/includes/class-wp-installer.php:1179
Stack trace:
class-wp-installer.php(551): WP_Installer->save_site_key

We are able to mitigate the server error by
a) removing the constant definition from wp-config
or
b) replacing the defined site key with the site key from prod.

The latter workaround seems to indicate that there must be some registration remnants from prod inside the migrated database on dev. Is that possible?

We solve the problem for now by using workaround a) and re-registering WPML in the dev backend whenever a WPML plugin update comes up. Obviously we would prefer the old workflow.

Can you imagine where such registration fields would still continue to hold old prod information (and be used by WPML)? We could then e. g. try deleting those fields (although it seems unlikely that this would solve the issue as it seems to have appeared spontaneously).

Best regards

April 30, 2018 at 7:36 am #1890778

Cristina

Hello Lilli,

thanks for contacting us on this.

As I understand the issue is happening since the last update to WPML 3.9.4, is that correct?

There have been issues with the new option in the registration when clients checked the new option, "Keep wpml.org up-to-date about which theme and plugins I use" . In some cases, the connection to the WPML server to validate the sitekey does not play well when this option is enabled.

Could you try to disable that option if you have checked it and see if it work without sending additional information? This may have caused the issue. We are working on that problem already.

If that does not solve the situation, I would ask the colleagues of the second level for feedback on this.

Kind regards,
Cristina

April 30, 2018 at 9:17 am #1892677

lilliR

Hello Cristina,

thanks for your quick reply. We just tested the old plugin version 3.9.3 and all site keys defined in wp-config.php work - so yes, it is definitely related to the plugin update. We are switching to 3.9.3 for now until this issue has been fixed. Thank you for guiding us in the right direction!

We did not activate the option "Keep WPML up-to-date" before the issue occurred. We just experimented with it, and activating/deactivating it does not influence if the issue occurs or not. (However activating the plugin license on the dev environment does not work (timeout) after migrating in case the option was active on the prod site during migration - but that probably is a separate issue as our dev site is protected by basic auth.)

Best regards

May 28, 2018 at 7:49 am #2236689

Cristina

Hello Lilli,

we have released a new Beta Version of WPML and this has been solved there.

I would like to invite you to test the release of the new beta version, as this problem should have been solved in that version.

I would be great if you could confirm that there is no problem in your setup with the new version.

Kind regards,
Cristina