[wp-trac] [WordPress Trac] #54184: HTML entities get decoded in Customizer text fields

[WordPress Trac]

#54184: HTML entities get decoded in Customizer text fields
-------------------------+-------------------------------------------------
 Reporter:  jqz          |       Owner:  (none)
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Customize    |     Version:  5.8.1
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  ui, administration, coding-
                         |  standards
-------------------------+-------------------------------------------------

Comment (by jqz):

 Replying to [comment:4 jonsurrell]:
 > a workaround may be to override `::render_content()`, but swap any
 `esc_attr()` or `esc_html()` calls for a `strtr()`

 Just calling `htmlspecialchars()` directly (rather than `strtr()`) would
 do the job.  The `esc_xxxx()` functions indirectly do that, but pass
 `false` as the `$double_encode` parameter.  I guess that behaviour is a
 hangover from WordPress having various strings floating around that have
 been HTML-encoded out-of-context.

 Maybe simply adding `$double_encode` as an optional parameter to the
 `esc_xxxx()` functions (default `false` to maintain current behaviour by
 default) would be a fairly straightforward solution to allow correct
 escaping in situations where it is known that the string is not already
 HTML-encoded.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54184#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform