Interestingly, despite the hundreds (thousands?) of people doing the 5k, “our part” was still five kilometers long. You’d think we could have split it up better or something.

With some restructuring, though, we might be able to cut down on the number of bytes of code we load on every page (and we could get rid of some class_exists() and require_once calls).

We’d want an autoloader, though, that could handle plugin files as well as core files.

Idea: an autoloader that can load classes from some deterministic path (e.g., the usual $classname.class.php or what have you) but that can also register classes at specific paths.

if ( !defined( 'WP_AUTOLOAD_CLASSES' ) ) {
    define(
        'WP_AUTOLOAD_CLASSES',
        function_exists( 'spl_autoload_register' )
    );
}

if ( WP_AUTOLOAD_CLASSES ) {
   /**
<ul>
  <li>PHP 5.1.2+</li>
<li>Called once per class during setup (each time</li>
<li>with two args) to tell it where the class is</li>
<li>located.</li>
<li>Don't need to call for a class if that class</li>
<li>exists in some easy deterministic path.</li>
<li>Called (with only one arg) when looking for a</li>
<li>not-currently-loaded class.</li>
<li>/</li>
</ul>

    function wp_autoload( $class, $path = null ) {
        static $classes = array();

        // Being called by PHP's autoloader
        if ( is_null( $path ) ) {
            if ( isset( $classes[$class] ) ) {
               /* Use include, not require.  That
<ul>
  <li>way we get a more meaningful</li>
<li>Fatal error: class does not exist</li>
<li>/</li>
</ul>

                include( $classes[$class] );
            } else {
               /* Look in some default path(s) for
<ul>
  <li>appropriately named files.</li>
<li>/</li>
</ul>

            }
            return;
        }

        // Being called by us
        $classes[$class] = $path;
    }
    
    // Register it
    spl_autoload_register( 'wp_autoload' );
} else {
   /**
<ul>
  <li>PHP 4 (PHP 5.1.1-)</li>
<li>Just require each file.</li>
<li>/</li>
</ul>

    function wp_autoload( $class, $path ) {
        require_once( $path );
    }
}

// Core classes in WPINC probably wouldn't have
// to be explicitly registered, but as an example:
wp_autoload(
    'WP_Error',
    ABSPATH . WPINC . '/classes.php'
);
// OK to call multiple times per path
wp_autoload(
    'Walker',
    ABSPATH . WPINC . '/classes.php'
);
// ...

// In some plugin file
wp_autoload(
    'My_Plugin_Foo',
    plugin_dir_path( __FILE__ ) . 'foo.class.php'
);

Update: To clarify, I don’t mean to imply that this idea would improve WordPress performance. It’s just an idea, not a proposal. I haven’t done any benchmarking or even naive experimentation.

Conditionally including files involves tradeoffs that need to be evaluated per app. Also, as Jacob Santos points out in the comments below, conditionally including files from conditionally defined functions is way out there.

I might call the idea clever, but it’s not necessarily good

WordPress should store a history of all your posts. You’d get protection from accidental changes, and you’d be able to see a clear timeline of the evolution of each of you posts.

Happily, WordPress is awesome! In the upcoming WordPress 2.6 release, the feature exists and rules!

And check out the pretty colors!

First, the interface changes. In Manage -> Posts you can currently look for posts by search term, or browse by month or category, but only one of these things at a time.

In WordPress 2.3 (or currently on WordPress.com), you’ll be able to filter by search term, post type (draft, private, scheduled for future publishing, or published), author, month published, and category. You’ll also be able to combine any or all of those filters and do them all at once:

so you’ll be able to ask for all published posts written by Lion-O during May of 2007, filed in the “cartoons from the eighties” category, and matching the phrase “Mumm-Ra, the Ever-Living”. That was a hard list of posts to come by until 2.3.

Manage -> Pages will be getting a similar face lift; you’ll be able to filter by search term, author and page type (draft, private, or published).

Better draft management, in particular, has consistently been one of the most frequently requested improvements in WordPress, and these changes are a big piece of that.

Neat huh?

Secondly, the back end changes. The WP_Query class can now select posts by post_status (draft, future, private, publish). This makes it trivial to use query_posts() and wp() for such queries; no more need for kludgey filters and hacks.

WordPress 2.3 comin’, at you soon. Be there!

A while ago, I revamped WordPress’ inline uploading functionality to be more pluggable, cacheable, maintainable and (hopefully) intuitive. A hundred bugs later, it seems to be working pretty well.

This time around, the issue was not how WP displayed the data, but how it stores it.

In trying to make things leaner and meaner on WordPress.com, we reworked some of the behind-the-scenes directory structures on our servers. This should have been totally transparent to the user, but, of course, it wasn’t. It broke our image handling.

Each file uploaded to WordPress is stored as a special type of post called an “attachment”. In the post and postmeta tables, WordPress stores things like file URL, file path on the server, image dimensions, image thumbnail info, etc. So to figure out anything we want about an uploaded file, all we have to do is essentially get_post() and a few get_post_meta()s. Sounds great.

It’s not.

Two reasons:

1. To answer a question like “Where is this file located on the server”, we have to get_post_meta() every time for the answer. With such a generic function, it’s impossible for plugins to filter that data on the fly even for this really simple question.
2. WordPress stores the data in a really inconvenient way; everything is absolute: paths, urls, you name it.

Because of the absolute paths, lack of API, and the aforementioned directory restructuring, we had hardcoded into our DB tens of thousands (a blind guess) of incorrect file locations and no way to filter them. Doing DB updates across hundreds of thousands of tables (not a blind guess) replicated on dozens of servers was not an option.

Partial solution (now implemented in WordPress core): Write a basic API for getting and putting the data. wp_get_attachment_metadata(), wp_update_attachment_metadata(), get_attached_file(), update_attached_file() (the lack of parallelism between function names, and the ambiguity in those names is an historical artifact) are all nicely filterable.

Improvements that still could be made: Don’t store absolute data. This is better for portability too. (Exceptition: guid – but don’t use it for the URL).

Related improvements that could be made:

• wp_get_attachment_url()
• wp_get_thumbnail_file()
• wp_get_thumbnail_url()
• wp_attachment_is_image()
• wp_mime_type_icon()
• Rework get_attachment_icon() given the above
• Kill reliance on or rework get_attachment_innerHTML() (see above)

Vaguely related improvements that could be made:

• wp_handle_upload() is a little awkward (but nice and robust!). Maybe wrap it? That might be silly.
• wp_generate_thumbnail_filename()
• Make thumbnail creation hookable and provide above convenience function

Update: All of the “related improvements” noted above have been made in the recently released WordPress 2.1. Of the “vaguely related improvements” suggested, 2.1 offers hookable thumbnail creation.

We’re still working on the best user interface, particularly for posting new posts. Firas mentioned the possibility of including a cute spinner à la Technorati. Perhaps a spinner over the post textbox would be best. Something like Owen‘s CanaryComment.

Go forth and multiply.

Update: The news keeps on spreading. And if auctions aren’t your thing, try a guessing game!

We’ll need to add some more info into the DB to handle this. topicmeta can handle the number of deleted and bozoed posts, but where to put the number of sticky topics or the number of no-replied, untagged or unresolved topics? Those last queries could use a little benchmarking; maybe we can get away with grabbing them dynamically. But for stickies… would forummeta be useful anywhere else?

Well, it all seems to be square now. Rock on WordPress.com. Rock on.