Allow rel attributes on links in KSES

[joostdevalk]

Due to the ​recent Google changes, authors will be wanting to add rel="me" to the links in their author descriptions on blogs they write on. Currently though, rel="me" (and every other rel) is stripped out because it's not an allowed attribute.

I propose we allow it, there seems to be no harm in allowing it and it would help people out. Patch attached.

Patch of KSES filter to allow rel attribute on links.

Good to me as long as there are no security issues.

+1 from me. If href and title is allowed can't imagine why rel should be worse.

Ugh, just thought of an issue. The way this patch is done right now, you'd probably also be able to add rel="me" and rel="author" etc. in a link in the comments which is unwanted behavior I suppose.

We could add it to allowedposttags only.

Replying to nacin:

We could add it to allowedposttags only.

It's already allowed there, I'd like it allowed in author bio's...

This whole thing is a mess thanks to how ancient the kses library is and how the globals and constants were implemented there.

Something like this should work as a one-off:

remove_filter( 'pre_user_description', 'wp_filter_kses' );
add_filter( 'pre_user_description', 'wp_filter_pre_user_description' );
function wp_filter_pre_user_description( $data ) {
	$allowedtags = $GLOBALS['allowedtags'];
	if ( isset( $allowedtags['a'] ) )
		$allowedtags['a']['rel'] = array();
	return addslashes( wp_kses( stripslashes( $data ), $allowedtags ) );
}

Ugh that is ugly. Anyway we can fix that in a less ugly way? If it involves rewriting kses, i'm up for that with some help :)

At this point we're past freeze, and and are switching over to "bugs only" mode. Punting and marking for 3.4-early. If you guys figure out what to do about kses etc., this ticket can be one of the first things in 3.4.

Related #18649

Related: #20210

Related: #21825

In [21790]:

• Introduce wp_kses_allowed_html() which accepts a context string and returns an array of allowed tags.
• Remove explicit declarations of class, id, style, and title from $allowedposttags
• Dynamicallly add global attributes to every tag for the 'post' context
• No longer calls wp_kses_array_lc() every time wp_kses() runs. Instead it runs once if CUSTOM_TAGS is true. Plugins directly passing a custom allowed_html array will no longer get the lc treatment. Keep an eye out for problems with this.
• wp_kses_data() and wp_filter_kses() pass current_filter() for the $allowed_html argument to wp_kses().
• wp_kses_allowed_html() handles being passed a filter name for a context. If the filter is not a recognized one it defaults to using $allowedtags as was done before for wp_kses_data() and wp_filter_kses().
• wp_kses_allowed_html() recognizes user_description and pre_user_description out of the box. For these it takes $allowedtags and inserts rel attribute support.
• wp_kses_allowed_html() allows plugins to override the return values for the default contexts and support arbitrary contexts via a wp_kses_allowed_html filter.
• wp_kses_hook() can now pass a string context for $allowed_html to the pre_kses filter. We might have to pass the result of wp_kses_allowed_html() instead if it turns out that plugins are digging in $allowed_html.

fixes #17977
see #20210

In [21795]:

Remove kses allowedtags that were commented out long ago. see #17977.

In [21796]:

Recommend the wp_kses_allowed_html filter over CUSTOM_TAGS. Soft deprecate CUSTOM_TAGS. see #17977, #20210.

[21790] is a work of art. <3

Maybe include support for data-* attributes to be HTML5 ready?