[Resolved] wp-config php modification won't solve multikey issue in Kinsta
This thread is resolved. Here is a description of the problem and solution.
Problem: The client is using Kinsta hosting for their WordPress site and is trying to manage WPML site keys between a staging and live environment. They are concerned that the wp-config.php file, which contains the WPML site key, gets overwritten when pushing changes from staging to live, making the automatic registration method suggested by WPML impractical for their workflow.
Solution: 1. We recommend merging the staging and live sites to share the same translation memory, glossary, and automatic translation credits. This can be done by following the instructions here: Automatic Translation Subscription for Multiple Sites.
2. Register each domain on wpml.org and ensure each has its unique site key.
3. We advise against using a programmatic conditional approach to manage site keys as it could cause issues.
4. Defining the site key in the wp-config.php file for each environment is recommended, but this is only effective if using the OTGS Installer Plugin. More information can be found here: Automatic WPML Registration Using PHP.
5. If the wp-config.php file is overwritten during migration, and it's not possible to exclude the file from the migration process, the client should manually ensure that the correct site key is used after migration by checking under Plugins > Add new > Commercial.
Please note that this solution might be irrelevant if it's outdated or not applicable to your case. If these steps do not resolve your issue, we highly recommend checking related known issues at WPML Known Issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If you still need assistance, please open a new support ticket with us here.
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.
Hopefully, someone over there is familiar with Kinsta's wordpress hosting and how their staging and live hosting environments work.
Whenever I want to make changes/updates to my site I copy the LIVE version to a staging site (which always has the same url - hidden link).
Once I'm satisfied with my changes, I push them back to the LIVE environment.
Seeing as I'm new to WPML, I'm implementing it on my staging site before pushing it LIVE.
You will notice I have installed the plugin and created a site key for both environments.
Now, here's the rub: Your instructions say: "If you frequently move your site between staging and production, you can also set your site up for automatic WPML registration using PHP."
However, Kinsta Support informs me:
"After looking into this further, I unfortunately don't see a way to accomplish this. It doesn't seem like WPML automatically is able to determine when it's on a staging environment, and when it is not. So, when pushing staging to live the keys would be overwritten because the wp-config.php file will be overwritten.
I would recommend reaching out to WPML's support to see if there is somehow any way however they're aware of. Or, if there is any way to configure one key to be used for both the live and staging environments."
So, with the understanding that the wp-config.php modification isn't a viable solution to managing different keys for the staging and live environments, what are my best remaining options?
If there are no better options available (for managing site keys in both environments), could I get away with handling all translations in the LIVE environment?
And if I did that, would the plugin automatically detect updates made to my content and trigger automatic translations (assuming I've set it to translate content automatically)?
Matter of fact, this was the entire basis for my question and issue.
While this document states: "The value that you set using the OTGS_INSTALLER_SITE_KEY_WPML takes precedence over the value in the database. So, when you move the database between domains, you will not need to update the registration."
This fails to take into account that we often/usually push everything (not just the database) when pushing updates from our STAGING site to our LIVE one. Seeing as we like to run all plugin updates on our LIVE site, we also frequently push our LIVE site to our STAGING as well.
KINSTA support informs me that doing so overwrites everything, including the wp-config.php file, which means this work-around is not a viable solution for us.
So, with that updated understanding, please help me understand my remaining options to have the best possible experience with WPML given these constraints.
Again, If there are no better options available (for managing site keys in both environments), could I get away with handling all translations in the LIVE environment?
And if I did that, would the plugin automatically detect updates made to my content and trigger automatic translations (assuming I've set it to translate content automatically) when I push updates from STAGING to LIVE?
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
If the sites are merged, then they will share the same translation memory, which means that if you complete a translation on staging and then open the same content on production, then WPML should automatically complete untranslated content.
If the wp-config.php file gets overwritten when pushing between staging and production, then there is sadly nothing we can do from our end, unless you have a way to exclude the file inside your migration process on Kinsta.
If not, then I would suggest always making sure that the site uses the correct site key at Plugins > Add new > Commercial after you have migrated the site. (each domain has its key).
