LinkPicker: Decode HTML entities in link preview title#77170
Conversation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Size Change: +5 B (0%) Total Size: 7.74 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in e2e3e57. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/24170916879
|
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
| className="link-preview-button__title" | ||
| > | ||
| { title } | ||
| { stripHTML( title ) } |
There was a problem hiding this comment.
The stripHTML removes HTML, but I don't think it decodes the entities.
There was a problem hiding this comment.
I think __unstableStripHTML (stripHTML) does decode the entities:
wp.dom.__unstableStripHTML( '<b>Hello & World</b>' )
// => "Hello & World" There was a problem hiding this comment.
I wanted to ask whether we need to do something like decodeEntities( stripHTML( title ) )
There was a problem hiding this comment.
Oh, I should have just searched 😄
If we trust fetchLinkSuggestions then maybe no?
There was a problem hiding this comment.
TIL. We usually use decodeEntities in the codebase. If it works then why change :D
There was a problem hiding this comment.
My prediction is that if unpredictable HTML might be included, stripHTML might be better than decodeEntities. For example, stripHTML is also used in the post title:
If we trust
fetchLinkSuggestionsthen maybe no?
Perhaps fetchLinkSuggestions is intended for search results 🤔
There was a problem hiding this comment.
Perhaps fetchLinkSuggestions is intended for search results
Well... there is that too! 😆 Sorry I was in a rabbit hole.
I think with decodeEntities is fine if we're unsure if we're getting entity-encoded values. I just tested and couldn't break it. Not that that means much!
This is likely related to loopback requests not working in wp-env. A similar issue has been reported in #77057 (comment). This should be resolved by #77155. |
Co-authored-by: t-hamano <wildworks@git.wordpress.org> Co-authored-by: Mamaduka <mamaduka@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
|
I just cherry-picked this PR to the wp/7.0 branch to get it included in the next release: 7f77de5 |




Noticed this issue while reviewing #77155
What?
Fix HTML entities not being decoded in the
LinkPickercomponent.Why?
This happened because the title was rendered directly as
{ title }in JSX without any processing. React renders JSX text content as plain text nodes, so HTML entities are not decoded automatically.How?
Apply
stripHTML()to thetitleprop before rendering it. This approach is consistent with the behavior in link-control/link-preview.js.Testing Instructions
Sample & Page <>🙂)Sample & Page <>🙂Sample & Page <>🙂Screenshots or screencast
Before
After
Use of AI Tools
Claude Sonnet 4.6 (Claude Code) was used to assist with identifying the root cause and implementing the fix. The change was reviewed and committed by the author.