Add the following to your functions.php:

function custom_autop($p, $br = 1) {
  if (stristr($p, '<!--noautop-->')) {
    return str_ireplace('<!--noautop-->', '', $p);
  } else {
    return wpautop($p, $br);
  }
}
remove_filter('the_content','wpautop');
add_filter('the_content','custom_autop');

That’s it. Now when you add <!–noautop–> to a post, it’ll disable the wpautop() function.

Incidentally, wpautop has a parameter called “$pee” and a loop that reads “foreach( $pees as $tinkle )” …

At the core, I wanted it to be as simple as possible to create new tests, but still have a good degree of flexibility. Basically by default, it assumes you want a A/B 50% split test using the php session ID as the identity. If you have a class defined as [Prefix_]TestName, it’ll load that as the experiment object instead of the default class, and you can do any additional cases (a/b/c/d?) and/or weighting in the treatment selection method. One treatment must always be named “default”.

The simplest possible usage case, after setting up your database, is essentially this:

if (Scenario::IsControl('myExperiment')) {
    // do something 
} else {
    // do something different
}

Next, in your conversion point, you’d do something like this:

Scenario::Complete('myExperiment');

Easy, right? Rendering results looks like so:

Scenario::RenderXml('myExperiment');

The html output looks like this (data set is basically a bunch of randomized 50/50 data):

If you specify “xml” for the translation, you’ll get something like this:

Scenario::RenderXml('myExperiment','xml');

Lots of thanks to Jesse Farmer for his incredibly useful article on statistical analysis and A/B testing. That article saved me a lot of headaches in attempting to decode the wikipedia article on the underlying concept. Seriously, wiki is freakin’ horrible when it comes to plain english explanations of mathematical concepts.

Any suggestions or feature requests while I’m in the documentation / tweaking phase?

The short version of the result is that the md5() function won across the board. The comments in the php.net hash function documentation seemed to indicate a performance increase in using hash(‘md5′,$str), and an even better increase in hash(‘md4′,$str). I found this to only partially be the case; While using the hash function, md4 is minutely faster than md5, the md5() function itself is considerably faster than either of these.

So, for any performance sensitive case, I would say md5() is by far the best choice.

Actual results of the test suite can be seen here:

Basically you create a view (here called $renderer) and a layout ($layout), then render your views and layouts for both HTML and text versions. My file tree looks like this:

application/
	emails/
		welcome.html.phtml
		welcome.text.phtml
		layouts/
			layout.html.phtml
			layout.text.phtml

So, ‘welcome’ would be your template name, with html and text versions. The layout is what you want wrapped around either version of every email you send out (header graphics, font settings, contact info, etc).

I keep all of my mail functions in one class, creating a new function for each email that needs to be sent out regularly in an automatic fashion. You could even use this for newsletters, but I prefer more robust environments like MailChimp or CampaignMonitor for that sort of thing.

This simple function handles all the rendering, file paths, etc. It just needs to be called with the proper template name, and an array of items to be passed to the view renderer.

Here’s the meat of it:

/**
 * getMailContent
 * Renders mailer content in text and html and passes it back as an array('html'=>content,'text'=>content)
 *
 * @param string $templatename the name of the email template to use (APP/emails/[name].[format].phtml)
 * @param array $substitutions key=>value array of variables to pass to the view renderers
 * @return array
 */
public function getMailContent($templatename, $substitutions) {
 
    // create a view renderer and set it to app_path/emails/
    $renderer = new Zend_View();
    $renderer->setScriptPath(realpath(APPLICATION_PATH . '/emails/'));
 
    // create a layout object and set it to app_path/emails/layouts
    $layout = new Zend_Layout(APPLICATION_PATH . '/emails/layouts/');
    $layout->setView($renderer); // this probably isn't even necessary
 
    // assign all substitutions (e.g. view variables) to the view renderer
    foreach ($substitutions as $key => $sub) $renderer->$key = $sub;
 
    $output = array(); // output array        
 
    // render text version of template & assign to output['text']
    $layout->content = $renderer->render($templatename . '.text.phtml');
    $layout->setLayout('layout.text');
    $output['text'] = $layout->render();
 
    // render html version of template & assign to output['html']
    $layout->content = $renderer->render($templatename . '.html.phtml');
    $layout->setLayout('layout.html');
    $output['html'] = $layout->render();
 
    // all done, return output
    return $output;
 
}

Nice and simple, huh? All you need to do is call it and then assign the output to your Zend_Mail object like so:

        $bodies = $this->getMailContent('new_comment', array(
            'comment' => $comment,
            'comment_list' => $comment_list,
            'comment_user' => $comment_user,
            'list_owner' => $list_owner
        ));
        $mail->setBodyHtml($bodies['html']);
        $mail->setBodyText($bodies['text']);

Your email template accesses the variables passed to it just as it would a normal view script:

$this->[variable]

Commentary / suggestions / etc welcome in comments.