[wp-trac] [WordPress Trac] #32556: Clarify behaviour of esc_attr() with respect to HTML entities

[WordPress Trac]

#32556: Clarify behaviour of esc_attr() with respect to HTML entities
--------------------------+-----------------------------
 Reporter:  leewillis77   |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Formatting    |    Version:  4.2.2
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 I've just come across this, and would welcome some info on what the
 *right* thing is to do here. For background, also see #25485.

 Currently, I have a string:

 {{{
 Next Events <span>»</span>
 }}}

 I want to place this into the value of an INPUT tag. I was using
 esc_attr(), e.g.

 {{{
 <input value="<?php echo esc_attr( $string ); ?>">
 }}}

 That results in an INPUT field that displays as:

 {{{
 Next Events <span>»</span>
 }}}

 IE - the » has been converted to » rather than &raquo; which is
 what is desired, to make the input box display as:

 {{{
 Next Events <span>»</span>
 }}}

 So, I assumed that I should be able to encode the entity myself, and then
 apply esc_attr() since esc_attr() advertises that it "will never double
 encode entities"
 (https://codex.wordpress.org/Function_Reference/esc_attr).

 However, beyond "not double-encoding entities", what esc_attr() actually
 does is normalize any entities - even if they've previously been
 deliberately encoded. This seems like a bug if not in the function, then
 in the documentation, but I'm not sure what the *right* thing to do is
 here?

 It's possibly to just use htmlentities(), and not use esc_attr() at all,
 but that feels like I might be missing out on some additional protection
 afforded by esc_attr(). Any guidance welcome.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32556>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform