Fix/title encoding bug #19187
Fix/title encoding bug #19187
Conversation
| @@ -123,7 +123,7 @@ class PostTitle extends Component { | |||
| <Textarea | |||
| id={ `post-title-${ instanceId }` } | |||
| className="editor-post-title__input" | |||
| value={ unescape( title ) } | |||
| value={ decodeEntities( title ) } | |||
There was a problem hiding this comment.
What are the differences in implementation? Can we add a unit test to catch the broken case here?
There was a problem hiding this comment.
Some level of filtering on wpcom converts #39; to #039;. lodash unescape only looks for an exact match of #39;. WP decodeEntities on the other hand, doesn't search for specific entity strings, it just throws everything into a temporary text field in the dom and then extracts, so relies entirely on the browsers own encoding/decoding, which handles both #39; and #039;
There was a problem hiding this comment.
Added an additional test to cover this variation in entity codes.
…le quote is accounted for
| @@ -123,7 +123,7 @@ class PostTitle extends Component { | |||
| <Textarea | |||
| id={ `post-title-${ instanceId }` } | |||
| className="editor-post-title__input" | |||
| value={ unescape( title ) } | |||
| value={ decodeEntities( title ) } | |||
There was a problem hiding this comment.
I wonder a bit about the corresponding escape which happens in the onUpdate dispatch below. In truth, I'm not actually sure why it's needed at all. But at least previously, there was a duality between unescape and escape which is no longer guaranteed.
There was a problem hiding this comment.
Hmm I wonder why we added only decodeEntities in #7977. I think an upstream patch to lodash (as including leading zeros is okay), and dependency update would work too, but I think I'm missing some context here.
There was a problem hiding this comment.
I wonder a bit about the corresponding escape
Yes, it would be good to update that to an internal encoding method once one is available.
Description
The encoding that was recently added to the post title block works fine on standalone wp installs, but not on wpcom - Automattic/wp-calypso#38362 - this is because for some reason wpcom adds leading zeros to the html entity codes, and lodash unescape does not account for this.
Switching from the lodash unescape to WordPress decodeEntities resolves the issue without causing any problems that I can see.
How has this been tested?
Tested manually, and also added an additional unit test to make sure decodeEntities accounts for leading zeros.
Screenshots
Before:
After:
Types of changes
Change string decoding method
Fixes Automattic/wp-calypso#38362