Problem: You are experiencing issues with category display in the backend of a multilingual site using WPML. Categories are not displayed in the expected language; instead, they appear in the language of the last updated post. Solution: We recommend the following steps to resolve the issue: 1. Navigate to WPML > Support > Troubleshooting. 2. Click on the following buttons: - Synchronize posts taxonomies (Select pages/posts from the dropdown before clicking the button) - Clear the cache in WPML - Remove ghost entries from the translation tables - Assign translation status to duplicated content - Set language information - Fix post-type assignment for translations 3. Go to Settings > Permalinks. 4. Set the Permalink structure to "Postname" and save the changes. 5. Clear the caches from your site and browser, then check again.
If the issue persists or the solution seems irrelevant due to being outdated or not applicable to your case, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If further assistance is needed, please open a new support ticket at WPML support forum.
Problem: The client is inquiring if the latest version of WPML is compatible with PHP 8.X, as their site on Wordpress.com is updating to PHP 8.1. Solution: We have confirmed that the latest version of WPML should operate without issues on PHP 8.X. However, there are known situations where deprecated errors might appear with PHP 8.2. These errors can be hidden and do not impact the functionality of WPML. For more details on this specific issue, you can refer to our errata page: PHP 8.2 Deprecated: Creation of dynamic property WHIP_RequirementsCheckerConfiguration is deprecated.
If this solution does not resolve your issue, or if it seems outdated or irrelevant to your specific case, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. Additionally, you can open a new support ticket for further assistance at WPML support forum.
Problem: The client wants to export content from WordPress that has been translated using WPML, regardless of whether the WPML Translation Editor or the WordPress Editor was used. The client wishes to back up this content externally, such as in a Google Doc or a spreadsheet. Solution: We recommend using the standard WordPress export functionality found under Tools → Export. This feature works irrespective of the translation method used. For a more flexible exporting tool, the client can use the WP All Export plugin. Detailed documentation on how to export multilingual websites using WP All Export and WPML can be found here:
Please note that the solution provided might be outdated or not applicable to your specific case. If the solution does not resolve your issue, we highly recommend checking the related 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 do not hesitate to open a new support ticket. You can reach our support forum here: WPML support forum.
Problem: The client installed WPML on their production site and after deleting the WPML plugins, they noticed that the tables were still present in the database. They were concerned that these should have been deleted.
Solution: We explained that simply disabling and removing WPML does not automatically remove the data from the database. To clean up the database, we recommended following the steps in our documentation for doing a WPML reset on the site, which can be found here: Deleting languages and plugin data by doing a WPML reset on your site.
We also acknowledged the client's note about the Google search result and informed them that we would investigate the issue on our end.
Please note that the solution provided might be irrelevant if it's outdated or not applicable to your case. If the steps above do not resolve your issue, we highly recommend checking the related 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.
Problem: 1. The client wants to remove certain ACF field labels from translation segments, specifically checkboxes for custom features like 'super-sticky' posts and hiding featured images, while keeping the ability to translate other ACF fields in the future. 2. The client wishes to either display the 'Translation Priority' select only in the default language or disable it entirely, as all posts require translation.
Solution: 1. To prevent ACF field labels from appearing in translation jobs, add the following code to your
2. Regarding the 'Translation Priority' field, it should only display options for the language you are currently working on. If you are seeing it in all languages, check the translation preference settings under "WPML > Settings". To delete the translated options for 'Translation Priority', follow the guide on Adding priority to your translations.
Please note that the solution provided might be outdated or not applicable to your case. If the issue persists, we recommend checking the related known issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If necessary, do not hesitate to open a new support ticket with us.
Problem: 1. The client wants to know the cost of bulk automatic translation before proceeding. 2. The client wishes to set all automatic translations to a "review" state for human translators to verify. Solution: 1. To estimate the cost of bulk automatic translation, we recommend checking out these two resources:
Please note that the solution provided might be outdated or not applicable to your case. If so, we encourage you to open a new support ticket. We also highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If you need further assistance, please visit our support forum.
Problem: The client is unable to view the correct permalink structure for their translated post on the front-end. Instead of seeing a 'pretty permalink' like
http://gxblog.local/pt-br/post-11-en
, they are seeing the default WordPress permalink structure, such as
http://gxblog.local/?p=179
.
Solution: 1. Ensure that the server supports mod_rewrite, which is necessary for using 'Pretty Permalinks'. 2. In the WordPress backend, open the affected post and switch to the secondary language using the top-bar language switcher. Verify that the page is not saved as a draft. If it is, publish the post so that the correct permalink can be generated.
If this solution does not apply to your situation, or if it seems outdated, we recommend opening a new support ticket. We also highly recommend checking related known issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. For further assistance, please visit our support forum.
Problem: The client is trying to maintain the default language slug for every translated post. The original language is English, but when translating to Spanish, the slug is automatically translated, resulting in a different slug than the English version. Additionally, the client encounters a 404 error when viewing the Spanish post because the URL does not include the '/es/' language code. After updating the post, the correct URL with '/es/' is generated, but the slug is still in Spanish.
Solution: We recommend using the WPML Translation Editor instead of the WordPress Editor for translating posts. This is because when using the WordPress Editor, the post slug is generated from the post title, which is a standard WordPress feature. By switching to the WPML Translation Editor and re-translating the post, the slug should remain the same as the original language.
If this solution does not seem relevant to your situation, please open a new support ticket with us.
Problem: The client is concerned about maintaining their current URLs with the language code /es_ES/ when switching to WPML, which uses the language code /es/ by default. They want to avoid 404 errors and are considering whether to redirect all /es_ES/ URLs to /es/ or to create new languages with the old site's language codes.
Solution: We recommend two options: 1. If you decide to use the predefined language code /es/, you should set up redirects from /es_ES/ to /es/. This cannot be done through the WPML GUI, so you would need to use custom functions, such as adding rules to the .htaccess file or using a redirection plugin.
2. If you prefer to keep using /es_ES/, you can create a custom language in WPML. First, change the default locale for the predefined /es/ language to something else (e.g., es_ESS), and then you can use es_ES for your custom language. Remember to set the correct default locale and hreflang for your language.
For more details on editing WPML's language table and setting up language codes, please visit our documentation.
If this solution does not seem relevant to your situation, please open a new support ticket in our support forum.
