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 )” …

Results:

A: typeof obj == “object” : 439 msec
B: util.isObj(obj) : 1228 msec (where util = { isObj : function(o) { return typeof o == “object”; } })
C: isObj(obj) : 1155 msec (where B and isObj = util.isObj)

Conclusions:

First, remember that these are looping over 100 million iterations. This kind of research might be useful for a worker thread, but it’s not terribly useful for day to day stuff.

The big conclusion here is if you’re only going to call a function from one or two places, or it’s very short, skipping the function and putting the code inline will save you about 60%, but it’s really only significant if you’re calling that function millions of times.

The second conclusion is that if you must use a function for something like this (millions of calls), you can save a tiny bit—almost completely insignificant—of time by getting a reference to that function. Keep in mind that this micro-optimization only works if the function you’re calling doesn’t require context. If you have to use the .call or .apply methods to add context, this approach is actually about 17x slower.

Actual testing code at http://jsfiddle.net/jsylvanus/tTsXp/

Second, I’ve been posting some related tutorials in the project’s forums:

• Getting started with phpScenario & Zend Framework (updated for 0.1.1)
• Configuration example for PDO adapter
• Working with Identity Providers (new for 0.1.1)

So, if you’re interested in split testing via php, I’d recommend checking the project and tutorials out.

Third, I’m finally getting started on the rewrite of Listy.us’s editor. Where the old editor was a single, sparsely-commented 1400-line javascript file, the new one is spread across several files using RequireJS, and uses QUnit for unit testing. It is, essentially, a project in itself, and I’m finding it much, much nicer to work with.

You can check out the free split testing library in all it’s beta glory at www.phpscenario.org and post any questions on the discussion boards. It’s version 0.1 beta, as in “Well, it works for me, but could probably use some tuning.”

Split testing, or A/B testing, is a method for testing goal-oriented theories. Essentially you say “I think (blank) will be more effective than (blank),” and then collect data to verify or disprove that hypothesis. In its simplest form, you’re just testing a 50/50 between two theories, a control and an alternate version. phpScenario assumes that this is the most desirable route and has defaults as follows:

• 50/50 split test between control (“default”) and “alternate”
• assumes you want to use session ID as the identifier
• assumes a certain database structure

Basically all you have to provide it with is a data adapter (two are currently provided in the library, for Zend_Db and PDO) and the database info, and you can fire away with one-liner testing.

The library makes room for more elaborate testing however, by allowing you to define classes for special cases, inheriting from Scenario_Experiment. It’s an object-oriented library, so I’ve tried to take advantage of that where possible. You can also define your own Identity objects, if you’d prefer to use, for example, a user ID rather than the session id as an identifier for testing.

As stated in the previous post, there’s an abstract renderer object and an included renderer that outputs XML, and optionally translated that XML via included or provided XSL translation files. The included one translates the data to a fairly simple HTML table, including z-score so you can judge just how reliable the data is.

How to Install

• Download the package and run database.sql against the database you’re intending to use. There’s an example of how to do so using the mysql command line tool in README.txt in the package.
• Include and configure the core per the documentation. If you’re not using something with a bootstrap like Zend Framework, you should probably put all the configuration stuff in one file and just require_once that file whenever you need to do Scenario calls.
• That’s it. Start making calls to the library.

It’s a pretty straightforward setup process. I basically designed the library to solve my own problems, and wanted something I could just throw into any given project and have a working solution in under a minute. Add tables, configure core, and go. I figured I might as well make it something other folks can use as well.

Once you’ve got the core configured, you can see how easy it is to actually use the library on the phpScenario site.

Questions/comments/etc can go in the comments here or on the forums, I’ll answer both.

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.