Archive for May 14, 2008

[geshi lang=php]

Where I am not understood, it shall be concluded that something very useful and profound is couched underneath.
- Jonathan Swift

< ?php if($this->failedValidation): ?>

Some problems were detected with the submitted form.

< ?php endif; ?>

< ?php echo $this->entryForm ?>[/geshi]

Let’s accompany our blog entry forms with a little Jonathan Swift for inspiration . We once again meet a validation problem message identical to the one in our login form. As we’re duplicating this message we’re going to have to consider a means later on of isolating such commonly used feedback messages for reuse somewhere in Part 9.

To keep our styling synchronised with our intended form output, add the following to /public/css/style.css:

[geshi lang=css]textarea {
width: 76%;
height: 30em;
}[/geshi]

This should provide a decent styling for textareas for most browsers. Perhaps even Safari which I noticed recently is displaying some of my text fields poorly.

Step 2: Assembling the Entry Form with Zend_Form

We’ve already had a fairly detailed look at Zend_Form back in Part 6 when we wrote a subclass to contain some standard and specific decorator arrays for form elements, and created our Login Form example. The same principles used there also apply here with very few changes. Once again we are using the shorter array-based syntax over multiple method calls. One of the differences to take note of is that I’ve used two new options attribs and value which no form developer could live without!

We’ll start with a new class called ZFBlog_Form_EntryAdd located at /library/ZFBlog/Form/EntryAdd.php:

[geshi lang=php]< ?php

class ZFBlog_Form_EntryAdd extends ZFBlog_Form
{

public function init()
{
$this->setAction(‘/admin/entry/add’);

// Display Group #1 : Entry Data

$this->addElement(‘text’, ‘title’, array(
‘decorators’ => $this->_standardElementDecorator,
‘label’ => ‘Title:’,
‘attribs’ => array(
‘maxlength’ => 200,
‘size’ => 80
),
‘validators’ => array(
array(‘StringLength’, false, array(3,200))
),
‘required’ => true
));

$this->addElement(‘text’, ‘date’, array(
‘decorators’ => $this->_standardElementDecorator,
‘label’ => ‘Date:’,
‘attribs’ => array(
‘maxlength’ => 16,
‘size’ => 16
),
‘value’ => Zend_Date::now()->toString(‘yyyy-MM-dd HH:mm’),
‘validators’ => array(
array(‘Date’, false, array(‘yyyy-MM-dd HH:mm’, ‘en’))
),
‘required’ => true
));

$this->addElement(‘textarea’, ‘entrybody’, array(
‘decorators’ => $this->_standardElementDecorator,
‘label’ => ‘Entry Body:’,
‘required’ => true
));

$this->addElement(‘textarea’, ‘entrybodyextended’, array(
‘decorators’ => $this->_standardElementDecorator,
‘label’ => ‘Extended Body:’
));

$this->addDisplayGroup(
array(‘title’,'date’,'entrybody’,'entrybodyextended’), ‘entrydata’,
array(
‘disableLoadDefaultDecorators’ => true,
‘decorators’ => $this->_standardGroupDecorator,
‘legend’ => ‘Entry’
)
);

// Display Group #2 : Submit

$this->addElement(‘submit’, ‘submit’, array(
‘decorators’ => $this->_buttonElementDecorator,
‘label’ => ‘Save’
));

$this->addDisplayGroup(
array(‘submit’), ‘entrydatasubmit’,
array(
‘disableLoadDefaultDecorators’ => true,
‘decorators’ => $this->_buttonGroupDecorator,
‘class’ => ‘submit’
)
);
}
}[/geshi]

I threw in a sprinkling of Zend_Date above to format the current date to a format compatible with a MySQL database. Zend_Date is also used in the background by the Zend_Validator_Date class which is why the date formatting is identical to both. Note that the formatting is not the PHP regular style used by the date() function, but instead uses ISO format specifiers. This offers a great deal of flexibility if you want something other than MySQL formatted dates.

Finally note that there is no “required” flag for the “entrybodyextended” element since an extended body is optional.

We’re not quite done yet. Our two textareas, as discussed way back in Part 1, are being designed to accept HTML input since I really can’t be bothered to play with custom formatting tags and such. This obviously raises the risk that I, another author, or someone who’s guessed my password may, either by mistake or intent, add some Cross-Site Scripting (XSS) into the mix and introduce a devastating security exploit. We can’t have that now!

Step 3: Filtering Entries using a HTMLPurifier based Custom Filter

What we will do now is attach a custom filter to the textareas containing our Entry data that cleans up any HTML input, removes XSS, and as a bonus converts any non-HTML input into formatted HTML. This, for example, covers our text paragraphs by wrapping them in <p> tags.

My favourite library for achieving this is HTMLPurifier which I consider one of those much under utilised libraries in PHP. To my knowledge, there is nothing out there to beat its comprehensive feature list. Its finest feature is that it actually understands HTML across multiple standards. Input is tokenised, parsed, passed through a whitelist (the opposite of a detection blacklist), reformed as perfectly correct valid output, and then it can optionally wrap stuff like plain text in paragraphs. All for your preferred DTD. Either you’re using HTMLPurifier, or you are using something second or third rate, and I have no qualms whatsoever in stating that as a fact. I cannot praise this library more highly.

To start, you’ll need to download a copy of HTMLPurifer 3.1.0rc1 (which is the latest release at the time of writing) and copy the contents of the package’s /library directory into our blog application’s /library. Since HTMLPurifer follows the PEAR Convention for class naming and file location, we need make no changes to our include_path. If you prefer, you can also install HTMLPurifer from its PEAR channel as described on the download page. Although it’s a release candidate I haven’t run into any problems using it other than my unexplainable habit of mispelling HTMLPurifier as HTMLPurifer which has led to a few frustrating hair pulling moments!

HTMLPurifier’s perfection is not without a performance cost. To improve performance it will utilise a HTML definition cache. Add a new base directory at /cache/htmlpurifier and grant permissions sufficient to let the webserver write files there. Don’t get too caught up over performance as security isn’t an area you want to needlessly play Scrooge with . The performance cost is really only noticeable if using it for post-processing of output being sent to visitors. The cache coupled with the fact HTMLPurifier is used only in the backend Administration eliminates any such cost for the purposes of our application.

Let’s introduce our custom filter classes. I’m saving them using a mirror directory structure of the Zend Framework as usual. Here a standard one I usually use with HTMLPurifier saved to /library/ZFBlog/Filter/HTMLPurifier.php:

[geshi lang=php]< ?php

class ZFBlog_Filter_HTMLPurifier implements Zend_Filter_Interface
{

protected $_htmlPurifier = null;

public function __construct($options = null)
{
$config = null;
if (!is_null($options)) {
$config = HTMLPurifier_Config::createDefault();
foreach ($options as $option) {
$config->set($option[0], $option[1], $option[2]);
}
}
$this->_htmlPurifier = new HTMLPurifier($config);
}

public function filter($value)
{
return $this->_htmlPurifier->purify($value);
}

}[/geshi]

HTMLPurifier options have three distinct elements we can pass to this filter as an array. We could stop here, passing filter options for every form, but this is a very general filter class whose sole purpose is to pass options into HTMLPurifier, so let’s add a subclass of this specifically for HTML textual input with predefined options at /library/ZFBlog/Filter/HtmlBody.php:

[geshi lang=php]< ?php

class ZFBlog_Filter_HtmlBody extends ZFBlog_Filter_HTMLPurifier
{

public function __construct($newOptions = null)
{
$options = array(
array('Cache', 'SerializerPath',
Bootstrap::$root . '/cache/htmlpurifier'
),
array('HTML', 'Doctype', 'XHTML 1.0 Strict'),
array('HTML', 'Allowed',
'p,em,h1,h2,h3,h4,h5,strong,a[href],ul,ol,li,code,pre,'
.'blockquote,img[src|alt|height|width],sub,sup'
),
array('AutoFormat', 'Linkify', 'true'),
array('AutoFormat', 'AutoParagraph', 'true')
);

if (!is_null($newOptions)) {
// I'll let HTMLPurifier overwrite original options
// with new ones rather than filter them myself
$options = array_merge($options, $newOptions);
}

parent::__construct($options);
}

}[/geshi]

This new subclass passes specific options to HTMLPurifier. We provide the path to the cache directory created previously, inform the library our output should conform to XHTML 1.0 Strict, add a whitelist of allowed tags and attributes, and finally enable two optional formatting helpers to auto paragraph output (wrapped with &ltp> tags) and transform URLs into hyperlinks. If ZFBlog_Filter_HtmlBody needs further adjustment we can pass it options when attaching this filter to our form elements.