Tag: coding

jQuery – Why U No Enqueued?
This is a followup to my how to get your plugin in the WordPress repository post.

While code isn’t outright rejected for being ‘bad’ code (only security holes and guideline violations), a lot of plugins are doing the easy things wrong. These plugins will get approved, but they won’t work with all setups, they’re more likely to have issues with Multisite, and they’re just not thinking forward. They aim to solve a, singular, problem, without looking beyond. Primarily I see this when people are trying to bring in some js code into their plugin. Heavens knows I do it, and I’ve done it wrong too. But as I see more and more plugins, I’m starting to get better and better at knowing what’s wrong when I see it.(“I know it when I see it” thanks to United States Supreme Court Justice Potter Stewart)

The easiest way to show you is to give you some really bad examples and go through some of the steps to fix it. The best part is that I’m actually going to use real plugins I’ve seen. Only the name has been changed to protect the innocent.

Ready? Here’s what we’re doing wrong.

Not using functions to define locations

The very bad code:
```
echo '<script src="/wp-content/plugins/myplugin/myscript.js"></script>';
```
I wish this was something I made up. Worse, I’ve see it more than once. Recently.

This install is assuming WordPress is installed in the root of your HTML folder (i.e. domain.com). This is not always the case, as many people install WordPress in subfolders. We’ll need to fix that first with home_url().
```
echo '<script src="'.home_url('wp-content/plugins/myplugin/myscript.js').'"></script>';
```
Now it’s a little better, as by using home_url() we’re letting WordPress define where ‘home’ is. Great! This has two pretty obvious problems, however. First, if I have WordPress installed in a folder, like /public_html/wordpress/, but I’m running it out of the main domain by giving it its own directory, this won’t work. Your code would point to http://example.com/wp-content… when mine is in http://example.com/wordpress/wp-content.. instead! The ‘easy’ fix is to change home_url() for site_url(), but what if I’m not using wp-content? You didn’t know we could Move wp-content? We can. So let’s address that.
```
echo '<script src="'.content_url('plugins/myplugin/myscript.js').'"></script>';
```
By using functions to determine plugin and content directories, we can make this much more flexible. That works, but it could be better. What if we didn’t have to define the plugins or myplugin folders? We could just do something simple like this.
```
echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';
```
Now we have a simple, flexible, functional script embed of js. Except there’s one, minor problem. We’re not including the script correctly.

Not enqueuing files

This isn’t ‘wrong’ really. I mean, if I put this in my plugin, it would echo out the script, and that’s what I want, right?
```
echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';
```
But let’s say I want to put it in my header:
```
function my_scripts_method() {
    echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';
}
add_action('wp_head', 'my_scripts_method');
```
And now I want to include my CSS so it looks pretty:
```
function my_scripts_method() {
    echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';
    echo '<link rel="stylesheet" type="text/css" href="'.plugins_url('myscript.js',__FILE__).'" media="all" />';
}
add_action('wp_head', 'my_scripts_method');
```
Oh, wait, no, I wanted my JS in the footer:
```
function my_scripts_method_foot() {
    echo '<script src="'.plugins_url('myscript.js',__FILE__).'"></script>';
}
function my_scripts_method_head() {
    echo '<link rel="stylesheet" type="text/css" href="'.plugins_url('myscript.js',__FILE__).'" media="all" />';
}
add_action('wp_head', 'my_scripts_method_head');
add_action('wp_footer', 'my_scripts_method_foot');
```
And really, this will work. But it’s not efficient, I’ve got extra actions, and I’m not considering any jquery dependencies anymore. By using wp_enqueue_script is better. Weblog Tools Collection did a series on how to properly add scripts (note that it’s a bit out of date with the use of WP-CONTENT constants). From that we can extrapolate to use just this to include our js and css:
```
function my_scripts_method() {
    wp_enqueue_script('my_script', plugins_url('myscript.js',__FILE__) );
    wp_enqueue_style('my_script', plugins_url('myscript.css',__FILE__) );
}
add_action('wp_enqueue_scripts', 'my_scripts_method');
```
What enqueue does is put your code in the best possible location and can be extended to load dependencies. wp_enque_scripts has a lot of power, and because it’s a WordPress function, it’s got options that make it more flexible. Like when I look at my above code, I remember, oops! I wanted to run my js out of the footer! Not a problem. Look at my options.
```
wp_enqueue_script('handle', 'source', 'dependencies', 'version', 'in_footer');
```
The ‘handle’ is what I want to name my script, it should be unique. If I register my script, I can call the handle over and over again. We’re using my_script right now. The ‘source’ is where my file is located. We’re lifting that from our other code, the bad code, because it works. Your ‘dependencies’ are the other js files yours needs to function. If I put in array('jquery', 'scriptaculous') then both jQuery and Scriptaculous would get loaded before my script. Curiously, you don’t actually need the ‘version’ option, as you can leave it blank and WordPress will automatically add a version number equal to the current version of WordPress you are running. So every time you upgrade WP, it will get updated and force a re-download. This is good, since if you have dependencies to scripts included in WordPress, and they change with a new version (which is the only way they can change), then you get updated too. Finally we have the value I was looking for, ‘in_footer.’ Leave it blank and it’s in the header, put in true and it’s not.

This makes my code:
```
function my_scripts_method() {
    wp_enqueue_script('my_script', plugins_url('myscript.js',__FILE__), '','', true ););
    wp_enqueue_style('my_script', plugins_url('myscript.css',__FILE__) );
}
add_action('wp_enqueue_scripts', 'my_scripts_method');
```
Yeah, isn’t that a lot easier?

Using a different jQuery

This last one I’m going to touch on today is the exact code I saw, in the wild, and it’s got two of my three buggaboos in it.
```
wp_enqueue_script('jquery-1.4.3.min.js', '/wp-content/plugins/myplugin/js/jquery-1.4.3.min.js');
```
Okay. You already know the right way to call the script, so we’ll edit that into something more flexible.
```
wp_enqueue_script('jquery-1.4.3.min.js', plugins_url('js/jquery-1.4.3.min.js',__FILE__) );
```
That should be okay, but it’s totally not.

Most importantly here, we’re calling jquery, which is actually built in to WordPress. Now, we’re calling it by a different handle, but that’s no guarantee that it won’t cause conflicts. In fact, I’m pretty sure this will cause no end of problems with some plugins. The right thing to do would be this:
```
function my_scripts_method() {
    wp_deregister_script( 'jquery' );
    wp_register_script( 'jquery', plugins_url('js/jquery-1.4.3.min.js',__FILE__) );
    wp_enqueue_script( 'jquery' );
}
add_action('wp_enqueue_scripts', 'my_scripts_method');
```
Now we’re making sure we won’t have conflicts by re-registering jquery, replacing it, and moving on.

A lot of people would actually recommend using Google instead, as it takes the responsibility off you for including a file you don’t ‘control.’ Also it makes your plugin smaller and load faster.
```
function my_scripts_method() {
    wp_deregister_script( 'jquery' );
    wp_register_script( 'jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js' );
    wp_enqueue_script( 'jquery' );
}
add_action('wp_enqueue_scripts', 'my_scripts_method');
```
Great! Now we’re done, right? Wrong. As of this writing, WordPress is using jQuery 1.7.2. Now I couldn’t come up with a reason to include an old version of jQuery in WordPress (newer, yes, older, no), so I asked around and none of my friends could either. Using an older version is more likely to cause issues with newer code included in WordPress, as well as plugins which are upgraded to take advantage of the new features. You’re shooting yourself in the foot. The only thing you might be using this for is to include deprecated fictions, and really you need to update your code to fix that instead.

If the whole point is to load the scripts from Google, though, there’s an awesome plugin for that.
14 May, 2012
I Make Plugins CPT
Mark Jaquith makes plugins. He also makes a plugin about making plugins, called I Make Plugins, which auto-formats your ‘local’ plugin pages, so you don’t have to write anything, and just pull in the WordPress repository readme for your plugin. It’s almost like the Victor/Victoria of plugins. Anyway, my issue was I don’t use pages for my plugin listing, I use CPTs. And in order to use Mark’s plugin, I had to hack it.

So I did the smart thing, and emailed him with an “I love your plugin! Here’s what I had to change to make it work with a CPT, though.” A couple days later, Mark replied with “Use these filters instead. Untested!” He also bailed me out when I screwed it up, so he gets an Internet today.

Even though I’ve never actually messed with filters in this way (actions yes, filters I’m still learning), I sat down with my coffee and started reading. Yes, I actually read things before I jump in, contrary to what my friends think.

This turned out to be pretty simple, when you got around to it. Since Mark called apply_filters(NAME,PARAMS), all I had to do was add_filter(NAME,MYFUNCTION) and then make a function, passing the PARAMS and parsing as I needed. Mark fixed my original code (which was hellishly not optimized) and fixed my weird preview issue by returning an option I forgot.

Post Type
First I had to set the post type. In this case, Mark defaults to pages, I default to plugins. Yes, I named a post type ‘plugins.’ It works.
```
add_filter( 'i-make-plugins__post_type', 'halfelf_imp_posttype' );
function halfelf_imp_posttype() {
	return 'plugins';
}
```
This takes in the arguments as $args, resets it to plugins, and returns the new value.

Get Plugins
Mark also has a ‘post parent’ so where I just use the CPT’s archive page for https://halfelf.org/plugins, he has an actual page with sub-pages. I don’t need post parent, so per Mark’s suggestion, I need to remove it from ‘get plugins.’
```
add_filter( 'i-make-plugins__get_plugins', 'halfelf_imp_getplugins' );
function halfelf_imp_getplugins( $options ) {
	unset( $options['post_parent'] );
	return $options;
}
```
Since the parameters I’m pulling in are an array, I have to use unset instead of making it a null value.

Is Plugin
The last check is to verify this is a plugin, and we can return the content. The normal string for this checks if the parent of the page is the ‘page parent’ (set earlier normally, unset by me). I just swapped it for a ‘is this a plugin?’ There are two parameters in this one, and the second is the post ID, which I need to check post type.
```
add_filter ('i-make-plugins__is_plugin', 'halfelf_imp_isplugin', 10, 2);
function halfelf_imp_isplugin( $is_plugin, $post ) {
	$post = get_post( $post );
	return $post->post_type === 'plugins';
}
```
Originally I had a call to is_preview() because, for some reason, it was overwriting all my post previews. While that only annoys me, it really annoys me! Thankfully once Mark fixed my ‘Get Plugins’ call, it all started working.
5 May, 2012
Fork With Restraint

I love that the GPL lets you fork. In fact, two of my plugins are forks and one’s an adoption. I think that’s one of the best things about GPL, the freedom to adapt and move on. But every single time you fork a plugin, you cause a couple problems that many people are either ignorant of or just don’t care about.

Confusion

If you look up ‘WP Grins’ there are three plugins. ‘WP Grins’ is the original, ‘WP Grins Lite’ is the first fork, and ‘WP Grins SSL’ is the third. Each one is pretty explanatory. The plugins are similar, but you get the idea from the title what’s different. And in each case, each forker took the time to say ‘this is what’s different’ in obvious ways, and to credit those who came before. This is important because, based on name alone, there’s not a whole lot to differentiate the plugins.

Multiple ‘things’ with the same name is confusing. That’s really very obvious isn’t it? That’s why companies spend hours and months fighting to protect their trademarked names. The name of a ‘thing’ is important, and the difference between the names is the crux of everything. In a predominantly text world, your name is everything.

Bad Feelings

This is where it gets weird. As you all know, I’m a huge supporter of forking. But sometimes when you fork, you’re a dick. There are a lot of weird things to consider when you fork, and for me, the first one is ‘Is the plugin I’m forking something you pay for?’ Generally speaking, if I’m even considering forking a for-pay plugin, I’ll try to start up a dialogue with the developers first, because I know that these people are trying to make a living, and I’m a dick if I take that away from them. Yes, GPL says I can do it anyway, but there’s the law and then there’s the community.

A lot of the time we tout the ‘spirt’ of GPL and I really hate that. We’re actually touting the cohesiveness of the community. That we know plugins are often free, but pay for support, or behind a pay wall, or a million other things. But. If you take away someone’s ability to make a living, you are a raging dick.

Strong words, but ones I firmly believe in. It’s no secret I’m not fond of the IncSub folks and their behind-a-paywall/yearly fee for plugins. My issue isn’t their code, however, or their prices, but their attitude. And while I don’t like them, I will support till my dying day their right to do it. And if someone logs in to their site, gets an account, downloads everything and then puts it up on their own site, well, I’ll support IncSub in kicking them while they’re down, because it’s just not nice.(This actually happened in November 2011.)

As Jane Wells put it:

The GPL does allow for redistribution of GPL code. You can even charge for it if you like. However, here at WordPress.org that sort of behavior is not encouraged or supported in our repo. If you redistribute, we expect to see modifications not available in the original. We show respect for the authors of GPL code by only promoting redistributions that are useful as new contributions through helpful modifications.

Which is why, when I forked the plugins I did, I made clear changes. Works on SSL now! Works on Multisite! And none were pay-for.

But what does ‘being nice’ have to do with this?

It Pays to Be Nice

WordPress’s strength is their community. It’s the people who dream and invent, and the GPL has given those people tremendous amounts of freedom to be creative and expressive. Where WordPress runs into problem is personality conflicts and clashes (even the smartest people can be assholes). And where you will see the most of those conflicts and clashes is when it comes to GPL and who has the ‘right’ to do whatever. (Second only to GPL is SEO.) Once you incur the ire of a community, your ‘cred’ drops amazingly. That’s why so many of us are accused of ‘drinking the Kool-Aid’ when we tout the GPL party line.

A quote in my comment ‘guidelines’ is from Lord Buckley, “If you know what to do and you don’t do it, there you bloody well are, aren’t you?” We all know the right things to do are to be good people. To respect each other and treat our fellow man with kindness. I don’t care what religion you are, or even if you worship the FSM. The only way we all get through this thing called life is to be decent people. Taking away someone’s source of income is rarely nice, and when you do it and say ‘I did this because it’s GPL and I can!’ then you’ve done it for the wrong reasons. Just because you can do something doesn’t mean you should. We all learned that as children, that just because I can throw a rock at Timmy’s head doesn’t mean I should.

Theft

When we get to college, many of us experiment, for the first time, with being able to walk away from things we don’t want to do, even though we should (like your classes). And many times, these young adult challenges, where we do the wrong thing, come with no serious repercussions, and we determine that it’s okay to break some rules. This curious attitude follows us into adult life. It’s okay to steal cable/music/movies because the companies that provide them make a lot of money, and the artist never sees it anyway, so we’re not hurting the people who really matter.

Taking someone’s product that is for sale, making a change and giving it away, is perfectly acceptable in the GPL. But that doesn’t make it right. That makes it legalized theft, and it will hurt your standing in the community. And that’s what people mean by the ‘spirit’ of GPL. You and me and everyone else who writes code or contributes are the spirit of GPL. And when you hurt one of us, you hurt us all.

Go ahead and fork plugins, it’s what makes WordPress, and any GPL product great. But when you fork, do it for the right reasons, and remember that the developer you’re forking from is a person too.

Treat them how you’d like to be treated.

9 April, 2012
Pretty URLs Matter
Just over a year ago, Lifehacker changed their site and we all learned about the hashbang. I believed that pretty URLs mattered:

I would posit that, since the web is based on look and feel, the design of your site still relies, in part, on the ease of someone in understanding the URL.

Well Dan Webb agrees with me: (It’s About The Hashbangs)

After quite a lot of thought and some attention to some of the issues that surround web apps that use hashbang URLs I’ve come to conclusion that it most definitely is about the hashbangs. This technique, on its own, is destructive to the web. The implementation is inappropriate, even as a temporary measure or as a downgrade experience.

This Dan guy happens to be in charge of switching Twitter from the #! back into nice, normal, readbale URLs:

@timhaines plus, now I'm in charge of undoing twitters hashbang URLs I can confirm that all the issues in that article are very real.

— Dan Webb (@danwrong) February 20, 2012

You can read the whole Twitter convo on Storify. But the take-away is, I admit, a little dance from me of ‘I told you so.’

In the comments of my previous post, someone pointed out that Google uses Hashbangs in a search. I have not seem them in my searches (here’s an example of what I do see on page 3 of a search for ‘sadasdas’):

https://www.google.com/search?sourceid=chrome&ie=UTF-8& q=sadasdas#q=sadasdas&hl=en&prmd=imvns&ei=8CthT86EEoWDgwerpqDwDA& start=20&sa=N&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.,cf.osb&fp=6b8f6c2ef22f8dde& biw=1324&bih=879

The thing is, Google doesn’t matter in this instance. Actually, none of Googles URLs ever really matter when it comes to the reasons we want Pretty URLs. Remember our credos?

URLs are important. Yes, they are, but they’re important when you’re looking for something. They should be important on, say, YouTube, and they certainly are important on Google Code pages. But for a normal Google search? You don’t type in google.com/ipstenu or even google.com/search/ipstenu to find pages about ipstenu (Though, really, that would be really awesome if you could! At the very least, the 404 should have a ‘Do you want to search for that?’ options. Get on it, Google Monkeys!) Which is the point I was trying to make. When you go to a site for specific content, you want people to say ‘Go to ipstenu.org/about’ and be done with it.

URLs are forever. Again, yes they are, except when they’re not. For Google? This doesn’t matter. They don’t search themselves, and rarely do I know people who bookmark a Google search. But… Did you know Googles search URL formats are backwards compatible? That’s right. If you had an old URL saved, it would still be usable.

Cool URLs don’t change. Except for search URLs. But Google knows if you’ve gotta change ’em, make ’em backwards compatible. Ben Cherry has a nice article on why it’s good, too, which I found enlightening. I still don’t like them on the front end of websites, mind you, for a reason Ben points out:

The hashbang also brings a tangible benefit. Someday, we will hopefully be rid of the thing, when HTML5 History (or something like it) is standard in all browsers. The Web application is not going anywhere, and the hash is a fact of life.

That’s the problem right there. We’re building something we know is going to go away! We just broke a credo!

Are there ever reasons for using Hashbangs? Sure, but most of us will never need them. They’re great for loading AJAX which is awesome because you can load new parts of your site faster. Heck, WordPress has some AJAXification, but it’s primarily on the backend. They’re fantastic for web apps and they have some attractive functionality. But they don’t work for everyone, and they never will.

The ‘replacement’ is HTML5, which introduces pushState, which lets you use a JavaScript library with HTML5 history.pushState and … well basically you write an app with that instead of AJAX and the Hashbang, your URLs stay pretty and your page can still have that nice ‘click to add the new tweets’ functionality that we’ve all seen on the new-new-new-Twitter. And Facebook.

See, pushState is giving us these three things (among others):
- better looking urls: A ‘real’, bookmarkable, ‘server-reachable’ url.
- graceful degradation: Render correct pages when you don’t have JS enabled.
- faster loading: By only loading parts of the page, slow-net users can get the content faster.
The downside? It doesn’t work on IE right now. That’s okay, though, since it’s got graceful degradation, IE users will just have to manually refresh things. Which sucks for IE users, but perhaps will be the fire under Microsoft’s feet to get on that one.

Keep an eye out in your webapps. They’ll be moving over to this sooner than you think.
14 March, 2012
mu-plugins: What is it good for?
If you’ve been using WordPress seriously for a while, or Multisite for more than twenty minutes, you know about this weird thing called MU Plugins. That used to mean ‘Multi User’, as in WordPressMU, the predecessor to WordPress Multisite. The short version is that any plugin you put in there is ‘Automatically On’ for your site. On a Multisite Network, this means it’s on for all sites. On a single site, it means it’s on and you can’t turn it off.(Must use plugins and 3.0 – WPMU Tutorials)

So why use it?

In a theme, often people will add code snippets to a functions.php file to customize things, and that works great. It gets called via the theme and you’re happy. But what happens when you change a theme? Or if you want to apply the changes to multiple themes? Then you use mu-plugins! I use it for all my ‘non-interface’ code, that is stuff I want to set and forget.

Here’s an example of a block of code I have:
```
// Header Additions
add_action('wp_head', 'fansite_head');

function fansite_head() {

        echo '<link type="text/plain" rel="author" href="http://fansite.tld/humans.txt" />';
        echo '<script type="text/javascript" src="http://apis.google.com/js/plusone.js"></script>';
        echo "<script type='text/javascript'>function plusone_vote( obj ) {_gaq.push(['_trackEvent','plusone',obj.state]);}</script>";
        echo '<meta property="og:type" content="fansite"/>';
        echo '<link href="https://plus.google.com/xxxxx/" rel="publisher" />';
}
```
This adds in my humans.txt (yes, I have one), the Google +1 tracking, and a link for the publisher so G+ knows the site is really itself. Now this code is on every site in my network, without lifting a finger.

Now there are some things that are very theme specific. Like I have a bit of code that adds similar data like my head example, but right below the HTML tag. Since that’s using a theme-specific call, I leave it in my theme functions.php instead. I even use this on my non-Multisite installs, since it just makes it easier to separate my perma-code from my theme code. In addition, when I’m making a site for someone else, and I’m not doing their theme (it happens), I can tuck things they want all the time, on every theme, in there, and they can’t ‘accidentally’ turn them off.

I’ve gotten in the habit of naming the files things like sitename-cpts.php (which has all my Custom Post-Type data for one single-site) and sitename-functions.php (which has everything else) and even sitename-style.php (which turns on the visual editor styling to match my site, and changes the html editor font, as well as a small fix for a fixed position header that looks nasty with the admin bar when logged in).

What do you love using mu-plugins for?
5 March, 2012
GPL – Oh Dear God
I come to code from a strange direction. I was a fangirl and I learned all about webpages because of that. Perhaps it’s because of that humble begining that I look at the GPL arguments much as I look at ‘shipping’ arguments in fandom. Shipping is when fans believe a relationship to exist between two characters, regardless of anything being scripted. A great example of this is Xena: Warrior Princess. Some people thought Xena and Gabrielle were a couple. Some people didn’t. When the two argued, there were fireworks. Now, with shipping, sometimes a miracle occurs and the couple do get together (see Mulder/Scully in The X-Files and Grissom/Sara in CSI: Crime Scene Investigation), but most of the time the arguments go on for eternity.

That’s pretty much how GPL arguments make me feel. Ad nasuem. I hate them, and I was sorely tempted to post this with comments turned off. But various people asked me my opinion and that they’d like to see this posted, so… you’re masochists. This all started with Rarst asking me what I thought about a GPLv2 vs GPLv3 in a trac ticket in WordPress to fix plugins about page license requirement. I should note that he and I don’t see eye to eye about GPL, and we’re still pretty friendly.

Here’s the thing. I don’t have a horse in this race. GPLv2, GPLv3, MIT, Apache, whatever. I don’t have a license I love beyond measure. You see, I work for The Man, and having done so for 13 years, I have an acceptance of things I can’t change. One of those things is ‘This is how we do things.’ You accept that, even if things aren’t the most efficient, or even if they’re not the way you’d do them if you could choose, this is what they are.

I view the GPL issue in WordPress with the same antipathy. It’s not that I don’t care, it’s that I accept the rules for what they are and I have no reason to rock the boat. WordPress says ‘If you want to be in our repositories, and you want to be supporting our official stuff, you have to play by our rules.’ This is good business sense, it’s good branding, and it’s self-protection. With that in mind, I recently changed a plugin of mine to use code that was MIT licensed.

Expat License (#Expat)

This is a simple, permissive non-copyleft free software license, compatible with the GNU GPL. It is sometimes ambiguously referred to as the MIT License. (MIT License compatibility with GPLv2)

That’s easy enough. But I’m sure you’ve heard people argue that GPLv3 and GPLv2 are incompatible, or Apache is, and those are true statements. Because they’re incompatible, however, does not mean you can’t use them together, it means you can’t incorporate them!

Let me explain. No. Let’s let Richard Stallman explain:

When we say that GPLv2 and GPLv3 are incompatible, it means there is no legal way to combine code under GPLv2 with code under GPLv3 in a single program. This is because both GPLv2 and GPLv3 are copyleft licenses: each of them says, “If you include code under this license in a larger program, the larger program must be under this license too.” There is no way to make them compatible. We could add a GPLv2-compatibility clause to GPLv3, but it wouldn’t do the job, because GPLv2 would need a similar clause.

Fortunately, license incompatibility only matters when you want to link, merge or combine code from two different programs into a single program. There is no problem in having GPLv3-covered and GPLv2-covered programs side by side in an operating system. For instance, the TeX license and the Apache license are incompatible with GPLv2, but that doesn’t stop us from running TeX and Apache in the same system with Linux, Bash and GCC. This is because they are all separate programs. Likewise, if Bash and GCC move to GPLv3, while Linux remains under GPLv2, there is no conflict.

What does that mean? It means I could write a plugin in GPLv3 and use it with the GPLv2 (or later) WordPress and not have any issues. However what I cannot do is take that code, put it into WordPress, and distribute it as a new version of WP Core. And that’s (most of) why we shouldn’t have the GPLv3 plugins in the WordPress repository. The fact is that often new core features get their start as plugins, and if we allow GPLv3 in there, we run the risk of breaking licensing.

Worse, if we get our ideas from a GPLv3 plugin and rewrite it to GPLv2, we still are at risk for violation. This is the same reason, to bring it back to fandom, why authors can’t read fanfiction. If they use your ideas, you can sue them. We have enough headaches with Hello Dolly, let’s not add to them. And before someone thinks I’m overreacting about that, I wish I was. I’ve watched copyright wars before, seen friends lose their websites over it, and I can’t imagine that a TV show would be less agressive than a software company when they feel their rights have been infringed. It’s terrible, but it’s the reality of the litigious society in which we live.

So why don’t we just move WordPress to GPLv3?

If it helps to think of software in a different way, pretend you have two versions of server software, Server 2.0 and Server 3.0. You can use the files from Server 2.0 on the box with Server 3.0, but you can’t use Server 2.0 files on Server 3.0. They’re not backwards compatible. That’s the first problem with GPLv3, we’d have to make sure every single bit of code in WordPress is able to be moved to GPLv3.

This is clarified in the GPLv3 FAQ: (GPLv3 FAQ Update – Converting GPLv2 to GPLv3)
I have a copy of a program that is currently licensed as “GPLv2, or (at your option) any later version.” Can I combine this work with code released under a license that’s only compatible with GPLv3, such as ASL 2.0?
Once GPLv3 has been released, you may do this. When multiple licenses are available to you like this, you can choose which one you use. In this case, you would choose GPLv3.

If you do this, you may also want to update the license notices. You have a number of options:
- You may leave them as they are, so the work is still licensed under “GPLv2, or (at your option) any later version.” If you do, people who receive the work from you may remove the combination with parts that are only compatible with GPLv3, and use the resulting work under GPLv2 again.
  If you do this, we suggest you include copies of both versions of the GPL. Then, in a file like COPYING, explain that the software is available under “GPLv2, or (at your option) any later version,” and provide references to both the included versions. If you have any additional restrictions, per section 7 of GPLv3, you should list those there as well.
- You may update them to say “GPLv3, or (at your option) any later version.” At this point, any versions of the work based on yours can only be licensed under GPLv3 or later versions. Include a copy of GPLv3 with the software.
- You may also update them to say “GPLv3” only, with no upgrade option, but we recommend against this. Include a copy of GPLv3 with the software.
That doesn’t sound terrible, does it? You can go from GPLv3 to GPLv2, so long as you remove all the GPLv3-and-up code. Backwards compatibility is complicated, and forward isn’t much better. The second problem is the bigger one. From the GPLv3 FAQ: (GPLv3 FAQ Update – permission to change release)

Consider this situation: 1. X releases V1 of a project under the GPL. 2. Y contributes to the development of V2 with changes and new code based on V1. 3. X wants to convert V2 to a non-GPL license. Does X need Y’s permission?
Yes. Y was required to release its version under the GNU GPL, as a consequence of basing it on X’s version V1. nothing required Y to agree to any other license for its code. Therefore, X must get Y’s permission before releasing that code under another license.

And why would WordPress want to switch to GPLv3 anyway? Other than having more licenses compatible with GPLv3 than GPLv2, the other main differences didn’t strike me as anything WordPress needs. You can read ifrOSS’s document and come up with your own opinion, of course. Basically in order to get WordPress moved to GPLv3, every single person who ever submitted code to WordPress has to be contacted and sign off on the change. Now, unless a clever lawyer type can argue that the act of submitted code to core reliquieshes your ‘ownership’ thereof, and the code becomes community

code maintained and manged by WordPress, and as such WordPress does not need to gain consent from all contributors, then maybe this can be done. But that’s a long, mess, legal conversation.

Finally, the real question is who are we protecting here? Remember, GPL is not about the developer but the user. The extra ‘freedoms’ that come in GPLv3 don’t really strike me as being about the user, and that worries me a little. Patent protection, permitting code to be kept from the end user, and tivoization are all great things for a developer who puts out the code, but as the person who wants to adapt it later, that sure feels pretty restrictive to me.

Will I use GPLv3 ever? Sure. But not in my WordPress code.
28 February, 2012