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?

Doctrine, an ORM library, has a convenient little behavior that you can attach to your tables to give them awesome superpowers of geolocation. It’s the Geographical template, and it resides in Doctrine/Template/Geographical.php. What it does is add two fields to your table: Latitude and Longitude, and extends your model with the ability to discern distances between any two of these locations.

That’s all well and good, except that as of 1.2.2, Doctrine’s default precision for a floating point field is 2. That doesn’t allow for very accurate geolocation, as it truncates something like “+33.544622″ down to “33.54″. Not good.

The documentation says absolutely nothing about fixing this behavior. I found a bug listing, but no actual fix. Thus began a long session of guesswork, all futile, and ending in a “duhhh” moment and a quick manual trace of the code to determine how the options for templates are handled.

Long story short, I found a fix, and here it is:

YAML version:

actAs:
  Geographical:
    latitude:
      options:
        scale: 7
    longitude:
      options:
        scale: 7

php model version (in your model’s setUp() function):

$geographical0 = new Doctrine_Template_Geographical(array(
   'latitude' => array(
      'options' => array(
         'scale' => 7,
      ),
   ),
   'longitude' => array(
      'options' => array(
         'scale' => 7,
      ),
   ),
));
$this->actAs($geographical0);

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:

What really shocked me though was when, on the flight up on the 17th (#522 if someone from SW wants to look it up), the flight attendant sang to the crew. Thrice. I was on a non-connecting one-stop flight, and was treated to amusing, silly, fun singing three times. It put a smile on my face. She got applause each time.

Someone needs to introduce that flight attendant to the marketing director, because that was just awesome. It really shows that they’re doing a great job, too: Checking baggage, the lines at every other airline were ghost towns. Southwest was almost spilling out of their guide thingies.

Keep it up, SW.

(I’ve got a lot of posts to make about the latest update to Listy.us, but this seemed a more pressing post. I felt it was worth mentioning before I forgot about it.)