Skip to content

How to allow more html tags in the wordpress comments?

Scenario: I am using the tinymcecomments plugin to give some formatting capabilities to commenters. Also oEmbed for Comments is nice one – when you put a link to youtube or vimeo it automatically embeds the video.
With the latest WP update I realised the span tag was removed from comments; colors attributes are filtered by the kses filter.


After investigating I come across this suggestion in the Codex:

Acceptance of HTML tags in the comments field is managed in the file kses.php, located in the wp-includes folder.

Open this file in a text editor, and locate the list of HTML tags near the top of the file. Each HTML tag is listed on a separate line, in the construction of a PHP array of allowed tags. Lines which begin with // are commented-out, or disabled, so lines which begin with // designate HTML tags that are not allowed in comments.

To stop people from posting HTML in comments, edit your kses.php file as desired to allow or disallow specific HTML tags in comments, by adding // to the very beginning of the appropriate lines of the list. To exclude all HTML tags, comment out all lines which allow HTML tags. Be sure to save your file when done.

That’s a start but hey, is the Codex really suggesting that I alter the WP core? Next update my all precious settings will go away. C’mon, we can do better than that!

In the kses source code I find this:

if (!defined('CUSTOM_TAGS'))
	define('CUSTOM_TAGS', false);


So basically I can redefine all the allowed tags structure in a constant. Not bad. But hey, do I really want to redefine both the $allowedposttags and the $allowedtags variables? Naaah…

So I scavenged in the source code and I came across a fit filter. I wrote a little function for my functions.php file; needless to say, this could have gone into a plugin.


function fa_allow_tags_in_comments($data) {
	global $allowedtags;
	$allowedtags['span'] = array('style'=>array());
	$allowedtags['p'] = array();
	return $data;

See? Much more concise than overwriting the variables. And more future-proof: if subsequent versions of WordPress change the variable there is no constant barring the changes.


Original post:

Published inCodingWordpress