Skip Navigation

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 topic contains 23 replies, has 2 voices.

Last updated by billL-7 1 year, 7 months ago.

Assigned support staff: Shekhar Bhandari.

Author Posts
September 5, 2019 at 10:12 pm #4522069

billL-7

We've set up a custom wpml-config.xml file for translating custom gutenberg-blocks. We have content showing properly in the advanced translation editor, but any attributes that have HTML inside are being converted from unicode in the original database value to the actual HTML markup. This causes the core WordPress function that parses attributes for use in PHP to fail and return nothing.

For example, the English (default) version of one of our attributes gets stored into the block HTML comment as

"pacsysCarouselContentBody": " br\u003eMAKE HEADCOUNT COUNT\u003cbr\u003e\u003cbr\u003eHiring just to hire is a good way to crash your business. So, how do you know how many employees you need to start?"

After requesting a translation using the Advanced Translation editor what gets stored in the database is:

"pacsysCarouselContentBody":"<br>MAKE HEADCOUNT COUNT<br><br>Hiring just to hire is a good way to crash your business. So, how do you know how many employees you need to start?"

What then happens is the English (default) version of the page loads fine, but WordPress fails to parse the attributes for any block that has HTML in the database which causes the block to fail rendering properly as no $attributes are passed to our render_callbackfunction.

The particular line of core where it fails is wp-includes/class-wp-block-parser.php line 444 which is:

$attrs = $has_attrs ? json_decode( $matches['attrs'][0], /* as-associative */ true ) : $this->empty_attrs;

The translated version of the page sets $attrs as nullbecause the json_decode() function fails to parse the HTML included in the database.

So our render callback function gets no $attributes to work with to fully render our dynamic block through PHP.

My expectation is that the unicode characters would not be converted when the translation is sent back to WordPress to create the post.

September 6, 2019 at 7:50 am #4523749

Shekhar Bhandari
Supporter

Languages: English (English )

Timezone: Asia/Kathmandu (GMT+05:45)

Hello there,

Welcome to WPML support. I'd be assisting you further on this issue.

Thank you for the info, to further debug this issue, I think it would be easy to add the custom block to a test site and see how it works.

I have created a test site here: hidden link You can login using the link, no need for user and pass. I request you to create a similar test setup on this test site so we can debug it further. Since this is a test site I request you to use only test data.

Let me know once it's done.

Thanks

September 9, 2019 at 5:19 pm #4539285

billL-7

Hi Shekhar,

Thank you for setting up the sandbox environment. I have uploaded our plugin, which enables custom Gutenberg blocks. I've set up the basic translation admin and management. Unfortunately I am getting an error when I attempt to activate the advanced translation editor. The bug we are experiencing is specifically related to that editor, not the basic editor available in the sandbox environment. Attached is the error that I receive in the WPML settings page. It appears to be an issue with the sandbox demo user missing an email. I attempted to add an email to that account, but with no luck. Can you advise on the best way to resolve this roadblock?

Screen Shot 2019-09-09 at 12.12.08 PM.png
September 10, 2019 at 12:31 am #4540593

Shekhar Bhandari
Supporter

Languages: English (English )

Timezone: Asia/Kathmandu (GMT+05:45)

Hello there,

I have added the email using database for the demo user so Advanced translation editor should work fine, can you now try to replicate the issue?

Look forward to your reply.

Thanks

September 10, 2019 at 2:16 pm #4546325

billL-7

That did get the Advanced Translation editor working. I created a test page here hidden link with a component. The encoded markup in the pacsysArticleCopy is being displayed since it becomes unencoded.

The correct markup passes the content of pacsysArticleCopy to our render callback function as an attribute. The incorrect markup after the HTML has been encoded in the translated page doesn't return any attributes to the render callback. As you can see the HTML comment for the block is even showing as the markup inside is rendered by the browser.

If you take a look at the database you should see the English version of the page has the markup in the pacsysArticleCopy attribute as unicode, where the translated version will show the actual characters for the markup.

CleanShot 2019-09-10 at 09.13.49@2x.png
CleanShot 2019-09-05 at 17.05.57.png
September 11, 2019 at 2:16 am #4549649

Shekhar Bhandari
Supporter

Languages: English (English )

Timezone: Asia/Kathmandu (GMT+05:45)

Hello there,

I am discussing this issue with our 2nd tier supporters and will respond to you soon.

Thanks

September 12, 2019 at 12:27 am #4556859

Shekhar Bhandari
Supporter

Languages: English (English )

Timezone: Asia/Kathmandu (GMT+05:45)

Hello there,

I discussed the issue with our 2nd tier supporters and it looks like the wpml-config file is not properly loaded from the plugin folder, so to fix the issue please follow the below steps:

1) Copy the following code in WPML->Settings -> Custom XML configuration

<wpml-config>
    <gutenberg-blocks>
        <gutenberg-block type="pacsys/pacsys-article" translate="1">
        <key name="pacsysArticle">
            <key name="pacsysArticleItem">
                <key name="*">
                    <key name="pacsysArticleEyebrow"></key>
                    <key name="pacsysArticleMainHeading"></key>
                    <key name="pacsysArticleSubheading"></key>
                    <key name="pacsysArticleCopy"></key>
                    <key name="pacsysArticleMedia">
                        <key name="pacsysCarouselMedia">
                            <key name="pacsysImageCaption"></key>
                            <key name="pacsysCarouselImage">
                                <key name="mediaBackgroundImage">
                                    <key name="alt"></key>
                                </key>
                            </key>
                            <key name="pacsysCarouselVideo"></key>
                        </key>
                    </key>
                </key>
            </key>
        </key>
        </gutenberg-block>
    </gutenberg-blocks>
</wpml-config>

2) Once you place the code there, go to WPML->Settings -> Multilingual content setup and refresh the page.

To find out more, https://wpml.org/documentation/support/language-configuration-files/

3) Now go an translate the page, it will work properly, we tested this on the staging site and it's working properly. hidden link

Let me know if this helps.

Thanks

September 12, 2019 at 5:08 am #4558373

billL-7

I can test that out, but the wpml-config.xml file will need to be loaded from the plugin folder.

Can you provide more information on what is causing the issue with the wpml-config.xml loading from the plugin folder?

September 12, 2019 at 5:58 am #4558535

Shekhar Bhandari
Supporter

Languages: English (English )

Timezone: Asia/Kathmandu (GMT+05:45)

Hello there,

What our 2nd tier supporter mentioned is that "WPML cache wpml-config.xml files agressively, so WPML doesn't read those files on every request because of the performance impact."

So we suspect that changes made in the XML file haven't been recognized by WPML yet. Being so, we ask you to test the another way around.

If you wish you can also, disable the plugins that includes the wpml-config.xml file to see if that helps.

Let me know if this help.

Thanks

September 12, 2019 at 6:28 am #4558611

billL-7

Both of these pages I created still broke with translations with the WPML config added directly to the Custom XML configuration.

hidden link

hidden link
hidden link

The second one even behaves differently between the fr and gl translation.

It doesn't seem to be tied to long content.

I copied and pasted the content for those posts from the content for the site where this bug was discovered.

September 12, 2019 at 6:31 am #4558615

billL-7

Here's one more example using just the first two lines from the Zurich post that broke. It also breaks on the translation.

hidden link
hidden link

I'm not able to access the database of this site, but I'm curious to see what's being output for each post there.

September 12, 2019 at 3:31 pm #4562425

billL-7

A few more updates. The error we're getting appears to be tied to links. In particular when it's getting encoded back to markup it's adding in the quote character " which breaks the JSON.

For example here's an english post stored in the database with a link.

<!-- wp:pacsys/pacsys-article {"pacsysArticle":{"pacsysArticleItem":[{"pacsysArticleMedia":{"pacsysCarouselMedia":{"mediaType":"none"}},"pacsysArticleMainHeading":"","pacsysArticleSubheading":"","pacsysArticleCopy":"\u003ca href=\<em><u>hidden link</u></em>\u0022\u003eLink\u003c/a\u003e."}]}} /-->

And the translated French verions I'm getting:

<!-- wp:pacsys/pacsys-article {"pacsysArticle":{"pacsysArticleItem":[{"pacsysArticleMedia":{"pacsysCarouselMedia":{"mediaType":"none"}},"pacsysArticleMainHeading":"","pacsysArticleSubheading":"","pacsysArticleCopy":"<a href="<em><u>hidden link</u></em>">Link</a>. Le"}]}} /-->

This section is what's causing the JSON parsing error:

"pacsysArticleCopy":"<a href="<em><u>hidden link</u></em>">Link</a>. Le"

I'm trying to understand where that encoding is happening. I know our WPML Config has been loaded from the plugin as before including it we wouldn't get any of our attributes to show up in the advanced translation editor. Without the wpml-config.xml in the plugin all we would get is the Title for translation.

The posts I shared in comments above broke on the sandbox environment. But the post with a single link worked on the sandbox environment. So we're getting inconsistent results. hidden link

September 12, 2019 at 3:49 pm #4562635

billL-7

I was able to use the theme editor to get a look into what the actual HTML comment output on the working hidden link page is.

It appears to be escaping the link characters.

<!-- wp:pacsys/pacsys-article {"pacsysArticle":{"pacsysArticleItem":[{"pacsysArticleMedia":{"pacsysCarouselMedia":{"mediaType":"none"}},"pacsysArticleMainHeading":"","pacsysArticleSubheading":"","pacsysArticleCopy":"<a href=\"https:\/\/google.com\">Link<\/a>. Le"}]}} -->

Not sure why my local is behaving differently for the same content. I also had the same issue on a WP Engine site.

Even on the sandbox environment this page hidden link is still breaking on translation and it's HTML comment looks like:

<!-- wp:pacsys/pacsys-article {"pacsysArticle":{"pacsysArticleItem":[{"pacsysArticleCopy":"DEMOCRATIC DNA<br><br>To be sure, congestion is a problem plaguing cities and commuters the world over. Every year U.S. drivers waste $1,200 in fuel and precious time sitting in traffic, according to a <a rel="\"noreferrer noopener noreferrer" noopener\" href=\"https:\/\/www.usnews.com\/news\/us\/articles\/2017-02-20\/traffic-jams-cost-us-drivers-1-200-a-year-study\" target=\"_blank\">recent study<\/a>. It's a problem everyone wants to solve, driving car and tech companies to throw millions at everything from navigation to ride-sharing to driverless cars."}]}} -->

The forum is encoding characters so I'm attaching a screenshot of what I'm actually seeing to go along with the code block: see screenshot-1.png.

So in particular the rel on the link isn't getting encoded properly at this point:

<a rel="\"noreferrer noopener noreferrer" noopener\" href=\"https:\/\/www.usnews.com\/news\/us\/articles\/2017-02-20\/traffic-jams-cost-us-drivers-1-200-a-year-study\" target=\"_blank\">recent study<\/a>

Screenshot-2.png shows the working english version of the page that is passed to WPML

screenshot-2.png
screenshot-1.png
September 12, 2019 at 5:16 pm #4563627

billL-7

I'm getting it to consistently break when entering links that open in a new window into the content.

They seem to break where they attempt to encode the rel attribute.

rel="\"noreferrer noopener noreferrer" noopener\"

Screenshot included comparing english and translated version.

The HTML view in the Advanced Translation Editor also appears correct when finishing the translation. But once we view the data stored in the HTML comment in the database it has become corrupted.

To view the HTML comment I added a line of code to page.php through the Theme > Editor screen.

echo '<pre>'; echo print_r($post); echo '</pre>';

That's where the pre element outputting the post object is coming from on the frontend. You can inspect the pre element to see the HTML comment inside post_content.

rel-data.png
September 12, 2019 at 7:06 pm #4564115

billL-7

I've run into another similar encoding issues on another block field. Using quotes around text in the headings causes and error as well as seen on this page. hidden link

<!-- wp:pacsys/pacsys-article {"pacsysArticle":{"pacsysArticleItem":[{"pacsysArticleMainHeading":""Commodo Excepteur"","pacsysArticleSubheading":""Exercitation Exercitation""}]}} -->

As you can see the strings coming back from the translation service don't have the quotes escaped so it breaks at the json_decode() portion of parsing attributes in WP core.

The original post has the attribute stored in the DB as:

<!-- wp:pacsys/pacsys-article {"pacsysArticle":{"pacsysArticleItem":[{"pacsysArticleMainHeading":"\u0022Commodo Excepteur\u0022","pacsysArticleSubheading":"\u0022Exercitation Exercitation\u0022"}]}} /-->