Category: How It Is

Making philosophy about the why behind technical things.

Plugin Licenses, Upsells, and Add-ons
This post is dedicated to WPEngine, who donated to help me get to WCSF. While I don’t use them, I think that if you’ve outgrown WordPress.com and aren’t quite ready to host everything yourself, but you still want the plugins and themes, then you should check these guys out. They aren’t cheap, but then again, I firmly believe in paying for what’s important.

Read the comments before you comment. Otto haz the smartz.

One of the many rules of WordPress.org hosted plugins is you can’t phone home. Actually you can, and the rule really is ‘Don’t phone home without a damn good reason.’ To use Akismet as an example, it phones home with information to help verify who posted on your site, and are they a damn dirty spammer. That’s a damn good reason. But phoning home to check “Did Bob pay for a license?” is not. That’s considered abuse of the “serviceware” guideline, and essentially making an API just to make sure a license is okay isn’t okay. Now making money on your plugins is an awesome thing. But when your code is open source and anyone can see it, how do you keep people honest?

To get down to brass tacks, I’m going to take a little jounrey the wrong way, before I get to some suggestions on how you can provide ‘free’ and ‘pay’ versions of a plugin on the WordPress repository, and not cause any guideline issues.

Let’s start out with the most common way people restrict you: A license key. If you put in a plain license key check like this, it’s easy to crack:
```
if ( $license == "yes" ) { // Licensed! }
```
Okay, you say, I want to encrypt things so that I tell someone ‘your license is ipstenuisreallyneatsheismadeofturtlemeat’ but when I look at my code, it shows ‘774ffc4efce8da294dff77f35f75df98‘ instead (that’s md5(ipstenuisreallyneatsheismadeofturtlemeat) as it happens). Wait. We can’t encrpyt code. Or rather, we can’t include encrypted code in a plugin, it’s against the no-obfuscation rule. We’d want to decrypt that instead. So I give you the code string instead and run it this way instead (Just pretend that $options['license'] is a site option.):
```
if ( md5(ipstenuisreallyneatsheismadeofturtlemeat) == $options['license'] ) { // Licensed! }
```
But then I have the problem of anyone can just look and see what’s going on again. You could go the extra step like putting ipstenuisreallyneatsheismadeofturtlemeat in a file and then pull off something like this:
```
$md5file = file_get_contents("md5file.txt");
if (md5_file("test.txt") == $options['license'] )
```
Is this easily decrypted? Yes. Is this easily circumvented by editing the code and removing the if? Again, yes. In fact the only way to really do this would be to use an API on your server to check the validity of the license (which you can’t do if you want to be hosted on WordPress.org anyway – no APIs just to check licenses), and even then I can strip mine your plugin and remove all checks like that. So why bother? Because you want to make a living on your code, and that’s certainly a fair-go! But as Otto rightly says, we can’t stop piracy, so why are we trying? DRM doesn’t work, and reverse engineering hasn’t proven sustainable. Maybe we’re building the wrong mousetrap.

If we throw the code solutions out the window, because we know they won’t work, where are we left? The next most common thing I see is people offering two plugins. A free, totally open GPL one on the WordPress repository and then a version behind a pay-wall that you would ‘replace’ that free one with. For example, I have a Rickroll plugin, and let’s say I wanted to make a Rickroll Pro version that let you change the video to anything you want, just put in the YouTube URL. I would have a settings page on my free version that pretty much says “Hi, if you want to change the video, visit halfelf.org/plugins/rickroll-pro/ to download.” And now I have to code Rickroll Pro to check if Rickroll (free) is installed and active, and refuse to activate if so. Furthermore, my users have to be told to delete the free Rickroll.

You know what? That’s a pain in the butt. What if instead I coded a Rickroll Pro add-on. No, I don’t mean ‘add this file to your plugin’ but ‘Install this second plugin, which will add functionality to Rickroll.’

It’s a second plugin, yes, but now I can have Rickroll free look for Rickroll pro. Not active? The settings page (which I would keep in Rickroll free) would tell you ‘Hey, you don’t have Rickroll pro! Install it and get more things!’ or ‘Hi, you have Rickroll pro installed by not active. Don’t you know it’ll never give you up? Activate it and have fun!’

Now the code muscle becomes a question of ‘How do I ensure my dependency checks work?’ First, Scribu wrote an awesome plugin dependency plugin, and the only flaw with it, is you’d have to install a third plugin. We don’t want that here, since yet another plugin is problematic. But looking back, that code grew out of a trac ticket about handling plugin dependencies. Now there’s a nice way to check: is_plugin_active()
```
if (!is_plugin_active('rickroll/rickroll.php')) {
    // do not activate. Provide message why.
}
```
You could go to town with the checks in there. Like if the plugin isn’t active, deactivate the child and so on and so forth. I’m not going to write it all for you (though Otto wrote a lot about it for themes)

Now going back in your parent plugin, you can run the same check:
```
if (!is_plugin_active('rickroll-pro/rickroll.php')) {
    // Rickroll pro isn't active, prompt the user to buy it.
} else {
   // Include rickroll-pro/adminsettings.php so they can use it
}
```
The one last thought I had on this was how to handle pro upgrades. Since I don’t like to upgrade a plugin a lot unless I have to, I’d make it an ‘upgrade both’. In Rickroll Pro I’d set a version constant, and then in that check to see if it’s active call, reference that version. So Rickroll, after verifying Rickroll Pro is active, would come back and say ‘My current supported version of Rickroll Pro is 1.5 and the constant is set to 1.0. You should upgrade!’ Then every time I write a new version of Rickroll Pro, I’d update Rickroll to point to the new version, and when they upgrade from WP, they would get notified about Rickroll Pro needing an update too.

Probably not the most efficient or effective way about it, but the other option is a self hosted plugin update API.

Bear in mind, because of GPL, all these hoops and ladders can be circumvented. Your plugin can and will be taken away for free. Don’t fight the pirates with registration circuses, and limit the weight of your code by selling the right thing. It’s a strange idea to think that giving your code away for free will help you earn money, but at the very least, not fighting against the pirates will give you time to write better, more secure, code. And that certainly will earn you more money. Then sell your support, because that time is money.
5 July, 2012
Highway To Plugin Danger Zone
This post is dedicated to Mark Jaquith, who donated to help me get to WCSF. Thank you, Mark!

There’s nothing wrong with using someone else’s code. All of us do it. That’s how we make something new: by building off the old. And we all build code that relies on someone else, even when we write operating systems. Everything is interdependent, and that’s okay. The problem with relying on someone else’s code, is that you’re open to their vulnerabilities.

Recently there was a kerfluffle about TimThumb, where the community came together and made a script, used by many themes and plugins, better and safer. This was an awesome moment, where we saw disparate strangers overcome FUD and live up to the dreams of Open Source.

In more recent days, there have been a lot of problems with the Uploadify script, to the point that Sucuri wonders if it’s the new TimThumb when it comes to overuse and vulnerability. Unlike TimThumb, Uploadify isn’t actually insecure due to a bug, but the design of how it works is insecure. Yes, it’s insecure by design. Uploadify allows easy multi-file uploads to your site, but it does it without integration with any user verification, so basically anyone who knows where the file is can upload anything they want to your site.

Uploadify offers some security suggestions, which encourages you to use the right folder permissions, keep the file outside of your public_html, and use SSL. The problem there is you’re still not checking to make sure that the code is only accessed by the right people. This isn’t a flaw in Uploadify. It’s a flexible product that can be used with anything, so they don’t want to lock it down to just WordPress, Drupal, Joomla, or whatever. This is, alas, the reason it’s so dangerous. Anyone can hook into it, if you don’t make it secure enough.

Now. A handful of WordPress plugins have been closed due to uploadify exploit potential (between 10 and 20). Not a lot, when you think about it. That’s because, perhaps surprisingly, not as many people are using it as you’d think. In part, this is from WordPress’s shift to plupload in WordPress 3.3, which allows you to hook into it in themes and plugins. By the way, I recommend you use plupload, because if you’re going to rely on third party code, it should be the one that comes with WordPress core.

The point is not to not use third party code, however, but to use it wisely and to use it safely. It’s your responsibility as a developer to make sure your plugin is secure, and to know what it does. If you don’t understand how someone else’s code works, don’t use it in your plugin, because by using it, you are now responsible for updating it, securing it and keeping it safe. How can you do it if you don’t get it? Furthermore its your responsibility to educate your users as to what a plugin does and how you’ve secured it. This is open source code, the bad guys can already peek in and see what’s up. If they know, then you owe it to the users to arm them with education.

The weakest link in the security chain is the education of the end users. The servers, we hope, know what the heck they’re doing. Ditto the software writers. But the users, they’re often the new guy, the one who doesn’t know what’s what yet, and they trust you. They trust you do your best. Note, I am not saying they trust you to be perfect. Anyone who expects perfection is ridiculous. We all desire it, of course, but you cannot expect it unless you yourself can deliver it. Can you? I thought not.

Alright then so what can you do to protect uploadify and similar scripts? First, lock it so it’s only accessible from the WordPress dashboard panels. If you can only get to it via WP, then you’ve locked yourself so no non-logged in users can access the tool. Then if you slap this code into the top of your file, no one can access it directly:
```
if ( ! defined( 'ABSPATH' ) ){ die( 'Direct access not permitted.' ); }
```
Next we should look into how we check for the user. Can any member of your site upload? Probably not. So let’s use capabilities and roles to lock it all down and make sure only the right users have access. We can use two simple lines to verify the user is logged in, and has the right capabilities to upload. The ‘manage_options’ cap is for Administrators, so loosen it up as you need:
```
if ( ! current_user_can('manage_options') )
die( 'Not allowed to upload.' );
```
You can hook an upload handler up as an AJAX handler via WP’s admin-ajax.php, per AJAX in plugins. If you need a non-AJAX handler, you can handle form submissions on your plugin admin pages. Going through WP gets you authentication and capabilities checking, and easy usage of nonces (see wp_create_nonce() and related links at the bottom of that page for more info).

There are of course more ways to secure things. There are nonces and AJAX, as well as using WordPress’s image tools to help double check if a file really is an image. After all, not everyone can use .htaccess, and some servers are silly enough to let you run a php file with a jpg extension.

But all that really only works if you want to restrict your uploads to members of your site. What if you want to let anyone upload an image? Honestly, you should re-think that. You are not imagur or imageshack. They have layers of server protections which you don’t, and they have levels of checks and balances in software written specifically for image uploads and protections. You don’t. They are a tool specifically for the job of images. WordPress is not. Do you see where I’m going? Do you really need to allow images be uploaded to your site? I bet you don’t.

Shortly after TimThumb was exploited, it was yanked from the theme repository. Since WordPress 3.3 no theme can contain TimThumb. From what I can gather, part of the reason is that code like that should be a plugin, not a theme. But personally, I think that both TimThumb and Uploadify should have official plugins (supported by the original/current developers), and anyone who wants to use that code can hook into those plugins. Then, if there’s an exploit, it’s one plugin to fix and not a couple hundred.

Of course there are as many flaws with that as with any other approach. If the original devs don’t want to support a plugin for WordPress or any other platform, the users would be SOL.
2 July, 2012
Listen to the Aftertaste
On Wednesday, the guys at WPCandy have a podcast, WP Late Night, where they talk about WordPress. After the show they have the Aftertaste. And this week I ended up on the Aftertaste.

Basically Dre noticed I was on IRC (a rarity for me) and asked if I wanted to join them. I thought about it, hauled my laptop into my office and chatted away for an hourish. I’m rarely home and un-busy on a Wednesday, so it’s a treat for me to listen live (instead of at work or on my iPad after the fact).

Aftertaste #25: After WP Late Night 15 (with Ipstenu!)

I’m at the 52 minute mark or so, but the whole after show is 2 hours and change.

Mostly I talked about support, WordPress, a bit about me, and … Honestly I haven’t listened in great detail. My wife says I started quiet and got louder, and others have said I don’t sound like a twelve year old girl, so that’s something.

At the very least, you’ll hear me pronounce my own name.

Amusing things you will learn:
1. Why I can’t rent a car
2. Where I work (but not by name)
3. What WordCamps I’ll be at
4. My citizenship
5. My sense of humor is exactly the same as it is online
I admit to be tickled pink that people think I must be calm and patient with all the repetitive questions you get in the forums. I’m not, they just can see my rolling eyes. I have a sardonic sense of humor, though, so I put up with it. I just vent elsewhere.

Oh and the ‘book I wrote’ mention was, indeed, about WordPress Multisite 101 (and it’s followup, WordPress Multisite 110) so feel free to link people to them.

Fun thing that didn’t get mentioned, yes, I’ll be at WordCamp Chicago. I have a ticket to WC San Francisco, and the vacation days, I just have to sort out the travel stuff and hotels, because I can’t rent cars, and stuff is expensive.

As an added bonus, here’s the last time I did anything audio-esque.
29 June, 2012
Amazoned
I don’t actually like Amazon. However the Kindle people spoke and I listened. After checking that, yes, I can release my ebook for sale on the Kindle legally (that was a weird conversation), I sat about doing it. I really wanted to self-publish on lulu, but … well, Amazon was easier. There. I said it. They actually know what they’re doing, and made it surprisingly painless! Of course, that they want you to write it in .docx, export to html, then upload a zip, was a little nuts. They also let you upload ePubs, which I have, so that was a lot easier.

I am now a Amazon Author or publisher. Whatever. And I have two books up on Amazon:
- WordPress Multisite 101
- WordPress Multisite 110
There’s no DRM on these puppies, and while, yes, it costs $7.99 to download, that’s because Amazon takes a really hefty chunk of change. See for every $5 you donated to me, I got $4.50 from Paypal and WePay. Amazon takes 30% or 65% of your money for every sale. Now I know, you’re thinking ‘Why would anyone pick the 35% option!?’ In the ‘real world,’ publishers give writers around 15% in royalties. Seems like a rip off at first, but look at what goes into all this. Writing, editing, typesetting, printing, binding, shipping, advertising, etc. And I’m skipping all that to go at it alone.

So why would I pick 35% for epublishing, when all they’re doing is webhost plus bandwidth? If you pick 70% royalties, then you get 70% of the cost, minus ‘shipping.’ Shipping, by the way, is electronic delivery. You’re paying for the bandwidth. Fair enough, works out to about $0.05 for every country. But also with 70%, I can only charge between $2.99 and $9.99 US for my book. So the max I can charge is $9.99, which will ‘net’ me $6.96. With 35% I can charge up to a couple hundred ($299.99). Now here’s the dillema. How much to charge. If I max out and go to $9.99 (damn it, I wish they’d just say $10!), I may look greedy. Then again, I did all the work here, do I not deserve my $7 per book? To get the $4.50 I was getting via donations, I’d have to charge about $6.75 for the book, at which point I may as well charge $7. Then again, the average donation I got was actually closer to $8.

Which is how I ended up at charging $7.99 you see. I don’t expect to break the bank. Hell, I don’t expect lightning to hit like that again. But it was kinda cool. By the way, you don’t get 70% for all countries, just the ones that allow it. The rest get you 35% instead.

The biggest hassle, other than price, was sorting out the various fields, which in and of themselves, weren’t that hard. Took me an afternoon, and I had the books approved by later that day. I found an error (I’d uploaded the wrong cover, go me) and made a fix, for that I waited a day for the republish and the image to show up. Weird, but not complicated.

I have to say, Amazon is a hassle, but far less than other places that say ‘You need to make an ISBN’ and ‘You must follow these formatting guidelines.’ which are cryptic and … You know, if they really wanted to make things easy, someone would make a nice form where you could upload your book, sans cover and author pages and copyright. Just the book content, right? Then once it’s uploaded, from epub or docx, you create your author ‘page’ and place it where you want (front of TOC or behind) and then copyright page ditto. Finally you upload your cover. If an ISBN is required, you make it for them. Remember, self publishing is something that you should be helping people do! Otherwise what’s the point?

Amazon (mostly) hits that one on all the marks. Why not iBooks, you may ask? The tool sucked. No, really. I wrote a doc in pages (Apple’s version of Word) and you’d think I could upload to iBooks and it would auto-format. Nope. Also there was the restrictive bit. Apple’s terms say that any content produced with iBooks Author that is for sale is to only be available on the iBookstore. Free ones can be distributed anywhere you like, but iBooks Author only exports to the .ibook format (and PDFs) so if you want to free-distribute (which technically is what I do here), you have to use a flat PDF. Okay, that isn’t really terrible, the epub to pdf ratio is 1:70. But then I can’t ‘sell’ on Amazon! Amazon, by the way, only locks me down if I’m using the KDP Select program. At least I think so. I read the legalese a few times.

Fairness to be had, I don’t feel that it’s ‘wrong’ for Amazon or Apple to restrict what you can do when selling your books. It’s free, you get what you pay for, as it were. Both Amazon and Apple take a 30% cut, and all things being equal, Amazon is a better choice. Of course you can still download them ‘for free’ if you want to from my ebooks page. Donations, as always, are welcome.
18 June, 2012
Penguins Just Gotta Be Me
Credit – Gary Larson

Google’s Penguin came out and a lot of people got hammered, hard, by the changes. Penguin is the name of their new/updated algorithm, and it seems to have a lot to do with backlinks.

Backlinks are when other people link to you. Pretty straightforward, but now it appears that people are being penalized for backlinks. Is this true? Yes and no. Google used to credit you for all sites that linked back to you, so the more popular you were, the more referral credit you got, the higher you were ranked, and that seems fair. Now, Google’s no longer passing through backlinks from spammers, so your referrals are dropping and people are being ‘penalized.’ But not really. That’s almost like saying you’re getting fewer phone calls after all the telemarketers stopped calling. Yes, you are, but you’re now not getting junk calls, and the ones you are getting are higher quality. The theory here is that everyone is now being judged fairly again, and by omitting the bad people from giving credit, you’ve leveled the playing field. Nice theory. It still feels pretty horrible to find your rankings dropped.

How do you find what happened to your rankings? Search Engine Journal has a lengthy explanation, but it boils down to looking at your Google Organic traffic and see if you have noticable drops on April 19th, 25th and 27th. That covers both Panda and Penguin.

But what caused it? Is it legit drops or unfair ones? That’s really something easily argued in multiple directions. The basic reason is something in your site, or in your site’s backlinks, has been determined to be spam. It sure feels unfair, because how can you be expected to do anything about what other people are doing! They’re the spammers, not you, why are you punished? Again, tis the great equalizer. If you remove all the bad links, what you’re left with may be a lower ranking, but it’s possibly a more honest and accurate one. I say possibly because I’m not able to see behind the Google curtain.

Few of my sites were impacted, though I generally get traffic from Twitter and Google Plus, because that’s where I advertise. Once in a while, a post gets picked up by another WordPress blog or email list like WP Mail or Matt Mullenweg, and I get 600% traffic. But most of the time I’m pretty steady, increasing slowly and naturally. In part this is because this is my hobby. Certainly I take pride in what I do, but this is not going to make or break me. That’s lent itself to a very odd thing. I’ve managed to follow every single one of Google’s ‘do this!’ suggestions, without ever thinking about it.

What are these rules? They’re obvious and I’ve touted them many times before.
1. Write good content.
2. Don’t spam.
3. Link naturally.
The first two are easy, the last one is a bit weird.

Natural linking is like what I did when linking to Search Engine Journal. I saw a URL, I copied it in, and I put my own description. In addition, I don’t have a massive collection of links anywhere. I link to people and posts in-line, when they come up, and send you around to them in a way like I would if we were talking. In that way, I’m always making backlinks that are valuable for the next guy.

But like I mentioned before, you can’t control other people’s backlinks to you. If you write WordPress themes and plugins, you maybe getting hit by this, and there is something you can do. It’s just that you won’t like it. See one of the things spammers do is use the same link, with the same URL and href attributes, over and over. What happens when you have an attribution link in your theme or plugin? It’s the same link. Over and over. At first glance, that seems horrible, because a theme would be penalized for having a link credit (like I have here) back to their sites. Some people seem to feel this is exactly what’s happening and the current feeling is that putting in the link as nofollow would be a solution.

Sidebar: Yes, I’m aware of the debacle with WPMUDev getting hammered by Google Penguin. Of interest to me was that once they removed EduBlogs (a site they run) from having links back to them, the issue seemed to be resolved. A working theory of mine is that Google saw the hundreds of thousands of ‘self’ backlinks from these sites to the parent and it was felt to be gaming the system. This would explain why WordPress, who runs a gazillion number of sites, didn’t get hit, and why not all themes are getting slaughtered. Personally a better move would have been for Google to just throw those results out the window, but…

Plugins, on the other hand, run by different rules. One of the plugin guidelines is no powered by links at all unless the user actively opts-in.(Themes are permitted one in the footer, or an optional one. In part this is because you only ever have one theme at a time, but you can have multiple plugins.) Having too many links out to the same place would be a problem for your SEO, and a plugin that linked multiple times would hurt you. We already know that Google knows how to check your js for hidden links. Back in 2007/2008 they added in the ability to pase onClick events, and it’s only improved since then. So while in 2008 Matt Cuts said it was safe to put a link in your JavaScript if you didn’t want it searched, that seems to no longer be the case. I’ve spot-checked on a couple sites, comparing them before and after, and studying their configurations, and many that have JS controlled ‘powered by’ links are being hurt.

One major takeaway here is that Google screwed some things up, big time. A day-zero search on Viagra was buck wild and all wrong. It’s fine now, but there’s no way a spammer should have been ranked first on a Viagra search. I’ve complained about how Google prioritizes before, and back in 2009 I declared that Google’s Blog Search was Irrelevant. You couldn’t get a single decent result on anything. With Penguin and Panda, they’ve decided to treat everyone the same, and if a lot of terrible people are using your products, and you have a backlink, you’ll get dinged.

What does all this mean? Well go Google for ‘panda google wordpress’ and you’ll see a lot of people shouting that they’re being penalized, and the ‘nofollow’ fix is hardly a fix at all. More are shouting that those ‘share this’ plugins, which show up multiple times on one page, are causing rankings to drop because the exact same link shows up multiple times. And right now, we don’t know. Like the Viagra problem, Google is fixing a lot of this on the fly. Google says ‘No algorithm is perfect!’ and that is certainly true, but if Google really is just equalizing things, then why were these bad sites so highly ranked to begin with?

If you’re a plugin/theme/designer, I’d put in nofollow to my works for now. First, the link-juice didn’t matter anyway if it was in javascript, and second, what you want is people coming to your site and downloading the perfect theme or plugin. They’re going to shop around, and that will, eventually, lead to more sales. Pushing people is a sales technique that falls flat. There are so many options for themes and plugins, a hard-sell will lose you people. So will stuffing your plugin with every SEO trick you know.

There’s no great answer, and screaming at Google (or WordPress) isn’t going to help. They’re going to do what they want. The best you can do right now is weigh your options between attribution and abuse. Are you really making things better for the users, or are you just doing this for yourself?
15 June, 2012
On The Segregation of Code
WordPress stores your URLs in the database as the full URL. That is to say all the links to other pages on your site, all the images, use the full path.

When I changed this site from tech.ipstenu.org to halfelf.org, I knew that meant I’d need to do a quick search/replace in the database. That meant first I searched wp_2_posts for everything saying tech.ipstenu and replaced it with halfelf. Then I did the same in wp_posts (since I knew I’d done some of that). I did this directly in SQL because I can, and I believe in using the right tool for the job. To whit:
```
UPDATE wp_2_posts SET post_content = REPLACE (
post_content,
'tech.ipstenu',
'halfelf');
```
That code searched all my posts and changed the URLs so my images looked right. Now, since I’m using a domain mapping plugin, I don’t need to go in and change wp_blogs, which I would be very hesitant to do anyway. I’d sooner make a new site with the same name (either manually or via a replicator), delete the old one, and use .htaccess to redirect.

Why would I do all this? Well, because WordPress stores URLs in a non-relative way. The link to my about page is https://halfelf.org/about, not just /about, and that screams in the face of what I learned back when we all agreed that paying for Netscape as a browser wasn’t a terrible idea.

The real question people are asking is why are we this way?

There are a lot of arguments, one is that you shouldn’t change your URLs. Another is that WP is written for the user, not the developer. A third is that you’re trying to force your process on a tool, when you should really develop the process for the tool. That third argument is where I live. I believe in being adaptable, while I want all my code to be flexible, adaptable and fluid, there’s a time and place for the flexibility being the code, and the flexibility being me. In the case of URLs, I think the flexibility must be mine.

In the ‘real’ world, you should never change your URLs, and if you do you always have the old ones forwarding to the new ones. Go on, go to http://tech.ipstenu.org/about/ and where do you end up? That’s because the plugin works. Go to http://code.ipstenu.org/about/ or even http://ebooks.ipstenu.org/ and see what happens. That’s because I forward those (obvious) URLs to where they should be. I know that people can adapt to change, but I can help with them a well crafted .htaccess rule. That’s flexibility in my code.

When we take another step back and consider the flexibility of code, we muddle that up quite nicely with the flexibility of content. These are different things. Code should be flexible and adapt to any situation you put it in, but you need to be flexible to adapt your content to the situation. Content cannot be considered in the same breath as code, because they are segregated by their very nature. We should be able to pick up our content and plunk it down in any code, and have it work equally well. This argument was fought, and won, by CSS back in the day. So how does this work with URLs? They’re in my content as links, and if I change them, I have to change my content.

Let’s take the example of building a site locally. Personally, I use a hosts file to make halfelf.loc so that when I’m done building it all out, I export the DB, replace halfelf.loc with halfelf.org, and I’m done. Why do I pick halfelf.loc? If you’ve been here before, you may remember I wrote about Moving Multisite. In there I mention serialization. That’s why. Searching for domain.loc and replacing with domain.org will not break serialization! This is, some claim, a ‘bush league’ maneuver (yes, zamoose, I heard you), but have you ever tried to move an application on your desktop to a new location? You have something installed in Program Files, let’s say, and you want to move that to Program Files/Half Elf? Congratulations, you get to search the whole registry!

See, it’s not just WordPress. This isn’t an excuse, but a statement of fact. Many applications on the web don’t use relative paths, and they do force you to search/replace things to move to a new location. This is especially the case when you think about how we write links. Some people use the link interface, which if used, could insert variables for ‘base path.’ But some of us use the old fashioned manual way, and now you have to code a really fancy bit to check “Did Ipstenu post a link to myself? If so, I need to change halfelf.org/foobar into [basepath]/foobar so I can update it later if I move.” Certainly it can be done, but it’s actually going to be easier to just search/replace. The ‘more’ you search for, the easier it gets. I actually know someone who did this. He says it was more trouble that it’s worth.

That really doesn’t surprise me. What all the proposed fixes to this try to do is to force WordPress into working a certain way, rather than customizing a solution. That probably sounded the same to a lot of people, but it’s not. The method by which you move static HTML files around servers is, for lack of a better term, a migration method. When you migrate an application from sys to test to production, you do so because there are a lot of moving parts to test. It’s in these moves that we face headaches with the relative path locations. When we hard code locations into our content, like in a URL, we lock ourselves into that URL, now and forever. But does the content actually matter?

For me, the real question is ‘What moving parts of WordPress might I be testing that I would need to ‘push’ to my production site?’ I came up with three things:
- Themes
- Plugins
- Content
I ‘push’ themes and plugins out to a test server and then my production server all the time. I do it for hundreds of different applications a day, and it’s all automated. We never have a problem (unless the code is bad) because we perfected our migration method, and let go of the idea of pushing our content. Our content is not our code.

Initially, we didn’t replicate content for legal reasons. We have sample data to test with when we’re checking out theme and plugin changes, but we don’t bother with data replication. Realistically we can’t, since the people who are testing things out don’t have the security clearance to look at the content. Because of that, we have to trust that the live data is the live data, and that it’s good. Instead of sweating over the content, we concentrate on copying up, in this case, themes and plugins. Since those may have customizations, we take a snapshot of the database, install the theme, make our changes, and take a snapshot after. Get the diff, and now we know what needs to be applied up. Then we script it. The job will FTP up the files, run the SQL diff (which we’ve already edited for the new domain name if needed, but rarely since we use hosts to point at our dev server instead), and off we go. Same thing for plugins.

If I apply this to WordPress, suddenly I have but one, minor, headache in moving my code, and that’s the wp_options table, and it’s serialization which includes the URL. I agree, that’s a headache and if I was going to put paid effort to fixing anything about relative URLs, that would be it.

But I don’t think that URLs for WordPress should be non-relative. Given the alternatives and the possibilities, right now the issue isn’t that WordPress stores the like that, but that we don’t have a migration ‘process’ defined yet. We should stop getting hung up on ‘fixing’ what isn’t broke, and instead start looking at the best ways to move what needs moving. See, once we found we couldn’t replicate our content, we started looking into what needed to be done to protect it, outside of ‘migrations.’ In WordPress, today, the best way is to have your writers submit their posts, and your editors review and publish. You may want to look into groupflow plugins, or do what the Bangor Daily News did.

The right tool for the write job.(Pun intended.) Moving your content between testing and live servers isn’t needed. Just concentrate on moving the ‘app’ as it were. It’ll work better.
5 June, 2012

Category: How It Is

Plugin Licenses, Upsells, and Add-ons

Highway To Plugin Danger Zone

Listen to the Aftertaste

Amazoned

Penguins Just Gotta Be Me

On The Segregation of Code