I am not having much luck with this. I tried to do your trick and deactivate/reactivate the plugins again to see if it "resets" anything. But I am not getting the same result as well. Can you walk me through step by step on how you fix the issue?
I did not really resolve the issue, because I did not reactivate the 3rd party plugins to check. But, right after updating the plugins, pages were loading, after a long time, except for one language. The language switcher was working, but I could not test for the PDF viewer. And the common issue that I have seen is the Weglot API Error. hidden link
Maybe, that's a Toolset/Weglot compatibility. In order to be sure, we need to check in a clean installation with minimal data. We also need to know how Weglot works and what does generate the "Weglot error API" message.
I believe that Weglot support help about this issue can help us all find out the root cause and fix it. Can you reach to them and ask for assistance to understand what generates that error?
Would it be possible for you to check on this clean WordPress site hidden link
You will have to create a couple of languages, a post and translate it and see if it will break the content template design.
Can you also check without the content template? I mean unassign the content template for the post and check for differences between the original post and the translations?
This is what Weglot says "Regarding Toolset's message, the "Weglot error API" message should appear with another message. A more precise one. Usually, this message appears when there is a parsing error due to issues in the HTML file."
I have added a new page and a few languages. No issue so far. I only have issues when I upgrade the toolset Plugin. Can you test it by upgrading the plugins?
Frankly, I hoped for more information from the Weglot support than it is "Usually, this message appears when there is a parsing error due to issues in the HTML file." I hoped to know, at least, how the plugin works. If it has to always make calls to the Weglot website. And in case of HTML parsing error, I would expect the Weglot support to give us the HTML that was sent and that encountered the parsing error.
I also updated Toolset plugins to the latest releases that were published last week. I switched the theme to 2020 and disabled all plugins except the following ones:
- PDF Embedder Premium
- Toolset Access
- Toolset Blocks
- Toolset Types
- Weglot Translate
But, it did not help fix the erroneous pages/translations(Language switcher and PDF viewer dimensions).
Please reach again to the Weglot support and ask them to explain to us the following:
- Where are translations saved? If they are saved in the database, they should let us know where, so we can compare the translation and the original posts. If the translations are each time queried from Weglot servers, they should let us know what was the response for a translation and we will compare the original and translation posts.
Otherwise, I am afraid, we'll be still hitting a wall. And I can't escalate this issue to our 2nd Tier without gathering all the necessary information for the debugging.
I hope this makes sense to you. Let me know if you have any questions or if the Weglot support needs something from us.
Thank you. I'll be looking forward to any additional information that can help us figure this issue out and fix it.
I added a registration key to the test site and run the update, I don't see any issues with the translations.
Would you like to try using a content template. I mean, a content template that is somehow similar to your content template and we'll see how these pages' translations will be displayed using that content template.
This is their response. I hope you may find it helpful.
------------
I'm really here to help Tootlset the best I can.
So yes "Usually, this message appears when there is a parsing error due to issues in the HTML file". It means that Weglot's parsing follows HTML good practices.
A parsing error can happen from thousands of different issues, like several class="" in the same HTML tag or if some nodes are not closed fine for instance.
Usually, we're able to detect the parsing issues thanks to an HTML validator like the tool below
> hidden link
Regarding the question:
- Where are translations saved?
There are saved in our database and are findable into the Weglot Dashboard > Translations List.
Here they will be able to find all the translations generated with the related original content.
It required to provide Toolset access to the project as a "translator".
Let me know if you want me to provide them access to this project. I will need Toolset's email address to validate their invitation.
NB: Are you able to generate back the issue on the test store?
How can I generate it back by our side so we can also try to help further?
Let me know if you need any further information.
------------
Let me know if you need access to Weglot. And let me know if you are able to update the plugin in the fresh test site. hidden link
I tried the validation tool and there is indeed an error on a Toolset Heading block used in the content template. The block pulls data from the "Sub Header" custom field, which is a multiline field and produces a <p> tag. Check this screenshot hidden link
While testing this, I realized that all the pages were resolved on your website. I still don't what was the cause of the issues with the 1.3.4 version. And I suspect something else because earlier today, I have performed the update and the issue was still there.
Please let me know if there anything else I can do to help.
You should be able to get back in hidden link, with the same credential in my first post.
Do you know why it's adding <p> inside <h2> tag? It is using the Header block from Toolset, is this something you guys need to fix or is this something I can fix on my end?
I am still experiencing the issue on this page after I update to the latest version 1.3.5, hidden link
Weglot provided me with this solution which seems to fix the problem
---
This element is findable under the CSS Selector below.
Can you try to add the code below to the Exclude Blocks elements into your WordPress admin > Weglot?
div.tb-field[data-toolset-blocks-field="63bad74314043e330e3fb0d98e08558f"]
I think the issue comes from the fact our automatic translation provider doesn't seem to manage so well the characters you will see in the video below
> hidden link
As it's only a bunch of characters for automatic translation providers, they can't manage it fine.
Excluding it from the translation seems to do the trick
----
I do need help as to why <p> is added to the Toolset Header Block. Let me know if you want to continue with this chain or start a new thread. Thank you!
Hello and sorry for the late reply, but I do not work on Wednesdays and Thursdays.
Awesome, Weglot support found what's breaking the translations. The bunch of characters added to the page are Toolset blocks styles encoded as base-64 string. Excluding the CSS selector "div.tb-field[data-toolset-blocks-field="63bad74314043e330e3fb0d98e08558f" will fix the issue for this page. But if you want to exclude all Toolset base-64 encoded strings, I'll suggest excluding "div.tces-js-style-encoded"
Regarding the <p> tag inside the heading tag, you can fix it either by:
- Converting the field from a "multiple lines" field into a "single line" field.
- Or by using the "Single Field" block instead of a Heading block. But you will lose the <h2> tag.
- Or by using a "Fields&Text" block and Toolset legacy shortcodes. Check this screenshot hidden link
Because the field is a "Multiple lines" field, it will always contain <p> tags, unless used with a shortcode and the output="raw" attribute. Check this test page hidden link
You can login to this test site using this URL hidden link
I am glad we get this far and found out the original issue. Let me know if you have any questions.
