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.

Our next available supporter will start replying to tickets in about 1.29 hours from now. Thank you for your understanding.

Tagged: 

This topic contains 1 reply, has 2 voices.

Last updated by Jamal 1 month, 1 week ago.

Assigned support staff: Jamal.

Author Posts
September 8, 2019 at 7:57 pm #4532459

heidiS-4

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.

HLK logged this ticket for Marriott on their own here: https://wpml.org/forums/topic/block-attributes-converting-unicode-in-translated-pages-database/

September 9, 2019 at 4:08 pm #4538841

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

Hello,

Thank you for contacting WPML Support. I will be glad to help with this.

Would you be willing to reproduce this issue in one of our test servers and I'll be glad to approach our developers for further analysis and hopefully a fix. Here a One-click link to login to the test server.
hidden link

It is also worth to mention that we can use "allow_html_tags " in custom XML configuration. But I am not sure if it will apply for Gutenberg blocks.

Looking forward to your reply.

Best regards,
Jamal
WPML Support

The topic ‘[Closed] Custom wpml-config xml Conversion from unicode to actual HTML markup’ is closed to new replies.