[theme-reviewers] Why Rigorous Review of Theme Functional Files is Important

[Otto]

On Thu, Jan 30, 2014 at 11:20 AM, Chip Bennett <chip at chipbennett.net> wrote:

> It is true that a good custom CSS Plugin will save settings on a per-Theme
> basis. But the critical criterion isn't whether a Plugin *can* do
> something; rather, it is whether the *something* is functional or
> presentational. After all, technically speaking, a Plugin *can* add Theme
> support for custom headers and custom backgrounds. Should we force Theme
> developers then to use a custom header/background Plugin, simply because
> one exists and can accomplish the task?
>
> Custom CSS is presentational, and specific to the Theme. As such, I
> believe it falls squarely within the purview of Themes, and if Themes want
> to provide a custom CSS Theme option, such an option would be appropriate.
>


Note: Sanitizing CSS is friggin' hard. A mere strip_tags isn't good enough.

The custom CSS module in Jetpack uses csstidy and a few pre-processors,
among other things. But the basic sanitization function would look like
this:

function dumb_css_sanitize( $css ) {
$css = str_replace( '<=', '<=', $css );
 $css = wp_kses_split( $css, array(), array() );
$css = str_replace( '>', '>', $css );
 $css = strip_tags( $css );
return $css;
}

I named it dumb_css_sanitize because it's kinda dumb. ;)

It allows <= patterns through as LT entities, runs kses over the thing to
strip tags, converts the > symbols back from what kses did, and then runs
strip_tags over it again, just in case. It's fairly safe in that you
couldn't close the style tag with content run through it and therefore get
your content parsed as html or script code. Probably.

This is sort of a minimalistic case. Better to use a real parser if you're
going to do that sort of thing.

-Otto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20140130/5309e8e9/attachment-0001.html>