Just you and your thoughts

In 2007, I wrote this about the job of software:

That’s when I know WordPress is doing its job: when people aren’t even aware they’re using it because they’re so busy using it!

I cited that more as a direction, than a goal. If the job of software is to get out of the way, it never completely reaches it — it just gets closer and closer. Sort of how dividing a number in half an infinite number of times never quite gets you to zero.

Today, in 2011, I took this screenshot of the Distraction-Free Writing interface for the upcoming WordPress 3.2:

screenshot of WordPress Distraction Free Writing interface. A title, and a body.

How’s that for getting out of your way?

2010 in review

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

Featured image

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 410,000 times in 2010. If it were an exhibit at The Louvre Museum, it would take 18 days for that many people to see it.

In 2010, there were 15 new posts, growing the total archive of this blog to 171 posts. There were 43 pictures uploaded, taking up a total of 330mb. That’s about 4 pictures per month.

The busiest day of the year was June 25th with 13,614 views. The most popular post that day was New in WordPress 2.9: Post Thumbnail Images.

Where did they come from?

The top referring sites in 2010 were codex.wordpress.org, wordpress.org, WordPress Dashboard, shexperience.com, and slashdot.org.

Some visitors came searching, mostly for wordpress post thumbnail, wordpress thumbnail, wordpress thumbnails, wordpress plugin tutorial, and post thumbnail wordpress.

Attractions in 2010

These are the posts and pages that got the most views in 2010.


New in WordPress 2.9: Post Thumbnail Images December 2009
521 comments and 26 Likes on WordPress.com


WP Tutorial: Your First WP Plugin March 2006
418 comments and 1 Like on WordPress.com,


Why WordPress Themes are Derivative of WordPress July 2010
182 comments and 17 Likes on WordPress.com


WordPress Error: You do not have sufficient permissions to access this page March 2006


WordPress 2.0.3: Nonces June 2006
108 comments and 3 Likes on WordPress.com

Post Formats vs. Custom Post Types

Some people are confused about the Post Formats feature that will be made available to themes in WordPress 3.1, especially how it differs from Custom Post Types.

Custom Post Types

These were poorly named. Think: Custom Content Types. That is, non-post content. Examples: employees, products, attachments, menu items, pages, pets. If you want it to show up in your site’s main RSS feed, then it’s probably not a custom post type.

Post Formats

A Post Format is a formatting designation made to a post. For example, a post could be a short “aside,” or a Kottke.org-style link post, or a video post, or a photo gallery post. The data you input might be slightly different — video post should contain a video, an aside should probably not be very long, a link post should have a link. And the way that the post is displayed on the site might be very different — an aside will typically be displayed without a title, a link post may have the title point to the link. A video post may be wider, or have social sharing buttons auto-appended. But they’re all still posts. They still show up in your feed, and you still find them in the Posts section of the WordPress backend.

The important thing to note about Post Formats is that they are going to be a standardized convention. So any theme that supports Post Formats and follows the standard will display your posts in a way that makes sense. Before, themes had to set up category-based conventions, and these conventions weren’t shared by other themes. This is a better way of handling that, and it should make it even easier to switch between themes than before!

Themers should turn to the Post Formats page in the Codex for info on implementation. Note that we’re not yet in beta, so expect this page to change a bit.

WordPress Q & A: Week of September 27

Ricky asks:

Thanks for your time. I’m working on a site where I’d like members to be able to submit posts, but I’d like to be able to moderate them first before they go live.

Kinda similar to what WP can do for comments, I’d like to do for posts. Is that possible?

Certainly! What you want is to open up registration and make the default role for new users “Contributor” instead of “Subscriber.” Contributors can submit posts for review, but not publish them. They’ll show up as “pending review” in the backend, and will require an Editor or Administrator to publish them. There are even plugins available to facilitate posting from the front end, such as Gravity Forms ($39 and up, GPL).

Allan asks:

I have hit an incredibly frustrating hitch with WP, and that is getting a text file with the content of my posts. I need a single file I can load into page layout software. I know about Blog Booker and Blurb but would like more layout control than those services offer.

If you need this for a bunch of posts on an ongoing basis, I’d create a custom page template and just have it do query_posts('posts_per_page=9999'); (or however many posts you want), and then do a basic loop. Look at a simple theme for inspiration on the template tags… it all depends on how you need it formatted.

Import a Vox blog into WordPress (or almost anything else)

Six Apart is closing the doors on Vox, a blogging service they launched three and a half years ago. You have until September 30th to export your content from Vox, or you’ll lose access to it. Yikes!

They helpfully included a link to WordPress.com’s importer help page. WordPress.com has a Vox importer. What isn’t immediately obvious is that you can use WordPress.com as an intermediary on your way to a final destination. That is, you can import your Vox blog to a temporary WordPress.com blog, and then do an export from WordPress.com. Now you’ll have gold: a WordPress export file. You can take this file and import it into a standalone WordPress site, or a plethora of other blogging tools or services.

I recommend that everyone who has Vox content they want to save do this. Mark your WordPress.com blog as private if you don’t want that to be its final destination — just do it (and soon!) so that you have a copy of your site in a useful and portable format.

Upcoming WordPress Events

On September 8th, I’ll be at the Tampa Bay WordPress meetup to talk about WordPress custom post types. If you’re a WordPress developer or themer in the area, you should stop by! The meetup is at 7pm at CDB’s Southside in South Tampa.

WordCamp Portland is on September 18th and 19th at Webtrends. My talk is called “Swan Dive! …into the Best WordPress of your Life,” and it’s all about using WordPress to its fullest. Everything from hosting to scaling and everything from upgrades to insider ninja moves will be covered.

APC Object Cache Backend for WordPress

I wrote the original APC Object Cache backend for WordPress back in 2006. Shared it via a link on the wp-hackers list, and until a few days ago, hadn’t touched it since.

It has now been updated to version 2.0.1, and should work more efficiently. It supports increment/decrement, and you can now use it to power Batcache, the whole-page caching engine used on WordPress.com! In fact, for single-server sites, it should perform a lot better than Batcache + Memcached (because Memcached is a separate application and connections from PHP have some latency).

If you have no idea what I’m talking about, read on.

WordPress has a built-in object caching API. It is usually used to store complex data objects or HTML structures which are computationally expensive to create on the fly. By default, the engine is implemented in PHP memory. That means that objects don’t persist in-between requests. The only benefit there is if you’re accessing the same objects multiple times on one request.

Enter persistent object cache backends. These backends store the data objects between page loads, which saves your server a lot of time and speeds up the user experience. APC is both an opcode cache (which speeds up PHP in general) and an in-memory key/value store which persists between page loads. If you have it installed (or can install it), I highly recommend that you do so. Unfortunately this probably won’t be available to anyone on shared hosting — VPS/dedicated only. Once you have APC up and running, as confirmed by phpinfo();, install the APC Object Cache in your WordPress content directory. It is a special kind of plugin, and will not work if placed anywhere else. It also needs to keep its name: object-cache.php

You should notice improved page load times! I’ve seen it improve page generation time 10x.

And what about Batcache? Batcache is a whole-page or “HTML output” caching engine. It stores complete web pages and saves them for later. It needs a persistent object cache backend to function. Furthermore, it needs an object cache backend that supports incrementation (counters, to measure how much traffic each URL is getting), and that does its own object expiration. Memcached has fit the bill, and is the preferred solution for multi-web-server WordPress installs. Now with the new version of the APC Object Cache, there is a preferred single server solution as well.

Note: W3 Total Cache users need not apply — it handles its own object caching, including support for APC.

Plugin installer tool

Remember when you had to install WordPress plugins by uploading them manually via FTP? I do. Heck, I remember when there weren’t plugins, and you had to copy and paste PHP code! We’ve come a long way, but I realized the other day that there is one more way that we could improve ease of installation.

Say you’re a plugin author, and you have this great plugin. How do you get people to install it? Well, you could link to its page in the plugin directory, where they’d be prompted to download a zip file. Or you could offer the zip file yourself. But why are we offering plugins the same way we were in 2004? We have a built-in plugin installer. Let’s use that! So how would you do that? I guess you’d just tell people “Hey, go to your wp-admin and search for ‘My Awesome Plugin.'” That introduces a lot of chances for failure. They might even end up with the wrong plugin!

I made a better way, and will be working on integrating this into WordPress.org this summer.

To see it in action, click here. All you have to do is type in the URL of your WordPress blog.

The tool auto-detects the WordPress installation by looking at the X-Pingback header. You’ll be presented with the plugin installation form for your blog. Click “Install Now” and the plugin will be installed. Much easier, and you know they’re getting the correct plugin.

Plugin authors can go here for more info. I’ll make sure these URLs forward to WordPress.org once we get it set up there, so you can start using this now.

Update: It has a bookmarklet now. If you click that bookmarklet from a WordPress Plugin Directory page, it’ll prompt you to install the plugin you were viewing.

Here’s a screencast showing it in action!

WordPress Q & A: Week of July 19th, 2010

Iva asks:

For us who use shared/clustered hosting solutions, there a good and free way to run WordPress 3.0 with a couple of sub-sites using more than one database?

Check out HyperDB. It does exactly this!

Paul asks:

How can someone make sure that their theme is compatible with the latest WordPress version?

I presume Paul is asking this from a user perspective. If your theme is simple, there is only a very small chance that a WordPress upgrade will break it. This rarely happens. Plugins and advanced themes (which behave as plugins) break at a slightly higher (but still very low) rate. This has to do with how well they were coded, for the most part. If the author is using our documented public functions, it is probably fine. If they are making direct queries or using deprecated functions, it might be a problem. You can ask the author this question directly, but it would probably be faster to just throw the theme up on a fresh WordPress install (of the new WP version). For important sites, it doesn’t hurt to have a test site where you test your plugins and themes with new WP versions. That should give you more peace of mind about upgrading.

Kieron asks:

How do I change the number of posts shown in a category? Currently there are 10 but I am using 3 posts in a row so I either want to display 12 or 9 to make it look okay.

The WordPress posts per page setting is global, but plugins can alter it based on the type of page you’re viewing (or any other criterion). The Different Posts per Page plugin looks the ticket! For people looking to do this in code, try this as a base:

function my_custom_posts_per_page( &$q ) {
	if ( $q->is_category )
		$q->set( 'posts_per_page', 12 );
		You can also test things like:
		$q->is_search, $q->is_author, $q->is_year, etc
		Look in the WP_Query class for the full list of variables
		Also note that you can change the ordering!
	return $q;

add_filter('parse_query', 'my_custom_posts_per_page');

Why WordPress Themes are Derivative of WordPress

In the past few days, WordPress has become entangled in a debate about WordPress theme licensing. It was specifically centered around Thesis, one of the last notable proprietary theme holdouts. Chris Pearson, who develops and sells Thesis, refuses to license Thesis under the GNU General Public License that applies to WordPress and all WordPress-derived code.

There are many aspects to the ongoing WordPress vs. Thesis brouhaha. Things like respect, copyright, freedom, GPL, ownership. There is no doubt that Thesis lifted lines of code, and even whole sections of code, directly from WordPress. The Thesis developer who did some of the lifting confessed to it (much to his credit).

Some people have changed their opinion on the matter when they learned of that wholesale code copying. That is, they changed their mind about Thesis specifically. But those revelations happened later in the fray, after Chris Pearson and Matt Mullenweg’s discussion on Mixergy about the matter. It is the position of the WordPress core developers that themes cannot be considered wholly original creations even when they don’t copy large sections of code in from WordPress. Theme code necessarily derives from WordPress and thus must be licensed under the GPL if it is distributed.

What is a WordPress theme?

WordPress themes are a collection of PHP files that are loaded together with WordPress and use WordPress functions and access WordPress core data in order to deliver HTML output. A theme may (and almost always does) include CSS files, JavaScript files, and image files. Note that WordPress theme PHP files are not “templates” or “documents” in the way that most people think of those words (though the word “template” is sometimes used, it is not strictly accurate). They are PHP script files that are parsed and run on the same exact level and by the same PHP process as all the core WordPress files.

Is a theme separate from WordPress?

There is a tendency to think that there are two things: WordPress, and the active theme. But they do not run separately. They run as one cohesive unit. They don’t even run in a sequential order. WordPress starts up, WordPress tells the theme to run its functions and register its hooks and filters, then WordPress runs some queries, then WordPress calls the appropriate theme PHP file, and then the theme hooks into the queried WordPress data and uses WordPress functions to display it, and then WordPress shuts down and finishes the request. On that simple view, it looks like a multi-layered sandwich. But the integration is even more amalgamated than the sandwich analogy suggests.

Here is one important takeaway: themes interact with WordPress (and WordPress with themes) the exact same way that WordPress interacts with itself. Give that a second read, and then we’ll digest.

The same core WordPress functions that themes use are used by WordPress itself. The same action/filter hook system that themes use is used by WordPress itself. Themes can thus disable core WordPress functionality, or modify WordPress core data. Not just take WordPress’ ultimate output and change it, but actually reach into the internals of WordPress and change those values before WordPress is finished working with them. If you were thinking that theme code is a separate work because it is contained in a separate file, also consider that many core WordPress files work the same way. They define functions, they use the WordPress hook system to insert themselves at various places in the code, they perform various functions on their own but also interact with the rest of WordPress, etc. No one would argue that these core files don’t have to be licensed under the GPL — but they operate in the same way that themes do!

It isn’t correct to think of WordPress and a theme as separate entities. As far as the code is concerned, they form one functional unit. The theme code doesn’t sit “on top of” WordPress. It is within it, in multiple different places, with multiple interdependencies. This forms a web of shared data structures and code all contained within a shared memory space. If you followed the code execution for Thesis as it jumped between WordPress core code and Thesis-specific code, you’d get a headache, because you’d be jumping back and forth literally hundreds of times. But that is an artificial distinction that you’d only be aware of based on which file contained a particular function. To the PHP parser, it is all one and the same. There isn’t WordPress core code and theme code. There is merely the resulting product, which parses as one code entity.

But it’s still in separate files!

I don’t think that matters. Linux Kernel Modules likewise are in separate files, but they’re considered by most to be derivative. If that argument doesn’t convince you, then note that the vast majority of themes derive from the original WordPress core themes. How they load different PHP subfiles, loop through posts, and get and interact with WordPress data is all covered by the original WordPress core themes, which are explicitly GPL. But I don’t think we need to resort to that argument, because of the way that themes combine with WordPress to form a modified work.


WordPress has many external APIs that spit out data. Interacting with these APIs does not put your code on the same level as core WordPress code. These APIs include Atom, RSS, AtomPub, and XML-RPC. Something that interacts with these APIs sits entirely outside of WordPress. Google Reader doesn’t become part of WordPress by accessing your feed, and MarsEdit doesn’t become part of WordPress when you use it to publish a post on your WordPress blog. These are separate applications, running separately, on separate codebases. All they are doing is communicating. Applications that interact with WordPress this way are separate works, and the author can license them in any way they have authority to do so.

This is a wholly different model of interaction than with themes. Themes are not standalone applications. They are scripts that become part of WordPress itself, and interact with WordPress on the same level that WordPress interacts with itself.

Not just our opinion

Drupal and Joomla, both GPL PHP web publishing applications, have come to the same conclusion. To quote from Drupal:

Drupal modules and themes are a derivative work of Drupal. If you distribute them, you must do so under the terms of the GPL version 2 or later.

The Software Freedom Law Center did a specific analysis of the WordPress theme system and determined that WordPress theme code must inherit the GPL.

The PHP elements, taken together, are clearly derivative of WordPress code. The template is loaded via the include() function. Its contents are combined with the WordPress code in memory to be processed by PHP along with (and completely indistinguishable from) the rest of WordPress. The PHP code consists largely of calls to WordPress functions and sparse, minimal logic to control which WordPress functions are accessed and how many times they will be called. They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call. As works of authorship, they are designed only to be combined with WordPress into a larger work.

This is also the interpretation of the Free Software Foundation, which wrote the GPL. Here is what the FSF has to say in the GPL v2 FAQ. They wrote the license, so you should consider carefully what they have to say when trying to determine the spirit of the GPL:

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

The bolded part is how themes work in WordPress. The fact that themes don’t come bundled with WordPress is merely a result of WordPress’ flexible plugin/theme architecture and how non-compiled scripting languages like PHP work. The PHP opcode is compiled on the fly, so you can distribute portions of a WP+Plugins+Theme application piece by piece, and they’ll dynamically combine into one application.


What about making money?

The GPL does not prohibit developers from charging for their code! The overwhelming majority of premium theme developers sell their themes under the GPL (and are making quite a lot of money doing it).

My JS/CSS/Images are 100% original. Do they have to be GPL?

No, they don’t. If they aren’t based on GPL’d JavaScript, CSS, or images, you are not forced to make them GPL. What you could do is offer a theme under a split license. The PHP would be under the GPL, but other static resources could be under some other license.

Won’t people just take my theme without paying for it?

You don’t have to offer it as an open download to everyone. You can put it behind a  pay wall. With regards to people getting it from a friend, or a torrent site, etc — this would happen even with a proprietary license. Do a Google search for “{proprietary theme name} torrent download” and you’ll see what I mean. What people are not able to get without paying is your support. This is a huge part of why people pay for premium themes — they have a knowledgable resource to call on if something goes wrong. That’s something that is irreplaceable, because no one knows the theme better than you do!

What about a developer license?

Theme PHP code must be GPL. You could do a split license on the CSS and JS and other non-GPL static resources. You can license those elements to one site, but let people with a developer license use them on multiple sites. Or, you could have an affiliate program that is only open to people with a developer license. You could seed betas to developers early. You could offer an exclusive developer forum. You could offer enhanced support. There are tons of possible models. The only thing you can’t do is restrict how people can use the GPL-derivative code.

Does this mean that the custom theme I developed for a client is GPL?

No. The GPL is triggered by distribution. Work-for-hire for a client is not distribution. In this case, they would have the copyright on the code. Distributing it would be up to them. As long as they didn’t distribute it, the GPL wouldn’t kick in. Your clients needn’t worry.

Can my employees take my custom theme and distribute it?

No, allowing access to GPL’d code by an employee is not distribution, and the company would have the copyright on the code. A company is considered one entity, so transferring the theme within that entity is not distribution.

What about plugins?

Everything in here applies to plugins as well as themes. The only difference between the two is that you generally have one theme active, but might have multiple plugins active. As far as interactions with WordPress go, they work the same way.


Theme code combines with WordPress code in a way that makes them one functional unit. This is what makes WordPress themes so powerful and flexible. Themes cannot stand by themselves, and are dependent on deeply integrating their code with WordPress core code in order to function at all. They cannot reasonably be considered original works. As such, theme PHP code (and any CSS/JS code that is derived from GPL’d code) must be licensed under the GPL if it is distributed.

If you refuse to abide by that licensing requirement, you forfeit your right to distribute WordPress extensions (themes or plugins). WordPress is copyrighted. If you do not accept WordPress’ license, you still have to respect our copyright. There are other platforms that do not have this licensing restriction (Drupal, Joomla, Movable Type Open Source, and Textpattern are all GPL, so you’d have the same issue with them).


Please remember that this is about copyright and respecting the license that the WordPress copyright holders have chosen. It isn’t about money. Premium themes are fine. It is non-GPL themes (a.k.a. proprietary themes) that are the issue. Also realize that WordPress cannot change its license. It is forever locked to the GPL (version 2). Arguments along the lines of “WordPress should allow proprietary themes because of X,” are pointless. We are as much bound by the license as theme developers!

WordPress Q & A: Week of July 5th, 2010

Brad asks:

What’s the optimal way to store large amounts of meta data for a taxonomy without creating a custom table in WordPress?

WordPress has meta tables for the site (options table), posts, comments and users. It lacks a table for meta data about taxonomies (categories, tags, custom taxonomies). Solutions for this aren’t going to be simple, but I can think of a solution that doesn’t create extra tables. You could create a “shadow” entry in the posts table for each term, using a custom post type (say, “taxonomy-meta”). Then, just attach meta key/value pairs to that post entry.

As for linking the post proxy entry to its corresponding term, you could use the taxonomy system to place that term within that taxonomy, but it would probably be much faster to appropriate one of the existing fields, since this is a one-to-one relationship. I’d probably use post_name and make it something like taxonomy-meta-term-{$term_id}. That way, it’d be fairly straightforward to grab the proxy object that corresponded to a particular term.

I’d create four API functions. One backend function to get the post ID of the proxy object corresponding to a particular term. A backend function to create a proxy object for a term if it doesn’t exist. And then one to update taxonomy meta, and one to get taxonomy meta.

It sounds complicated, but it shouldn’t be more than 30-40 lines of code. And your API would be simple. Share the code if you end up doing this!

“K. K.” asks:

Can you explain how to become a core WordPress developer like you?

WordPress is a meritocracy, so to get the “props” you have to show your worth and put in the time. Start by lurking in Trac and seeing how we develop. Observe the weekly WordPress meetings in #wordpress-dev on Freenode. Then, when you feel confident, start submitting patches to Trac on tickets that need them. Or test the patches that are up there. Follow the tickets and respond to feedback. People who consistently provide quality patches and who seem to “get” the WordPress principles (e.g. options are bad, keep core light, target the 80% need, etc) will rise fairly quickly in prominence.

Ted asks:

Are there any plans to incorporate Facebook connect or any of the other 3rd-party authentication mechanisms into WordPress? If not, are there any FB connect plugins you’d recommend — ideally ones that work for both WP and BuddyPress?

Facebook Connect — no. We might consider third party mechanisms like OpenID+OAuth, but they’re not on the short-term roadmap. The most popular Facebook Connect plugin seems to be WP-FacebookConnect, written by a Facebook dev Simple Facebook Connect.