Latest Posts block breaks in Editor ('prevOffset' error) when site is in Spanish and posts have long texts

[adrianahdez]

Description

When we go to Settings > General > Site Language and set it to English, nothing of what I'm going to mention next happens. Everything works correctly.
But, when we set the website to Spanish, the following happens:

If we insert a "Latest Posts" block on a page:

• When the website has news (Posts) with very short texts, approximately a paragraph of 47 words or less, nothing happens, it works correctly.
• But, when the website has Posts where, at least one of them, has texts of more than 47 words approximately, the block BREAKS in the Editor (from the tests I have done, it seems it doesn't care about the number of characters, what affects it is the number of words).

In that case, the following happens:
On the front end, the news always looks fine, but in the Editor, this happens:

The block remains permanently broken, without being able to change any of its options, and regardless of what I do:

• It doesn't matter if I delete that "Latest post" and insert a new one (all without caches and in incognito mode).
• It doesn't matter if the news text is copied and pasted or written.
• It doesn't matter if the text is in Spanish or is 'lorem ipsum' text.
• It doesn't matter if it has only one or multiple paragraph blocks (again, what it seems to matters is the number of words).
• It doesn't matter if there are empty blocks between paragraphs or not.
• It doesn't matter if the Post text ends with a space, a letter, or a period.

That is, the problem is not in the text I have used; it would happen with any text as long as the site language is Spanish (I don't know if it happens with another language).

When the site is in English, everything works fine.

So, it seems to be related to something odd in the WordPress translations of the Spanish language.

Step-by-step reproduction instructions

• Go to Settings > General > Site Language and select Spanish.
• Create a Post with a long text in its content (more than 47 words approximately)
• Go to edit any Page with Gutenberg Editor and insert the "Latest Posts" block.
• Open javascript console in Editor and see the error:
  TypeError: Cannot read properties of undefined (reading 'prevOffset')
  at u (element.min.js?ver=c…0aebbec25b27:2:3022)
  at f (element.min.js?ver=c…0aebbec25b27:2:3683)
  at block-library.min.js…7eb5bf914:14:208280

Screenshots, screen recording, code snippet

In Firefox show a different error when I reproduce the same steps:

Environment info

Tested with:

• Wordpress: 6.5 and 6.5.2
• Classic theme: Custom development, with 0 plugins installed.
• FSE themes: Clean Wordpress with only Twenty Twenty Four, Twenty Twenty Three and Twenty Twenty Two themes and no plugins.
• MacOS Sonoma 14.4.1
• Tested in Chrome, Firefox, Edge and Safari

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[talldan]

I had a look for where in the block this might happen, and it seems like here might be a candidate:

gutenberg/packages/block-library/src/latest-posts/edit.js

Lines 485 to 509 in 727f350

	{ createInterpolateElement(
	sprintf(
	/* translators: 1: Hidden accessibility text: Post title */
	__(
	'… <a>Read more<span>: %1$s</span></a>'
	),
	titleTrimmed || __( '(no title)' )
	),
	{
	a: (
	// eslint-disable-next-line jsx-a11y/anchor-has-content
	<a
	className="wp-block-latest-posts__read-more"
	href={ post.link }
	rel="noopener noreferrer"
	onClick={
	showRedirectionPreventedNotice
	}
	/>
	),
	span: (
	<span className="screen-reader-text" />
	),
	}
	) }

createInterpolateElement internally uses a variable called prevOffset.

It seems curious that the error happens in relation to the word count in the content, as that code mainly uses the post title
(titleTrimmed) values.

It might be related to the internationalized text there - __( '(no title)' ), which would lead me to think it could happen when a post title is empty.

[adrianahdez]

I've also noticed another issue in this block.
In the Editor, there are some classes that are in the wrong place. For example, the class for the Post title (.wp-block-latest-posts__post-title) is on the feature image HTML element, and the post title element doesn't have the class. That's why the styles I've defined for that block look wrong in the Editor.

UPDATE: I've created an issue here for this.

[t-hamano]

It seems that this problem cannot be reproduced with the latest Gutenberg.

The video below shows that the issue can be reproduced in WP6.5, but not in Gutenberg version 18.1.0.

922658047719a1a65be2c25e71d207fb.mp4

[adrianahdez]

@t-hamano I installed the Gutenberg plugin and it worked.
Thanks!!

[skorasaurus]

thanks; closing since this issue is fixed within the Gutenberg plugin; the changes from the gutenberg plugin will be integrated into a newer core version into WordPress in the future (~3-6 months).

[Mamaduka]

It might be worth identifying the PR that fixed the bug in Gutenberg and labeling it for backporting into a minor release.

[t-hamano]

After looking into it a little more, this problem is a bit strange. This problem does occur in WP6.5.2, but it does not reproduce when I enable the Gutenberg plugin version 17.7, which should be bundled with WP6.5.

Therefore, I would like to reopen this issue until we know the root cause.

[talldan]

@t-hamano There's also the wp/6.5 branch that might be worth testing on, as that will more accurately reflect what was released in WP6.5.2.

If it doesn't happen on that branch then I guess there might be a few reasons why it only happens in core. There's a chance that some dependencies are at the wrong version in core. I'm sure I recall in issue in the past (not recently) where React was at the wrong version in WordPress core.

[t-hamano]

Maybe I found the cause. The outcome of this problem depends on whether the text … <a>Read more<span>: %1$s</span></a> is translated correctly or not.

In the Gutenberg plugin, the span tag is correctly maintained and translated as shown below.

https://translate.wordpress.org/projects/wp-plugins/gutenberg/stable/es/default/?filters%5Bterm%5D=%E2%80%A6+%3Ca%3ERead+more%3Cspan%3E%3A+%251%24s%3C%2Fspan%3E%3C%2Fa%3E&filters%5Bcase_sensitive%5D=yes&filters%5Bterm_scope%5D=scope_originals&filters%5Bstatus%5D=current_or_waiting_or_fuzzy_or_untranslated&filters%5Buser_login%5D=&filter=Apply+Filters&sort%5Bby%5D=priority&sort%5Bhow%5D=desc

But in WordPress core, the opening span tag is incorrect.

https://translate.wordpress.org/projects/wp/dev/es/default/?filters%5Bterm%5D=%E2%80%A6+%3Ca%3ERead+more%3Cspan%3E%3A+%251%24s%3C%2Fspan%3E%3C%2Fa%3E&filters%5Bcase_sensitive%5D=yes&filters%5Bterm_scope%5D=scope_originals&filters%5Bstatus%5D=current_or_waiting_or_fuzzy_or_untranslated&filters%5Buser_login%5D=&filter=Apply+Filters&sort%5Bby%5D=priority&sort%5Bhow%5D=desc

I think this problem probably occurs when invalid HTML elements are passed to the createInterpolateElement() function, not just in a specific block. For example, if you update the HTML element contained in the text where this function is used to an invalid one, you can see a similar error.

The video below shows that when a string containing invalid HTML elements is passed to the createInterpolateElement() function in the Site Logo block, a similar error is output and the block is broken.

b41afac648b76dcdfed70316c0f63693.mp4

This problem could be fixed by fixing the Spanish translation, but should we add some kind of safeguard to this function itself?

[Mamaduka]

A fantastic detective work, @t-hamano 🕵️‍♂️

This problem could be fixed by fixing the Spanish translation, but should we add some kind of safeguard to this function itself?

Agreed, the Spanish translation team needs to fix this. I'll share this in the #core-i18n channel for visibility.

[talldan]

Well done tracking this down ❤️

This problem could be fixed by fixing the Spanish translation, but should we add some kind of safeguard to this function itself?

Better error handling would be cool. Perhaps test case could be added for incorrect tags that checks the function throws a nice error message.

[NekoJonez]

I think if you share this in #polyglots, the actual GTE's can fix things like this faster ;)

[Mamaduka]

@NekoJonez, the issue was fixed and update Spanish translation should already be available.

[t-hamano]

I submitted #60843 for improving the createInterpolateElement() function itself.