[wp-trac] [WordPress Trac] #23688: esc_textarea, wp_richedit_pre and wp_htmledit_pre eat post content under PHP 5.4

[WordPress Trac]

#23688: esc_textarea, wp_richedit_pre and wp_htmledit_pre eat post content under
PHP 5.4
--------------------------+-----------------------
 Reporter:  westi         |       Owner:  westi
     Type:  defect (bug)  |      Status:  reopened
 Priority:  high          |   Milestone:  3.6
Component:  Formatting    |     Version:  trunk
 Severity:  blocker       |  Resolution:
 Keywords:  needs-patch   |
--------------------------+-----------------------

Comment (by trevHCS):

 Replying to [comment:10 azaozz]:
 > Thinking we need `wp_htmlspecialchars()` where `blog_charset` can be
 normalized, etc.

 I am wondering whether normalising the blog_charset would maybe be better
 done within get_option() rather than a specific new function?

 Reasoning being there are 3 PHP 5.4 functions where this change to UTF-8
 was made:

 htmlspecialchars()
 htmlentities()
 html_entity_decode()

 There are already scripts within WP core which use the proposed
 get_option('blog_charset') fix as documented below, so fixing it in a new
 function wouldn't actually help those if the charset was incorrect.

 Scripts found to already use the fix:

 - default-widgets.php -> function widget() -> html_entity_decode()
 - feed.php -> get_the_category_rss() -> html_entity_decode()

 This doesn't remove the need to update the code to use the
 get_option('blog_charset') within any of the above function calls, but it
 would seem to me at least that fixing it once would be easier than fixing
 it lots of times?

 Fixing it in get_options() would also fix any errors in HTML headers,
 albeit that is outside the remit of this ticket.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/23688#comment:11>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software