The real challenge, however, is “Getting Something Out There” that you can build on. I don’t mean setting up a blog or a couple of static pages, I mean putting in place a scaffolding that you don’t have to replace in its entirety as your business concept matures. The optimal solution then seems to be to use an established software package that can be extended to suit your needs.

Easier said than done. Every CMS out there claims to be extendable, yet not all are created equal. Furthermore extensibility usually requires that you build within their own framework, which then locks you into a third party whom you don’t have control over.

This can be overcome by developing your business services independently, and create a loose integration between your application and your CMS. By doing this you’re suddenly free to proceed with your own plans without the added worry of being locked into a platform.

So why did I choose WordPress and Zend? Well, WordPress has an easily understood plugin structure as well as an active developer community, plus its plugins allow you to do pretty much anything your heart desires. Zend was chosen because it’s a professionally supported application framework with quite a few corporate backers, and it’s written in the same language as WordPress- PHP (Plus, it’s what I know- Added Bonus).

The rest of this post is going to get technical, so I hope those of you who aren’t as geeky as I don’t mind. In essence I describe how to accomplish a loose WordPress-to-Zend integration with all the benefits I described above.

Step 0: Assumptions

Before I begin, there are some assumptions I’m going to make.

1. You know how a Zend MVC application is structured.
2. Your Zend code base will be hosted on the same server as your WordPress install.
3. You are running application stacks on the same primary domain. (blog.fancybrandname.com and www.fancybrandname.com works)
4. Your Zend application will handle user authentication records. This is because you don’t necessarily want to be restricted to WordPress’ table structure.
5. Your application uses the MVC Templating System that comes with Zend.
6. The WordPress integration code will live in the plugins directory on the WordPress side and (with one notable exception) in the ~library/ directory on the Zend side.

Most importantly, please understand that this implementation is NOT for the faint of heart, and requires additional code on your part. I cannot easily make any assumptions about how user authentication is handled within your Zend application, nor what models or methods you have built to simplify object retrieval.

Step 1, Database: Create a linking table

The first fundamental requirement is that we need some way of linking the WordPress user table (usually named wp_users) to the user table in the zend application. Usually this is done via a linking table, that might look something like this:

CREATE TABLE `user_id_link_table` (
  `id_zend` bigint(20) unsigned NOT NULL,
  `id_wordpress` bigint(20) unsigned NOT NULL,
  KEY `id_zend ` (`id_zend `),
  KEY `id_wordpress ` (`id_wordpress `)
);

Step 2, Zend and WordPress: Configure the Cookie Domain

To make sure your authentication cookies are available across your two domains, you’ll need to make sure both WordPress and Zend are looking for the same cookie. The way to do this is to set a wildcard Cookie domain so it transfers from one domain to another. If you look through the various configuration files and session initialization methods, you might see entries like “www.yourdomain.com” or “blog.yourdomain.com” near a reference to a cookie domain. To make sure they transfer, replace all instances with “.yourdomain.com” (the period at the beginning is important). That should ensure that your cookies are portable.

Step 3, Zend: Setting up an integration controller

The first thing we need to do is make sure that your Zend Application is fully loaded. Since you might want to use view helpers in your page templates, this means that we actually have to set up a ‘dummy’ controller that is used for integration purposes only, but which doesn’t try to output anything. This is easily done:

<?php
/**
 * The Integration Controller.
 */
class IntegrationController extends Zend_Controller_Action
{
    /**
     * Index action. Sets up the entire framework but disables output.
     */
    public function indexAction()
    {
        $this->_helper->viewRenderer->setNoRender();
    }
}

Step 4, Zend: Extending the AutoLoader

The fourth step is that we need to extend the Zend AutoLoader, because otherwise it will get confused when WordPress tries to load its plugins. Since we don’t really know which plugins will be loaded ( and thus we can’t explicitly include them in our $PATH ), we’re simply going to restrict the Zend Autoloader to restrict its activities to certain namespaces.

This file is called ~library/Wordpress/Loader.php

<?php
require_once('Zend/Loader.php');

/**
 * The WordPress loader class is a quick filter that ensures only specific application
 * libraries are passed through to load handling.
 */
class WordPress_Loader extends Zend_Loader
{
    /**
     * Override of the loadClass method.
     *
     * @param string $class
     * @param string|array $dirs
     */
    public static function loadClass($class, $dirs = null)
    {
        $parts = split("_", $class );

        switch ( $parts[0] )
        {
            case 'Zend':
            case 'Wordpress':
            case 'YourNamespace':
                parent::loadClass($class, $dirs);
        }
    }

    /**
     * This handler has to be here for Zend_Loader invocation purposes
     *
     * @param class $class
     * @return string|boolean
     */
    public static function autoload($class)
    {
        try {
            self::loadClass($class);
            return $class;
        } catch (Exception $e) {
            return false;
        }
    }
}
?>

Once we’ve extended our AutoLoader, we now have to properly invoke it in our Zend Bootstrapper.

NOTE: You may have to adjust the following code somewhat so it fits in with your application. My own application has a Bootstrap Class within which this is a private method.

/**
 * Application Bootstrapper.
 */
class Bootstrap
{
    private function setAutoLoad()
    {
        require_once ( 'Zend/Loader.php' );
        // Notice that I'm still calling Zend_Loader, but I'm passing the new Classname.
        Zend_Loader::registerAutoload('Wordpress_Loader');
    }
}

Step 5, Zend: Creating a Session Model

This fifth step is necessary if you’re going to delegate all authentication tasks to the Zend application rather than to WordPress itself. By treating our user sessions like a CRUD-based application, we can abstract it entirely into a Model rather than keeping the code within a Controller. By doing this we can invoke the method from anywhere, including a WordPress plugin.

NOTE: I’m putting this session class into the WordPress namespace, while it really should go into a namespace appropriate to your application.

<?php
/**
 * The session model wraps basic session creation and destruction methods
 * into one single interface.
 */
class WordPress_Model_Session extends WordPress_Model_Abstract
{
    /**
     * Creates a new session (aka logs in a user)
     *
     * @param string $user
     * @param string $password
     * @return
     */
    public function create ( $user, $password )
    {
        // Get our authentication adapter and check credentials
        $adapter    =   $this->_getAuthAdapter( $user, $password );
        $auth       =   Zend_Auth::getInstance();
        $result     =   $auth->authenticate($adapter);

        if ( !$result->isValid() )
        {
            return false;
        }
        else
        {
            // We're authenticated! Add your own logic here.

            return true;
        }
    }

    /**
     * Destroys a session (aka logs out a user)
     */
    public function destroy ( )
    {
        Zend_Session::forgetMe();
        Zend_Auth::getInstance()->clearIdentity();
    }

    /**
     * Constructs an instance of the auth adapter for this model.
     *
     * @return Zend_Auth_Adapter_DbTable
     */
    protected function _getAuthAdapter( $login, $password )
    {
        // Put your authentication plugin loader code here.

        return $adapter;
    }
}

Step 4, Zend: Add an integration method to your Zend Bootstrapper

The last thing we need to do is create a method in our bootstrapper that lets us load the entire application without Zend trying to parse the URL into which it was loaded. To do this, we create our own HTTP Request instance with a URL that invokes the Controller and Action we created in step 3, thus effectively ‘fooling’ the FrontController into thinking it was invoked from somewhere else.

/**
 * Application Bootstrapper.
 */
class Bootstrap
{
    /**
     * Executes the application in a bootstrapped integration state.
     */
    public function integrate()
    {
        // Construct a 'Dummy' Url to use for our Request.
        $uri = sprintf ( 'http://%s/integration/index',$_SERVER['HTTP_HOST'] );
        // Create a new request object
        $request = new Zend_Controller_Request_Http( $uri );
        // Dispatch our FrontController
        $this->_frontController->dispatch( $request );
    }
}

At this point, we’re done with all the work we need to do on the Zend side of things. On to the WordPress Plugin!

Step 6, WordPress: Create a plugin

The sixth step is to make sure that your entire Zend Application is available to WordPress. This is a security risk- the instant someone discovers a vulnerability in WordPress they’ve got access to everything, so make sure you have a competent PHP developer who knows how to secure an application.

<?php
/*
Plugin Name: Zend Integration Plugin
Version: 1.0.0
Description: Allows WordPress to authenticate users against the a Zend Session Model
Author: Michael Krotscheck
Author URI: http://www.krotscheck.net/
*/

class ZendIntegrationPlugin
{
    /**
     * Constructor. Initializes this class.
     */
    function __construct()
    {

    }
}

// Load the plugin hooks, etc.
$zend_integration_plugin = new ZendIntegrationPlugin();

Step 7, WordPress: Load the Zend Framework

The next step is to load your Zend application. By creating a method that explicitly loads our Bootstrapper and then invoking the integration method we created in Step 3 above, we load all necessary classes and dependencies without them interfering with WordPress.

class ZendIntegrationPlugin
{
    function __construct()
    {
        // .... previous code ....
        $this->Wordpress_framework_init();
    }

    /**
     * Initialize the Zend framework for inclusion.
     */
    public function WordPress_framework_init()
    {
        // Import the Zend Bootstrapper. This path needs to be absolute.
        require_once ( '@APPLICATIONROOT@/bootstrap.php' );

        // Create a new Bootstrapper instance and invoke the integration method.
        $bootstrap = new Bootstrap ( );
        $bootstrap->integrate();
    }
}

Step 8, WordPress: Disable Unnecessary Functions

Since we’re delegating all session authentication tasks to your Zend application, we need to explicitly disable many of WordPress’ default functionality related to password and account management. We do this by using the application hooks created explicitly for that purpose.

<?php

class ZendIntegrationPlugin
{
    function __construct()
    {
        // ... previous code ...

        // Disable Lost Password, Retrieve Password, and Password Reset
        add_action('lost_password', array(&$this, 'disable_function'));
        add_action('retrieve_password', array(&$this, 'disable_function'));
        add_action('password_reset', array(&$this, 'disable_function'));

        // Remove Password Fields from the wordpress user profile.
        add_filter('show_password_fields', array(&$this, 'disable_password_fields'));
    }

    /**
     * Used to disable certain display elements, e.g. password
     * fields on profile screen.
     */
    function disable_password_fields($show_password_fields)
    {
        return false;
    }

    /*
     * Used to disable certain login functions, e.g. retrieving a
     * user's password.
     */
    function disable_function()
    {
        die('Disabled');
    }
}

Step 9, WordPress: Autoload the session

This is perhaps the most complex piece of the plugin, because we have to do three things: First, we have to detect whether the authentication states between your Zend application and WordPress match. If they don’t, we have to either create a wordpress session or destroy it. The tricky bit here is that WordPress requires use of its own user database, so we have to retrieve basic information from the Zend User tables and construct a WordPress user should it not already exit.

Unfortunately, I cannot say how your Zend application is built nor what models exist that would allow you to retrieve a user record. As such I’ve inserted pseudocode in the method below that describes what needs to happen rather than make guesses about your implementation.

<?php

class WordPressAuthenticationPlugin
{
    function __construct()
    {
        // ... previous code ...

        add_filter('plugins_loaded', array(&$this, 'auto_login'));
    }

    /**
     * This method runs after the plugins is loaded, and attempts to detect
     * an out-of-sync session.
     */
    public function auto_login()
    {
        $isZendAuthenticated = Zend_Auth::getInstance()->hasIdentity();
        $isWordpressAuthenticated = is_user_logged_in();

        // Check to see if we're logged out of Zend but still logged in to WordPress
        if ( !$isZendAuthenticated && $isWordpressAuthenticated )
        {
            // Log out of WordPress.
            wp_logout();
            wp_clearcookie();
            set_current_user(null);
        }

        // Check to see if we're logged in to Zend but not WordPress
        if ( $isZendAuthenticated && !$isWordpressAuthenticated )
        {
            // Retrieve the user record from Zend
            $yourUserObject = yourUserRetrievalMethod();
            $wordpress_user_id = yourWordpressIdRetrievalMethod($user);

            // Check for the wordpress user ID, create a new user if necessary.
            if ( $wordpress_user_id == NULL )
            {
                // Retrieve the user creation scripts.
                require_once(ABSPATH . WPINC . DIRECTORY_SEPARATOR . 'registration.php');

                // Create a user object, using the hashed password value (It matter doesn't what you use as long as it's unique)
                wp_create_user($yourUserObject->login, $yourUserObject->password, $yourUserObject->email);

                // Check for a successful insert
                $wordpress_user_id = username_exists($login);
                if ( !$user_id )
                {
                    die("Error creating user!");
                }
                else
                {
                    yourWordpressIdUpdateMethod($user, $user_id);
                }
            }

            // Now that we know we have an existing wordpress user record that matches our Zend Table,
            // try to create a wordpress session
            $wpUser = new WP_User($wordpress_user_id, $yourUserObject->login);
            $wpPassword = md5($yourUserObject->password);
            wp_login($yourUserObject->login, $wpPassword, true);
            wp_setcookie($yourUserObject->login, $wpPassword, true);
            wp_set_current_user($wpUser->ID, $yourUserObject->login);
            return;
        }
    }
}

Step 10, WordPress: Enable Login via WordPress

At this point we are maintaining the authenticated session across our applications, but we don’t yet have WordPress authenticating users against our Zend user table. As above, I can’t make assumptions about how your authentication is set up, but I can show you which application hooks to set up, leaving the rest of the logic for you to fill in.

<?php

class WordPressAuthenticationPlugin
{
    function __construct()
    {
        // ... previous code ...

        add_filter('check_password', array(&$this, 'check_password'), 10, 4);
    }

    /**
     * Override Check Password
     */
    public function check_password($check, $password, $hash, $user_id)
    {
        // Retrieve a user by the WordPress User ID. You can use any class in your Zend application.
        $user = findZendUserByWordpressId ( $user_id );

        // Check for a valid return data.
        if ( $user )
        {
            // Try to log in.
            $sessionModel = new WordPress_Model_Session();
            return $sessionModel->create( $user->login, $password );
        }

        return false;
    }
}

Step 11, WordPress: Enable Logout via WordPress

The very last vanity task to perform is to enable logging out via the WordPress buttons. Again we use an action handler, and in this case we explicitly call the Session destroy method we created in Step 5.

<?php

class WordPressAuthenticationPlugin
{
    function __construct()
    {
        // ... previous code ...

        add_action('wp_logout', array(&$this, 'logout'));
    }

    /**
     * Runs Logout routines against the Zend controller.
     */
    public function logout ()
    {
        $sessionModel = new WordPress_Model_Session();
        $sessionModel->destroy();
    }
}

And that’s it. With all these pieces in place your Zend application should now be integrated with your WordPress intall. Congratulations! Now your startup has a fully functional, plugin ready CMS without being tied to a commercial solution for the long term.

To begin with, this session starts where the 5 minute install stops. There are plenty of tutorials out there that will help you set up your own WordPress blog, so I’m not going to bother repeating them. Instead I’m going to start covering topics that you’ll run into when you want to have your WordPress install do more than what it was originally designed to do.

Since the topics covered are very technical in nature, I will also take the time to demystify some of them. In other words, if you’re already a developer in your own right you might not get much out of this presentation, as I will be covering some basic PHP syntax, server redirects as well as an overview of modifying DNS records.

On the other hand, if you are a blogger who’d like to have a good introduction, or are curious about how WordPress might fit into your corporate environment, this will be an excellent overview.

Section 1: One Install, Many Blogs

11:00AM-11:20AM

If you’re an avid blogger and/or maintain more than one WordPress blog, consolidating all of your blogs onto one single WordPress install can help with everything from plugin management to upgrades. Most plugins, however, naturally assume that they exist on a solitary install, so if you want to use something like Google XML Sitemaps there are some additional steps you need to take. As such, this first part will cover the following topics:

1. Writing a Dynamic Configuration File (PHP)
2. Request Redirects with mod_rewrite
3. Configuring plugins for multi-site use

Section 2: WordPress^μ

11:20AM-11:40AM

In many corporate environments it’s often optimal to manage multiple blogs through one single administrative interface, which is where WordPress^μ (Multi-User) comes into play. Installs such as these are often tricky, because they require a bit more technical expertise to get them set up properly. As such, I will be covering the following:

1. A brief feature overview of WordPress^μ
2. Installing WordPress^μ.
3. Redirecting for subfolders (http://www.yourdomain.com/blogname).
4. Redirecting for subdomains (http://blogname.yourdomain.com/ ).
5. Updating CNAME DNS records for subdomains.

If we have time at the end of the session I will open the floor for any additional questions you might have about installation challenges you might have faced. I can’t promise a comprehensive answer to all of them, but between myself and the rest of the room we should be able to get you pointed in the right direction.

Until I read the comment itself, which… well, to put it nicely it was abrasive, insulting, and belittling of my expertise… which man, lemme tell you, is a fantastic marketing strategy for the CEO of a company that sells blogging software. Given that I’d heard good things about Anil Dash I was shocked and surprised, and was about to let it go with a simple rebuttal…

…and then I realized I wasn’t about to let it slide. He said that I hadn’t done my research, so I did it: and here’s what I found, point by point, to everything he said.

Before I go into the meat of it all, let me post a challenge to both Automattic and SixApart: Let the numbers decide who’s better. When all is said and done the way to determine which system is better is best determined by how many signups, users, blogs, posts and comments each of your systems generates over time. I’m no statistician, but I do know a few that are rational and uninvolved in this debate (if a little anal retentive) and would be more than happy to provide a reference to finally settle this argument once and for all. In other words, I’m asking you to put your numbers where your mouth is, and then publish it.

Now, on to the research!

“To be fair, you have to compare the hosted services of TypePad and WordPress.com or the installed software of Movable Type and WordPress.org, or you’re comparing apples and oranges.”

Touche, yet I’d like to point out that you do the very same thing several times in your response.

“A quick glance reveals tons of features that are exclusive to TypePad.”

This is an interesting statement, because from observation TypePad has been copying WordPress for years now (Which I can respect- there’s no shame in copying good ideas). I’ve listed a few features below that have been on WordPress.com far before TypePad ever got around to implementing them.

• Banned words
• Moderation queues
• Spam folders
• Static Pages
• WYSIWYG text editor
• Paging
• Custom headers
• Podcasting
• BlogRolls

“Anybody who’s paying attention to technology at all couldn’t have missed TypePad for iPhone showing up in Steve Jobs’ keynote at Apple’s WWDC at the beginning of this week. But it’s not just that TypePad was first, and best, to bring blogging ot the iPhone, but that there are exclusive clients for the Blackberry, Windows Mobile, Palm, and Nokia phones too.”

Congratulations, you’re standing in the shadow of Steve Jobs. So is every last iPhone addon, Mac Peripheral and iPod knockoff. Trying to bolster your company through secondary affiliations like that indicate that you can’t stand on your own. What really matters here isn’t the number of clients you have available, but the amount of quality content you publish via those clients. Secondly, saying that you’ve got the “best” mobile client is misleading- http://wphoneplugin.org/ is quite effective and many people I know are happy with it. Now, I’d rather claw my eyes out than write something substantive on my iPhone, but then there are those bloggers that get by with twits rather than substance. Can you provide actual comparative numbers proving that your mobile solutions are “better” than someone elses?

“There’s TypePad AntiSpam built-in, which even WordPress users have told us provides better comment spam blocking than Akismet.”

I’m again going to request a citation for this statement, because so far the only information I’ve found comparing the two systems is an article about how TypePad’s spam protection is overly aggressive and unstable, as well as an email stating that your spam protection was actually derived directly from Akismet.

“The only ads on WordPress.com are the ones Automattic puts onto your blog but hides from you if you’re logged in.”

If you are catering to the type of blogger who wants to have ads on their site, then you’re catering to people less interested in providing content and more interested in earning a quick buck. That’s certainly an acceptable business strategy, but not one I would lower myself to.

“You could even have ads for causes or companies you don’t support on your WordPress site.”

Well, of course. Anyone who uses AdSense can do this.

“You’re just plain inaccurate in regards to URLs.”

Really? Oh, goody, lets take a look.

“While Meg hasn’t set up Cute Overload in the way that you’d prefer”

She clearly tried, and if one of your largest blogs can’t figure out how to properly set up canonical permalinks, you’ve got a problem.

it’s absolutely possible to have whatever URLs you want for your site — take a look at Celebrity Babies:

• Root URL: http://www.celebrity-babies.com/
• Article URL: http://www.celebrity-babies.com/2008/06/scott-and-renee.html

You neglect to point out the following link: http://celebritybabies.typepad.com/, and all the subsequently valid links that can be searched for on google. If you want to talk SEO, lets talk about the penalties of double-posted content.

To contrast on WordPress.com, lets take a look at People Magazine. The original stylewatch wordpress account link redirects to the correct URL, and even if you search at the stylewatch.wordpress.com site the links all 301 redirect to the correct server.

Furthermore, TypePad 404′s out if the URL is incomplete or even missing a trailing slash , while on WordPress they can map you to the closest match on a particular URL. In other words, even links that have been cut off because they’re too long are 301 redirected to the correct ones. And lets not talk about the behavior of your trackback URL’s.

Long story short, URL handling in WordPress is superior to TypePad. Moving on…

“I see this mistaken assertion made often enough about TypePad that I have to wonder if someone out there is deliberately misstating what the system can do.”

I have seen several TypePad blogs that properly handle permalinks. Unfortunately, the default instructions provided by Six Apart result in the behavior I’ve listed in my previous post, so it seems that your problem isn’t one of not supporting a particular feature, but one of crappy documentation.

“And TypePad simply blows WordPress.com away on SEO when it comes to search engine indexing: TypePad delivers your blog posts directly to Google Reader and My Yahoo and Blogline.”

Please provide a citation on this one, because last I checked WordPress and practically everyone else out there has a standard notification system via pings and trackbacks which works like a charm. In contrast this notification system of yours seems to be a public ATOM feed, which only works when and if a search engine decides to consume it.

“On WordPress.com, you’re kind of moving into a bad neighborhood — by their own admission, one-third of the blogs on WordPress.com are spam.”

This was a ballsy enough statement that I hunted down the actual numbers from Automattic. Turns out that one-third of their signups are spammers, which are subsequently and effectively axed before damage can occur (Information available for the curious). It’s important to make sure you’re precise in the statements you make- else it starts sounding like spin and hype.

“You seem to know more than enough about SEO to know what that implies.”

Hey look! A compliment! I was feeling like the scum of the earth there for a while….

“On TypePad, you can make a password-protected blog, and share it with as many people as you want to grant access to. On WordPress.com, it’ll cost money if you want to invite more than a certain number of people to have passwords on your site.”

I just tested this, and I had no problem password protecting my blog and giving different users access. I could also do multiple authors, and multiple blogs without being charged a dime, something TypePad will charge you for. Moving on…

“Extensibility? Let’s talk about what normal people who aren’t PHP coders can do.”

This statement’s a little odd, because it automatically posits that a PHP coder could do something. i.e. we’re talking about Movable Type vs. WordPress rather than TypePad here.

Assuming the latter, TypePad has an existing framework by which third party providers can inject their widgets into your blog. I don’t call that extensible, especially when I have to tell my friends to go sign up for a host of other services to get their stuff the way they want it. At that point you’ve given up control of the user experience to the widget provider, which… well, how much do you trust them to stay in line with your UX & UI?

For the former… you mean install any of thousands of plugins? No? How about installing thousands of themes? No? Oh, you mean the ~300-odd plugins, or the piddly number of themes available for Movable Type?

“For self-hosted options, Movable Type is free, open source, and it’s just irresponsible to misrepresent the fact that MT is open source.”

I’d like to point out that you just went on record to say that there’s no difference between the Free Download and the “Movable Type Professional Pack” advertised at $100, which… lets see…”is an add-on for Movable Type 4.1 available exclusively to paid customers”. I for one know you didn’t mean that, but please be careful in the future- I don’t want to be subpoenaed in a class action suit.

“And MT is dramatically more secure than WordPress.org — and that’s according to the Department of Homeland Security’s own statistics.”

You are using misleading statistics in the post you linked. The aggregate data provided by the Department of Homeland Security covers every version of each system and every third party plugin across the better part of a decade, without even taking into account reported vs. actual, fix turnaround, whether it’s third party or core, and the size of the reporting community.

To be truly able to call MT more secure than WP, you will need to do a study on # reported, # valid, # fixed, features and plugins tested and the time it took to resolve a vulnerability. Anything less is FUD, and until you can come up with some serious statistics I’m going to go with the solution that CNN, the NY Times, The Wall Street Journal, Fox News, Reuters, and the Financial Times entrust their blogging to.

“But of course, there’s no MT-MU, and that’s because MT was intelligently designed from its very first release almost seven years ago to support multiple blogs.”

But of course if you want support, pricing starts at $300, and from what I hear it doesn’t scale effectively for more than a couple of thousand users. Actually, here’s an excellent question: Are you powering typepad.com with the openly available version of Movable Type? Because WordPress.com is powered by MU, and if you’re not willing to take your own medicine, you have no right selling it.

“It’s not a separate fork with its own set of plugins and themes.”

98% of WP plugins (that’s thousands) and all WP themes work with MU. Check your sources.

“And it’s not just possible to host blogs for others with it, it’s the sort of thing that’s done on the scale of Major League Baseball offering free MT blogs to anyone who wants one.”

Wait, what? You mean all the news outlets I listed above don’t count as “on the scale of Major League Baseball”? How about WordPress.com? Are you saying that the MLB’s free blogs have more active writers than your competition?

“Sentencing your friend to a blog where he can’t run his own ads and his “upgrade” path is an ordeal of constant security problems that have been described as a “cancer””

Well, hey, the Technorati top 100 have a good WordPress representation, so at least they’ll be in good company in that “Blogger Jail” you’re suggesting. As for upgrading, I know how easy WordPress is, and I know how “easy” updating Perl CGI’s is, and the latter’s a much bigger pain to deal with.

In fact, ever since the WordPress SVN repository went public, my updates are single commandline affairs that I’ve already taught to several clueless bloggers.

“cool stuff like blogging on the iPhone”

http://wphoneplugin.org/

There is a followup post here that goes into quite a bit more detail. If you are interested in this topic I recommend you read both, as well as take the time to go through the comments. There is some excellent back and forth on the benefits and downsides of each.

As someone who manages several blogs, some on TypePad and some on WordPress, I find myself in a rather unique position to comment on both. I won’t lie- I am clearly biased towards the latter, and though my opinion might be colored by that bias I’ve tried to figure out why I feel the way I do. I’ve outlined a few points below on areas where I feel that WordPress is clearly superior to TypePad.

Feature Implementation

If you look at a strict feature list of each system, it seems like while there are a few tradeoffs, the two systems are effectively equivalent. This is not entirely the case- hosting on TypePad gives you a series of admin forms that… well, don’t really feel like admin forms. Figuring out where all the customization settings are is almost as much effort as the customization itself, and no real thought has been put into UX or context. To contrast, the new WordPress UI has clearly received quite a bit of love from people who aren’t developers: The design is clean, management and updating is easy, the help files are easily found and concise, and if a particular feature is implemented it is done so in a way that covers 95% of your use cases. In other words, it’s a much cleaner experience.

URLs

This is perhaps my biggest issue with TypePad, and is best illustrated via the following samples. Please place close attention on the URL’s themselves.

Sample in Typepad

• Root URL: http://www.cuteoverload.com/
• Article URL: http://mfrost.typepad.com/cute_overload/2008/06/rule-of-cutenes.html

Sample in WordPress

• Root URL: http://www.flashenabledblog.com/
• Article URL: http://www.flashenabledblog.com/2008/06/12/tutorial-creating-a-downloader-for-youtube-with-flexair/

For Search Engine Optimization this is a deal breaker – on WordPress, the Search Engine Spiders see all of your articles under your domain. On TypePad, they see a single page linking off to a bunch of pages on typepad.com. In other words, TypePad gets SEO credit for your content. Note that this is a double-edged sword: by having your content on TypePad you get a small automatic SEO boost simply because you’re affiliated with them, yet the tradeoff is that you’re far more likely to get lost in the noise.

User Registration

On WordPress, anyone can register and comment, and they get a handy dashboard once they do. On TypePad this is not the case- even if you’re logged in as a user on TypePad, you will still be prompted to sign in to TypeKey to be able to retain your identity across blogs and comments. On top of that, your registrants will be bombarded with requests to start their own blog, and while my marketing side can appreciate the cross-sell opportunity, the user in me finds it incredibly obnoxious.

Extensibility

This will probably not come into play unless you’re interested in hosting your own blog and/or have a developer mindset (like myself), but WordPress is simply easier to customize. Even if the metric fuckton of extensions and plugins doesn’t suit you (the kitten-a-day plugin is my personal favorite), the fact that the codebase is fully open sourced makes it easy for third party developers to generate their own. In contrast, TypePad itself is really not customizable at all, and Six Apart’s self-hosted solution Movable Type will cost you money. Admittedly, they do have a few plugins that are superior (Piknik for one), but given the ecosystem I expect an enterprising developer will meet and exceed them soon enough.

Upgrading

Sooner or later, you’re going to want to upgrade and leave your hosted solution for your own server. If you’re on Typepad, you will probably be looking at a variety of different solutions, including Movable Type (published by the same people who publish TypePad). If you’re on WordPress, you’ll probably be looking at… WordPress. Movable Type has licensing fees, and while they’ve made strides towards open-sourcing the core of their system they still retain IP control over the real juicy bits. In contrast, WordPress is entirely free, and given that at this level the two systems are functionally equivalent, the upgrade path from WordPress.com to your own installation is much easier, cheaper, and builds on your existing system knowledge so you don’t have to learn everything over again (On top of the UX point I made above).

Furthermore, WordPress has an ace up its sleeve: WordPress Mu. This is the upgrade after the upgrade, where you become the host of other people’s blogs. The install is practically the same, the only difference is that now you’re in charge of the "WordPress.com" equivalent. While competing with them directly might not be the best option, this is an excellent system if you are interested in opening your own office to blogging. Anyone and everyone can create their own blog and retain their own author identity, while at the same time remaining associated with your company. OPENing up your office culture can be a boon in many different ways.