Mark Tuttle

Good solution, Doug. Your experience with the admin dashboard is explained in this article where it says that $allowedposttags “is the set [of tags] that is allowed to be put into Posts by non-admin users (admins have the “unfiltered_html” capability, and can put anything they like in).” This capability is checked for in kses_init. I had a similar experience with the problem disappearing in contexts I couldn’t characterize as well as you did, and might never have noticed this sentence without your report.

The problem is in the KSES module (“kses strips evil scripts!”) in wp-includes/kses.php. This is an html filtering mechanism that strips malformed elements, attributes, and values with the intention of avoiding problems like the security vulnerability known as a cross-site scripting attack. KSES is described more completely here and here.

The problem is that the default definition of $allowedposttags says that the ‘div’ element can have a ‘class’ attribute but not an ‘id’ attribute. So KSES is stripping the ‘id’ attribute given in the example above. Indeed, adding ‘id’ as an allowable attribute solves the problem.

It appears possible to override this behavior by setting
define('CUSTOM_TAGS',false); and giving your own values for $allowedposttags, $allowedtags, and $allowedentitynames. I’m not sure where you would set these, perhaps in your theme’s functions.php, although fixing this should be independent of your theme.

But why would any html filtering mechanism allow an element like ‘div’ or ‘td’ to have one of the attributes ‘class’ or ‘id’ and not the other? Since the values of these attributes are always interpreted as strings or identifiers, how could they contribute to a security vulnerability?

Shouldn’t it be an invariant that where ‘class’ is allowed ‘id’ is also allowed, and vice versa? Who should I be writing to to get this fixed in the next release of WordPress?