[wp-trac] Re: [WordPress Trac] #9935: Quick editor for comments
converts encoded HTML entities back into plain form
WordPress Trac
wp-trac at lists.automattic.com
Wed Jun 3 08:28:47 GMT 2009
#9935: Quick editor for comments converts encoded HTML entities back into plain
form
---------------------------+------------------------------------------------
Reporter: michaeltyson | Type: defect (bug)
Status: reopened | Priority: normal
Milestone: 2.8 | Component: Comments
Version: 2.7.1 | Severity: minor
Resolution: | Keywords: needs-patch comments quick edit html entities encode htmlspecialchars
---------------------------+------------------------------------------------
Comment(by hakre):
'''Filters (Backend)'''[[BR]]
''comment_text''-Filter (simplified)
{{{
9: make_clickable - make_clickable(1 arg)
10: wptexturize - wptexturize(1 arg)
10: convert_chars - convert_chars(1 arg)
20: convert_smilies - convert_smilies(1 arg)
25: force_balance_tags - force_balance_tags(1 arg)
30: wpautop - wpautop(1 arg)
}}}
''get_comment_text''-Filter
{{{
null
}}}
If you see the list of applied filters it is perfectly clear, why this bug
is in. it is by implementation. It is totally unforseen to properly escape
ampersands.
This is not OK for both, the frontend and backend. For the frontend it is
not OK because it prevents to display ampersands well in comments. And in
the backend it prevents to display and to edit such comments.
Because the standard comment editor does not have the problem that the
comment-list and quickedit have, the template function can be adopted to
the standard comment editor in ''wp-admin/comment.php'' ({{{$comment =
get_comment_to_edit( $comment_id );}}}) resp. ''wp-admin/edit-form-
comment.php'' ({{{<?php the_editor($comment->comment_content, 'content',
'newcomment_author_url', false, 4); ?>}}}) (the
''the_editor_content''-filter might apply which was null).
Considering the content editor working perfectly right means that the
comment list in the backend should use the comment data as in comment.php.
For the bug on the frontend the one who wrote the output implementation in
the template include should take of that. I would rate it "defect by
design" because it does not handle ampersands well. The cause can be
somewhere else as well, as shown, the ''comment_text()'' function does
make use of a lot of filters. just guessed, maybe convert_chars() is
unable to handle that?
Whatever. I could figure out that wp-action/comment.php does it right with
a plain output of $comment->comment_content but this does not do the job
for the list. The standard editor has encoded ampersands (with or w/o
javascript) therefore there must be another processing on the data i have
not found so far. I need to dig into that further first.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/9935#comment:7>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list