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?

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.

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.

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.

On APIs

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.

FAQs

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.

Conclusion

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).

Discussion

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!