[wp-hackers] about a possible bug related to attribute_escape

[Andrea Ercolino]

attribute_escape's declaration (includes/formatting:1102)


// Escaping for HTML attributes
function attribute_escape($text) {
  $safe_text = wp_specialchars($text, true);
  return apply_filters('attribute_escape', $safe_text, $text);
}


attribute_escape's use I'm talking about: (admin/admin-functions:942)


$entry['meta_value'] = attribute_escape($entry['meta_value']);


I think there is a bug with respect to this use.

If I insert an html entity like &# 8212; into a custom field value (I'm
escaping with a space now), then it is recorded as &# 8212; but when that
value is read back, attribute_escape will display it as the corresponding
char (—). Now, if I update that custom field without changing
anything, I'd expect that the recorded value will still be &# 8212; but it
will be something completely different and garbage-like (—). From now on,
the recorded value will be — and the displayed value will be —, no matter
how many times I keep updating it.

The problem is that I really want the chars exactly as I put them into a
custom field, i.e. if I put &# 8212; then I want &# 8212; recorded and
displayed (in the editing panel): I don't mean at all — nor — !! 

This is true not only for meta_value, but also for meta_key, and not only
for &# 8212; but also for any other entities / chars.

WordPress should not change the values of the custom fields because they are
the last resort for keeping data as is, untexturized.

I've tried the following and it works as expected (by me)


$entry['meta_value'] = htmlspecialchars($entry['meta_value']);


What do you think?
Is it a bug?

-- 
View this message in context: http://www.nabble.com/about-a-possible-bug-related-to-attribute_escape-tf3262952.html#a9069531
Sent from the Wordpress Hackers mailing list archive at Nabble.com.