[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 jonsurrell):

 This seems like a case of the `esc_attr()` trying to avoid double-encoding
 entities around here:

 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-
 customize-control.php?rev=60715#L672
 WP_Customize_Control::render_content()].

 #60229 may someday help with this by introducing templating and the
 ability to distinguish between HTML and unescaped plaintext.

 For this specific issue, a workaround may be to override
 `::render_content()`, but swap any `esc_attr()` or `esc_html()` calls for
 a `strtr()` [https://core.trac.wordpress.org/browser/trunk/src/wp-includes
 /html-api/class-wp-html-tag-processor.php#L3774 like the HTML API uses].
 This snippet is a suitable replacement for `esc_attr()` and `esc_html()`
 where escaping is intended (regardless of whether things ''appear'' to be
 double-escaped):

 {{{#!php
 <?php
 strtr(
       $plaintext_content,
       array(
             '<' => '<',
             '>' => '>',
             '&' => '&',
             '"' => '"',
             "'" => ''',
       )
 )
 }}}

 This is the same issue as #64054, except that this issue is for the
 customizer.

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