[wp-trac] [WordPress Trac] #3670: Removing CDATA close tag ( ]]> ) unbalances the CDATA block

[WordPress Trac]

#3670: Removing CDATA close tag ( ]]> ) unbalances the CDATA block
--------------------------+-------------------------------------------------
 Reporter:  scenic        |       Owner:  andy                                          
     Type:  defect (bug)  |      Status:  new                                           
 Priority:  normal        |   Milestone:  2.9                                           
Component:  Template      |     Version:  2.1                                           
 Severity:  normal        |    Keywords:  has-patch needs-testing needs-unit-tests early
--------------------------+-------------------------------------------------
Changes (by kirkpatrick):

 * cc: kirkpatrick (added)


Comment:

 The substitution of the right bracket in the CDATA closing,
 {{{
 $excerpt = str_replace(']]>', ']]>', $excerpt);
 }}}
 occurs in a number of places in WordPress, all in wp-includes:
   comment.php Line 1355

   feed.php Line 191

   formatting.php Line 1734

   post-template.php Line 168

 So this substitution seems to be desired for reasons other than
 "protecting feeds".  Perhaps security against javascript-driven xml
 injection attacks? (It would be useful if the gods of WordPress would tell
 us the meaning of all this.)

 Anyway, as it is, a page written by a plugin that creates javascript that
 includes strings of html will not validate as xhtml.  Since we can
 (presumably) trust plugins, it should be ok to fix this: just reverse the
 order of lines 167 and 168 in post-template.php, so the filters
 (potentially set by plugins) are applied ''after'' the replacement:
 Change
 {{{
         $content = apply_filters('the_content', $content);
         $content = str_replace(']]>', ']]>', $content);
 }}}
 to
 {{{
         $content = str_replace(']]>', ']]>', $content);
         $content = apply_filters('the_content', $content);
 }}}
 This way, any CDATA in the post (as stored in the database) will lose the
 CDATA, as seems to be desired, but the plugin can still operate properly
 and validate.

 The same reversal should also be done (my application doesn't need these,
 but ...) in comment.php (line 1355 to above 1351) and formatting.php
 (exchange 1733 and 1734).

 This is a minimal change, and I believe makes more sense than the present
 code. The post content is filtered, but then the plugin is allowed to do
 its work.

 Of course, this fix does not meet the needs of the earlier change posters,
 who wish to post javascript hidden with CDATA. I don't think I support
 this for standard WordPress.

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