Thank you for the details. I can reproduce the issue. Unable to complete the translation of the following post. Please refer to the attached images for additional information.
hidden link
Therefore, a couple of requests to track this. Upgrade the following configurations to help improve the performance of your site. Then, clear all types of caches and make sure the bug exists.
1) Increase *WP Memory Limit* to *256*(the minimum required memory limit for WPML is *128*). Please check the following links for more details
2) Increase the *MaxInputVars* of PHP settings to *10000*. Please check the following article for more details, or contact your system admin/hosting provider for this purpose.
hidden link
Please note that there are limitations when it comes to translating Posts (Articles) and Pages using WPML String Translation. For these content types, we need to use the WPML Advanced Translation Editor, Classic Translation Editor, or perform a manual translation via the WordPress editor. For more details, please refer to the following documentation.
Hello Bigul,
These settings are not the issue.
Indeed, you have access to staging, which is limited.
My original site has the settings you mention (see image), and it does not change, status is identical.
I am even more sure that it's not an issue of memory or calculations, that I duplicated this post, cut it in 4 different pieces, and it does change anything as well. For any of the 4 sections.
For your info, one of the elements that you tried to translate was formerly translated with WPML strings. And the other one is an addition, few days ago. Knowing that I had not enriched this post since probably ... last year.
For your info, I had a case open on this, say 1 year ago, the supporter spent his tme shooeting the ball in other fields (plugin, memory, etc.). Fact is that if editor was not working, string translation was. And using much less memory / CPU than the editor.
My interpretation: all what was translated via WPML strings is not translate-able nor modifiable by the editor. I just discovered that it's in another Database. So, there is a logic. For me, this way of doing is a kind of non-sense, all should be related to the original item (wheter plugin, post, product, ...) ... but not to which "tool" was used to translate.
Then, it also looks like any post, page, product .... which has been partly using WPML strings in the past, can't be changed anymore. From a customer point of view, it's a damage.
Waiting for your feedback and with my kindest regards
Alina
Thank you for the details. I hope your live site is also hosted on Cloudways.
This may be a compatibility conflict. I will continue testing this further. Just to confirm, were these tests performed on the same staging site or the live site? If so, please share the post URLs.
I am even more sure that it's not an issue of memory or calculations, that I duplicated this post, cut it in 4 different pieces, and it does change anything as well. For any of the 4 sections.
Also, have you tried using WPML's Advanced Translation Editor? It is much easier to manage and offers several helpful features, such as Translation Memory, which can save time by automatically reusing previously translated content.
Additionally, as per the Debug Information, the max_input_vars value on your live site appears to be set to 2500. You can verify this by visiting WPML >> Support >> PHP Info.
Therefore, could you please recheck and confirm? Because when translating long posts or working with WooCommerce products, it is highly recommended to set max_input_vars to at least 10000. This ensures that all fields are processed correctly during translation.
Hello Bigul,
You were most certainly right, if the settings on my Cloudways interface seemed right for my site, they were probably not implemented ... thank you for noticing it. I questioned the Cloudways team, and now, it's rectified and apprearing on WP/Tools/Information, it's image max input vars.
Following this change, I tried again to translate the post.
What is the result?
- as far as I can see, I can translate all fields / paragraphs.
- when I save, the saving can't be completed, the hour glass remains for hours ...
- when I later look at wp/articles, the given article is declared as 'under way", that's your clock wheel (see image uncompleted)
- surprisingly, when I open the translation (EN), it's declared as 100% completed (that's image though-completed)
- when I look at article in EN, well, whatever declared as translated or not, and anyway though 100% translated in WPML editor, the post remains at it was before (see faisan / pheasant, translated in WPML editor but invisible in EN post). Or see coeur saignant / bleeding heart flower, which remains in former string version.
For you to see with your eyes, I upaded the staging, to make it match with the current version of my site ... but php settings
So, all considered, I remain on my former belief: a "thing" (post, product, page) can't be modified if it were in the past partly translated via WPML strings.
Waiting for your feedback and wishing you plenty of good things
Alina
Thank you for the feedback. I checked WPML >> Translation Management >> Translation Jobs, and the affected posts' translations are showing as "Completed" or "Completed – Needs update". Please refer to the attached images for more details.
Therefore, one request. Please try the following steps, preferably with the assistance of your hosting support:
1) Increase *WP Memory Limit* to *256*(the minimum required memory limit for WPML is *128*). Please check the following links for more details
Then, try the following and make sure the bug exists or not:
- Open one of the problematic posts for editing in the original language.
- Make a minor content change (e.g., add a special character or word).
- Save the post to refresh the translation settings.
- Then update the translation and check whether the issue persists.
Hi Bigul,
Rest Api works and is not disabled via any plugin
WP memory is already at 512 (see image attached). I even tried yesterday with 700. Exceed memory limit may be a symptom, like fever, but the symptom is not the illness ... hundreds of reason to have a fever.
That's what I call: shooting the ball in another field.
To sum it, the published post 68727:
- is translated in EN
- but the translations are not appearing in post
See image: published-post-68727-translations-made-but-missing
Now, it's interesting to look at post (n° 88414) just above the published one, filtered via using word ""encyclopedie" in FR ... which is at draft stage:
see image post-list-sorted-in-fr-via-key word-encyclopedie
It was generated via using plugin Yoast duplicate post.
Though identical to original one, it's declared as fully translated. What is not normal.
If you compare 88414 (FR) preview, with it's 88415 EN translatio, you see what was visually missing in original EN post is now visible (though in FR to be translated in EN). This means that the Yoast copy is better than WPML copy.
See image copy-fr-vs-copy-en-via-yoast
Of course, after, if I try to translate this duplicated post via WPML editor, it does not save. But at least, I have a better basis if I use gutenberg since the html and shortcodes are already there: hidden link
Re WPML and the problem of memory ... it's always the same process of those undefined array key on media translatin ... and then the more or less fatal error via class-wpdb.php, as as managed by WPML
See image wp-debug-log
Knowing that it follows:
parse_str(): Input variables exceeded 2500. To increase the limit change max_input_vars in php.ini. in /home/1164702.cloudwaysapps.com/vjgpsqycrh/public_html/wp-content/plugins/sitepress-multilingual-cms/classes/editor/ClassicEditorActions.php on line 20
So, all in all, to translate a post which is easy to manage via WP/gutenberg, looks like WPML make now things super complicated and highly ressource extensive (memory + CPU) ... An issue that I never had with strings translation ... which also has translation memory
I have had a similar issue to generate product feeds for Google shopping, Bing, ... It demands many calculations (filters + conditions) on Woocommerce data bases ... The first plugign I tried demanded a lot of ressources, often bugging. Than, I found another, which is super smooth.
The easy fix is that you explain me how to get post translated via WMPL strings
Therefore, please try the workaround suggested in the ticket summary after taking a full site backup, and let us know your feedback.
If the bugs persist, kindly provide a list of the problems you are currently encountering with WPML, along with the exact steps to reproduce each one. This will help us ensure that no issues are overlooked.
Additionally, please grant permission to:
- Deactivate non-WPML plugins
- Switch to the default Twenty Twenty-Five theme on the staging site for further troubleshooting
- Create a copy of the site in case of escalation to our developers
Thank you for your kind understanding and cooperation.
Hello Bigul,
I don't understand.
You have the access to my staging site, where you can try anything.
You mention a "workaround" for a problem that is different. I don't get the point. Did you forget what is it about? If so, please read this thread from scratch.
Again the easy fix is that you explain me how to get post translated via WMPL strings.
Or should I abandon WPML and switch ?
Kind regards
Thank you for the updates. As mentioned earlier, there are several limitations when it comes to translating post or page content using WPML String Translation. An alternative is switching to the Advanced Translation Editor, but this would require re-translating most of the existing posts and pages. Therefore, we are not recommending that approach at this point.
We will continue to troubleshoot the issue in detail and get back to you as soon as possible.
I suggested trying the workaround because of the following error, which may be related, although I have not been able to reproduce it:
parse_str(): Input variables exceeded 2500. To increase the limit change max_input_vars in php.ini. in /home/1164702.cloudwaysapps.com/vjgpsqycrh/public_html/wp-content/plugins/sitepress-multilingual-cms/classes/editor/ClassicEditorActions.php on line 20
Additionally, you are now experiencing a new issue: where the post translations are not displaying on the frontend. That is why I requested a full list of the translation-related issues you are currently facing. So we can ensure nothing is overlooked during troubleshooting. Thank you for your kind understanding.
To sum it up, WPML classic editor does not work; use wordpress editor does not work as well, since the HTML is not copied, contrary to when done via Yoast duplicate post.
1.WPML strings
There is theory, and practice. There is no risk to try on staging site.
Again, WPML strings was working perfect with this post.
Could you either explain me how to get posts translated via strings .... or enable me to download a version that enables it, for trial.
To try:
1. does it enable to translate?
2. if I cancel all former entries, will it solve the issue of the editor.
2. workaround relates to a different issue.
It's concerns sticky posts, and elementor. I am using none.
3. max_input_vars is set at 10,000. You have the screenshot. Btw, I also increased the capability of Apache server
4. What about the fatal error I sent?
Waiting for ytour feedback on those 4 points
Kind regards
Alina
New threads created by Bigul and linked to this one are listed below:
Thank you for the details. I am currently checking with our team regarding this issue. We will carry out a detailed debugging process and get back to you as soon as possible.
Also, I have created new tickets for the related problems for easier follow-up. Thank you for your patience. Please stay tuned while we continue investigating.
Hi Bigul,
All in all, and factually, you refuse to answer to any of my request or question.
I hoped to deserve a minimum of respect.
Looks I don't
Till I talk with honest people?
New trial:
Q1: if a post was, in past, translated via WPML stings, how is it supposed to be updated now?
Q2. If a gutenberg block was translated via string, how is it supposed to be modified?
Q3. in which database are posts (articles) translations?
Last, I have now the proof that the problem stands in how WPML manage HTM.
Bugs, errros, high CPU / memory use are always symptoms.
Last Q4: what is your SMART commitment? Specific, Measurable, Ambitous / agressive, Realistic, Timed
Kind regards
Alina
Hi Bigul,
In addition to former message ...
There is bot a database and html issue.
I made some additional tests.
Some old translations have been "broken" by WPML changes. I found out 3 different cases:
- when paragraph was containing a link
- when paragraph had bold (ie
- and apparently also when paragraph contained quotation marks
Also, the translations that were in the past recorded and thus re-usable, are not anymore.
Could you explain?
Kind regads
New threads created by Bigul and linked to this one are listed below:
Thank you for the details, and I am truly sorry for the inconvenience you are facing with WPML right now. Let me try to answer your new questions as clearly and honestly as I can:
As mentioned earlier, posts and pages should not be translated using String Translation. In some cases, especially when using a page builder, WPML will create a translation package (WPML >> Packages), and we can translate a few of those package strings from WPML >> String Translation. But even then, it is not 100% reliable. That is one of the key reasons we introduced the WPML Translation Editors (Classic and Advanced). While some customization may make it possible, it can lead to serious performance issues and is not recommended.
Gutenberg block content should also be translated using the WPML Translation Editor, not through String Translation. If a custom block was registered as a string, you can technically update it via String Translation, but it is better and more stable to translate the whole post or page through the editor.
Regarding the database: WPML stores translated posts in the standard wp_posts table, with each translation being a separate post entry. These are linked to the original content via WPML’s internal tables, such as wp_icl_translations. You can refer to this screenshot for more clarity: hidden link
We are now troubleshooting each issue you are facing one by one with the help of our second-tier team. I am also creating a local copy of the site to escalate the matter for deeper debugging.
As a WPML support person, my goal is always to provide clear, respectful, and helpful answers. Thank you again for your cooperation and patience. We will get back to you as soon as we can. Please bear with us a little longer.
Hi Bigul,
For some reasons, I could work on my site for a while.
Now, I have time, and I discover several issues with WPML!
I just did a translation of a post .... the html ... indeed the gutenberg codes are badly transferred.
I wanted to update a product, it directly opens in wordpress editor, and shows: "Warning: You are about to edit your translation using the standard WordPress editor but your site is configured to use the WPML Translation Editor. Any edits you do here will be lost if you later open it in the WPML Translation Editor. "
I use the WPML eidtor, I can't anymore, and I get warnings !
Nightmare !
Kind regards
New threads created by Bigul and linked to this one are listed below:
