Ryan Boren » WordPress

WordPress 10th Anniversary Moleskine

Ryan Boren — Mon, 17 Jun 2013 18:52:49 +0000

My very spiffy WordPress 10th anniversary Moleskine just arrived. Time to leave some marks.

Rdio and Spotify oEmbed Support in WordPress 3.6

Ryan Boren — Fri, 03 May 2013 12:50:59 +0000

In an effort to make the new Audio Post Format UI more useful, we added Rdio and Spotify to the default oEmbed providers list for WordPress 3.6. Spotify and @nicklas2k were kind enough to whip up an oEmbed endpoint for us to use. Thanks!

@nacin @Spotify @WordPress Here you go, embed.spotify.com/oembed/?url=ht…—
Nicklas Söderlind (@nicklas2k) May 02, 2013

To celebrate, here are a couple of albums released in 2013 that I’m enjoying.

I’m dogfooding the Post Formats feature of the

Ryan Boren — Wed, 01 May 2013 18:21:22 +0000

I’m dogfooding the Post Formats feature of the upcoming WordPress 3.6 release, so expect more frequent posting here for awhile. Expect also some things I don’t usually post such as quotes, chats, links, asides, and short status updates like this one.

WordPress Theme Licensing

Ryan Boren — Thu, 15 Jul 2010 18:47:09 +0000

The WordPress community is currently having a big debate over whether themes are considered derivative works of WordPress as per the GPL, the license used by WP. The SFLC has previously declared that they consider the PHP code in WP themes a derivative work. Other open source CMS software makers, such as Drupal, also consider themes derivative. Drew Blas has a thoughtful post where he compares WP themes to Linux applications and likens declaring themes as derivative the equivalent of declaring Linux applications as derivative. I left a few comments on his post noting that a more apt comparison is with Linux Kernel Modules (LKMs) rather than applications running on top of Linux. Linux applications are more comparable to XML-RPC clients that use WP’s XML-RPC API. Neither Linux applications nor XML-RPC clients are considered derivative. LKMs, however, are considered by many Linux developers to be derivative works. LKMs load directly into the running kernel and have direct access to internal data structures and APIs. WP themes are the same way. They load directly into WP and have access to WP internals. The distinction between the different classes of interactions is important when discussing the letter of the GPL as well as the general spirit in which many authors of open source software regard modules, themes, and plugins that extend their works.

I’ve not followed Linux kernel development closely for the past few years, but as far as I know the debate over LKMs never definitively resolved itself. A system was put in place where LKMs could declare their license using a MODULE_LICENSE macro. Licenses that are not GPL-compatible “taint” the kernel. Many Linux developers will not assist with tainted kernels. I doubt we would do something similar with WordPress. Many WP developers already refuse to help with proprietary themes. Adding some API doesn’t help clarify anything. Unfortunately, the only thing that would is a lawsuit that goes the distance.

So, where do I stand as one of the primary copyright holders of WordPress? I’d like to see the PHP parts of themes retain the GPL. Aside from preserving the spirit of WordPress, respecting the open source ecosystem in which it thrives, and avoiding questionable legal ground, retaining the GPL is practical. As Drew Blas notes, the theme that sparked this debate copies WP code. Most themes copy WP code. Unlike the argument that all themes are derivative by nature, there is little debate that themes that copy code should retain the GPL. Going out of your way to create a theme that does not borrow a single line of code from the WP community is wasted effort. As attested by several theme makers who license under the GPL, the license has no affect on business. Why generate ill will by using a proprietary license? What value is there in that? Unlike LKMs, WP themes do not have to deal with hardware NDAs and DRM, closed source third-party code, or any of the other legal hassles that sometimes force an LKM to be closed source. Themes live in the world of the fully open source web stack. Since you are still free to license the CSS and images in your themes as you see fit, challenging the WP community over the license of the PHP code seems like bad business.

2.8 Plugin Compatibility

Ryan Boren — Mon, 22 Jun 2009 17:54:23 +0000

Some plugins are causing grief for those upgrading to 2.8.

HyperDB needs to be updated to the latest version, otherwise tags won’t save.
DB Cache also prevents tags from being saved. I haven’t seen an update for it yet.
Plugins that load old versions of jQuery for all admin pages will break all kinds of stuff. Plugins should use the version of jQuery that ships with WP. If a plugin must use a particular version of jQuery, that version should be queued only for the plugin’s own pages.
Themes that call get_categories() from functions.php before the init action fires will fail. 2.8.1 will workaround this, but ideally these themes should update so that they can handle custom taxonomies properly.

Auto Upgrading to Nightly Builds

Ryan Boren — Thu, 18 Jun 2009 20:05:01 +0000

WP’s automatic upgrade can be used to automatically upgrade to betas and nightly builds for the development branch or the latest stable branch. To get onto a development upgrade path you must first make a small change to wp-includes/version.php.

The current release of WP is 2.8. If you peek in the version.php file, you will see this:

$wp_version = '2.8';

If you would like to try out the latest development builds for the upcoming 2.8.1 release, change that line to this:

$wp_version = '2.8.1-dev';

“dev” can be any string. The presence of a suffix on the version tells the automatic upgrade to put you on the upgrade path for 2.8.1 development releases. You will be able to automatically upgrade to each nightly, beta, and RC build for 2.8.1. Once the final 2.8.1 release comes out, automatic upgrade will upgrade you to that official release and put you back on the stable release path. To get back on the 2.8 development branch upgrade path after the release of 2.8.1, you would have to change your version to “2.8.2-dev”.

If you are feeling really experimental, you can get on the 2.9 development path by setting the version to “2.9-dev”. Unlike the 2.8 development path which contains only fixes to high-impact bugs, the 2.9 path is where new feature development is happening. You probably want the 2.9 path only if you are a developer.

Update: Peter wrote a plugin that makes this easier.

WordPress Bits

Ryan Boren — Tue, 17 Feb 2009 18:10:20 +0000

2.7.1 is out, improving upon a solid 2.7 release.

The next version of the iPhone app is almost out and features comment moderation.

2.8 is well underway. So far there have been lots of script loading and DB performance improvements. The first cut of the theme installer is in, and the redesign of the Widgets admin UI is beginning. Custom tag taxonomies now have some built-in admin UI, and proper timezone and DST support is available if you are running PHP 5.

WordPress 2.7.1 Beta 1

Ryan Boren — Tue, 03 Feb 2009 18:24:15 +0000

2.7.1, the first 2.7 maintenance release, is almost ready. So far, 66 tickets are fixed in 2.7.1. There are another 50 tickets open against the 2.7.1 milestone, but most of those will be moved to 2.7.2 or 2.8. If there are tickets in that list you would really like to see fixed in 2.7.1, drop a comment.

To automatically upgrade from 2.7 to 2.7.1 Beta 1, change the version in your wp-includes/version.php file from 2.7 to 2.7.1-beta and then visit Tools->Upgrade. Otherwise, download the beta package and install manually.

Following 2.7.1

Ryan Boren — Fri, 12 Dec 2008 21:30:39 +0000

A major release segues right into bug fixing for the first maintenance release. You can follow what is being fixed for 2.7.1 here. So far there are five small fixes.

100,000 in 20

Ryan Boren — Thu, 11 Dec 2008 23:11:40 +0000

100,000 downloads of WordPress 2.7 in 20 hours, and the pace is picking up.