I recently had an exchange with a commercial theme developer who changed his terms away from the GPL because of an experience with some rude person who was redistributing his themes for free. Ultimately, I wasn’t able to convince him to stick with it, but there was a clear misunderstanding of the GPL in the first place there (I suspect that language differences played some part), and I thought this might make for an interesting blog post.
(Note that I’m talking about themes, but this all applies to commercial plugins as well as any other code you’re selling online.)
It’s All About Redistribution
The main barrier to the GPL that a lot of theme developers have expressed is the right of redistribution. That is to say that if you sell me a GPL’d theme, then I can turn around and give that theme to anybody I want, for free, and you have no recourse.
This viewpoint is entirely correct, however it’s missing the big picture, I feel.
Why Would I Do That?
First off, why would I take something I paid for and then give it away to everybody else for free? I mean, it’s one thing to give a copy of something to a friend of mine for his use, but it’s wholly another to go to the effort of setting up a website to distribute your theme as some kind of “screw you” policy. Did you anger me in some way? What level of maliciousness would be necessary for me to want to do that? Seems a bit overboard, and most people are ultimately reasonable.
However, this ignores the existence of John Gabriel’s Greater Internet Fuckwad Theory. Which is to say that some people are just trolling bastards who will screw with you just because they can. So let’s say that somebody gets a copy of your themes, posts them online, then refuses to take them down despite your polite requests, and waves the GPL in your face for his right to redistribute them.
Technically, this sort of person is correct, he does have the right of redistribution. But that doesn’t really matter.
What Are You Selling, Anyway?
Let’s say I made a piece of code and sold it. No GPL, no license, just me selling code to people for their own use. They have no rights to the code whatsoever. So, somebody posts that code online, for free, at some pirate site. Somebody else downloads it, and uses it, without paying me. Straightforward software “piracy”.
What have I lost here? Well, I lost the cash that I could have made from an extra sale, true, assuming that said person would have bought the code instead of pirating it. If you know people who habitually pirate code, then you know that that is a rather dubious claim, at best.
More importantly, I’ve lost a contact point between me and the user of the code. When I sell something to somebody, then I now have a relationship with that person. I get their email address. They may contact me for support. Even paid support. I may have forums for purchasers of my software to talk amongst each other in a community support system. They may buy other things I wrote.
This is the real benefit to selling code, that relationship between me as a developer and them as a purchaser of what I develop. And I’m missing that connection, until they want support from me for my product. Then I may say “well, you’re using a pirated copy of my product, if you want to join my support forums and my community and get my help, then you have to buy the product from me”. Take note of the many times that software companies have offered “clemency” sales and such, to turn pirated copies into legitimate ones.
What it comes down to is simple:
You Can’t Stop Piracy, So Don’t Try.
Think about it, you’re selling a digital file here. Files can be copied. If I buy a copy of your software, strip out any identifying marks, then post it to a thousand torrent sites, what exactly can you do to stop me from doing that?
No matter what your terms and conditions are, people still can copy your files, distribute them, edit them, do whatever they want. Unless you’re actually enforcing your terms with (potentially expensive) legal actions, then your terms are really quite meaningless. Technical measures to stop piracy don’t work, as many game companies have found out over the years. DRM doesn’t (and technically cannot) work.
Instead of viewing people redistributing your code as a bad thing, view it as an opportunity. If somebody downloads a “pirated” copy of your code, and uses it, then clearly they have a use for it. And at some point, they’re going to want upgrades. They’re going to want support. They’re going to want modifications. So make sure that you are the person they come to, and then you have an opportunity to convert that pirated download into a real sale.
The GPL doesn’t screw the developer by allowing others to share his work. The GPL enables the developer to get more contacts (and potentially more sales) by allowing others to share his work along with his name, contact information, website, etc.
Don’t fight against the right of redistribution, make it work for you instead.
A surprising number of people don’t know about or have never used this feature, so it’s something I thought I should point out.
You know all those boxes on the Edit Post page? Did you know you could turn them off? Did you know that WP 3.1 turns many of them off by default?
See? Just click the Screen Options dropdown to show or hide anything you want or don’t want to see. These settings are saved so that you can customize how your own editing screen looks, for you only, every time you go to add or edit a post. Plugins that make meta boxes get their meta box added to this list too, so if you don’t use the manual Publisher boxes from my own Facebook or Twitter plugins, for example, you can just disable them.
People often ask me why there’s a Publish box when they are using Auto-Publish in the SFC or STC plugins, and why I didn’t make that optional. So I just thought it might be worth pointing out publicly that there is already an option for it, built right in.
There’s been a lot of articles on this topic over the years (I even wrote one). But I’m going to tackle this from a different angle, one that I’m not used to: A non-technical one.
Fixing a website “hack” is actually a fairly heavy technical thing to do. Most bloggers are not webmasters. They are not really technical people. They’re probably people who simply purchased a web hosting account, maybe set up WordPress using a one-click install, and started blogging. In an ideal world, this sort of setup would be perfectly secure. The fact that it’s usually not is really a problem for web hosts to figure out.
But often I find that the emails/posts I see that read “help me my site was hacked what do I do” or similar don’t get a lot of help. There’s a reason for this. People who are asking this question are not usually the type of people who are technically capable of actually fixing the problem. Guiding somebody through this process is non-trivial. Frankly, it’s kind of a pain in the ass. So those of us capable of fixing such a site (and there are plenty) are reluctant to try to help and basically offer our services for free. The amount of work is high, the frustration is equally high, and there’s not a lot of benefit in it.
So, with that in mind..
Step One: Regain control of the site
By “control”, I basically mean to get the passwords back and change them. Tell your webhost to do it if you have to, and read this codex article on how to change your WordPress password even when you can’t get into WordPress. Also, change your web hosting account password, your FTP password, the database password… Any password you have even remotely related to your site: change it. Note that doing this will very likely break the site. That’s okay, down is down, and it would be better to be down than showing hacked spammy crap to the world.
And that’s another point: take the site down, immediately. Unexpected downtime sucks, but if you’re showing spam to the world, then Google is sure to notice. If you’re down for a time, then Google understands and can cope, but if you’re showing bad things, then Google will think you’re a bad person. And you don’t want that.
The idea here is to stop the bleeding. Until you do that, you haven’t done anything at all.
Step Two: Don’t do a damn thing else
Once you have the passwords and the site is offline, leave it like that.
Seriously, don’t erase anything, don’t restore from backup, don’t do anything until you do what follows next…
Anything you do at this point destroys vital information. I cannot stress this enough.
Step Three: Hire a technically competent person to fix it for you
If you know me, then you know I rarely recommend this sort of thing. I tend to offer technical knowledge and try to help people do-it-themselves. But hey, for some people, there are times when it’s just a hell of a lot to take in. Webserver security is a complex subject, with a lot of aspects to it. There is a lot of background knowledge you need to know.
If you’re reading this and you don’t know how a webserver works, or config files, or you don’t know arcane SQL commands, or you don’t understand how the PHP code connects to the database and uses templates to generate HTML, then trust me when I tell you that you are not going to fix your website. Not really. Sure, you could probably get it running again, but you can’t fix it to where it won’t get hacked again.
So, find a website tech person. Somebody who knows what they’re doing.
(BTW, not me. Seriously, I’ve got enough to do as is. Just don’t even ask.)
How, you ask? I dunno. Look on the googles. How do you find anybody to do anything? There’s several sites out there for offering short-term jobs to tech wizards. There is the WordPress Jobs site, but note that I said you need a website person, not necessarily a WordPress person. A lot of people who know WordPress don’t know websites and security… Although many of them do and this is not an indictment on the community, it’s more a recognition of the fact that working with servers and websites in general is not really the same thing as working with WordPress. WP knowledge is useful, but generic server admin experience is much, much better in this situation.
And yes, I said HIRE. Seriously, pay up. This is a lot of work that requires special knowledge. I know that a lot of people try to run their websites cheaply and such… Look here, if you’re paying less than $300 a year to run a website, then why bother? How serious are you about your website anyway? Quality web hosting should cost you more than that, hiring a specialist for a short term day-job is going to run you a fair amount of money. Expect that and don’t give him too much hassle about it. Feel free to try to argue on the price, but please don’t be insulting. Offering $50 to fix your site is unfair, as that’s less than an hour’s pay for most consultants, and you need one with special skills here. This is a minimum of a day’s work, probably longer if your site is at all complicated. Just getting it running again without doing everything that needs to be done is probably a 4 hour job. Sure, somebody can hack together a fix in half an hour, but do you ask your automotive guy to just throw the oil at the engine until it runs? Have some respect for the fact that knowledge and skill is valuable, in any profession.
Basically, here’s what the website guy will be doing, if he knows his business.
First, he’ll probably backup the site. This includes the files, the databases, any logs that are available, everything. The idea is to grab a copy of the whole blamed thing, as it stands. This is a “cover-your-ass” scenario; he’s going to be making large scale changes to the site, so having a backup is a good idea, even if it is a hacked one. The person will need all of the relevant passwords, but don’t give them out in advance. He’ll ask for what he needs from you.
Second, if you already have regular backups (please, start making regular backups… VaultPress is invaluable in this situation and can help the process out immensely), then he’ll probably want to restore to a backup from before the hack. And yes, you very likely WILL lose content in this restoration. However, since there is a backup, the content can be recovered later, if it’s worth the trouble.
(Note, if you don’t have any backups, then he’ll try to remove the hack manually. This is error prone and difficult to do. It also takes longer and has a much lower chance of succeeding. It’s also difficult to know that you got everything out of the site. If anything is left behind, then the site can be re-hacked through hidden backdoors. This is why regular backups are critically important to have.)
Third, he’ll update everything to the latest versions and perform a security audit of the site. This means looking at all the plugins, themes, permissions on the files, the files themselves, everything. This is to make sure all the main security bases are covered and that it doesn’t get rehacked while he does the next step. They may talk about “hardening” the site.
Fourth, from that backup he made earlier, he’ll likely try to trace where the hack started from. Logs help here, as do the files themselves. This is kind of an art form. You’re looking at a static picture of a dynamic system. And unfortunately, he may not even be able to tell you what happened or how the attackers got in. Attackers often hide their traces, especially automated tools that do hacking of sites. With any luck, the basic upgrades to the system will be enough to prevent them getting in again, and a security audit by a knowing eye will eliminate the most common ways of attackers getting in. That often is enough.
Step Four: Prevention
Once your site is fixed, then you need to take steps to prevent it from happening again. The rules here are the same rules as any other technical system.
Regular backups. I can’t recommend VaultPress enough. After my site went offline for a day due to some issues with my webhost (not a hack), I lost some data. VaultPress had it and restoring it was easy. There’s other good backup solutions too, if you can’t afford $20 a month (seriously, don’t cheap out on your website folks!).
Security auditing. There’s some good plugins out there to do automatic scans of your site on a regular basis and warn you about changes. There’s good plugins to do security checks on your sites files. There’s good tools to check for issues that may be invisible to you. Use them, regularly. Or at least install them and let them run and warn you of possible threats.
Virus scanning. My website got hacked one time only. How? A trojan made it onto my computer and stole my FTP password, then an automated tool tied to that trojan tried to upload bad things to my site. It got stopped halfway (and I found and eliminated the trojan), but the point is that even tech-ninjas like me can slip up every once in a while. Have good security on your home computer as well.
Strong passwords. There is no longer any reason to use the same password everywhere. There is no longer any excuse for using a password that doesn’t look like total gibberish. Seriously, with recent hacks making this sort of thing obvious, everybody should be using a password storage solution. I tried several and settled on LastPass. Other people I know use 1Password. This sort of thing is a requirement for secure computing, and everybody should be using something like it.
These are some basic thoughts on the subject, and there’s probably others I haven’t considered. Security is an ever changing thing. The person you hire may make suggestions, and if they’re good ones, it may be worth retaining him for future work. If your site is valuable to you, then it may be worth it to invest in its future.
And yes, anybody can learn how to do this sort of thing. Probably on their own. The documentation is out there, the knowledge is freely available, and many tutorials exist. But sometimes you need to ask yourself, is this the right time for me to learn how to DIY? If you need quick action, then it might just be worth paying a pro.
While the WordPress upgrade system is great, sometimes people prefer to use command line tools or similar to manage their sites.
I hadn’t done this much until recently, but when I was at #wptybee, Matt asked me to set up a site using SVN externals. This turned out to be easier than expected, and a great way to keep a site up-to-date and easy to manage. So I thought I’d document the process a little bit here.
This is actually not an uncommon way of creating sites and maintaining them. I’d just never seen it documented anywhere before. If you know SVN, you probably already know how to do this.
First, you’ll need to have a website on a host. Obviously.
You’ll also need shell access on that host. SSH will do fine.
Next, you’ll need that host to have SVN. Easy way to check: just run “svn –version” at the command line.
Finally, you’ll need an SVN server. A central place to store your files. Some hosts let you set these up easily. Sometimes you’ll have to set one up yourself. How to do this is slightly outside the scope of this article.
Create the SVN environment
The first thing you’ll want to do is to check out your SVN area into a directory on the machine. You can do this part on either your local machine, or on the server. I did it on my Windows 7 laptop, using TortoiseSVN.
The basic idea here is that this site will become your new public_html directory. Alternatively, you can make it a subdirectory under that and use .htaccess rules or any form of rewriting to change where the root of your website is. Regardless, the directory as a whole will be your main website directory.
Now, we’re going to get WordPress installed into your SVN. To do that, we setup the WordPress SVN to be an external of the SVN root.
If you use TortoiseSVN, then you’re going to right click inside the root of your checkout, then select TortoiseSVN->Properties. In the dialog that follows, you’ll create a new property named “svn:externals” and give it a value of “wp http://core.svn.wordpress.org/trunk/“. Hit OK to make it stick (note, do not select the recursive option).
What this does is simple, really. It tells the SVN that the contents in the “wp” directory will come from http://core.svn.wordpress.org/trunk , which is the main trunk version of WordPress.
Alternatively, if you’re not brave enough to run trunk all the time, you could use http://core.svn.wordpress.org/branches/3.0, which would make it get the latest 3.0 version at all times (which is 3.0.4 right now). And if you wanted to use a directory name other than “wp”, you could change that as well.
The point being that instead of having to manually update WordPress, you’re telling your SVN server that the contents there actually come from another SVN server. So when you do an “update”, it will go and grab the latest version of WordPress directly, without having to updated by hand.
After you’ve modified the externals setting for that root directory, you have to do a commit, to send the new property to the SVN server. Then you can do an update and watch it go and grab a copy of WordPress and put it into your directory directly.
So now we have a WordPress setup, but it’s not installed. No worries, but we’re going to make a custom installation here, so we’ll hand edit the wp-config file eventually.
Why are we doing this? Well, we want our wp-content folder to live outside of the WordPress directory. It’s going to contain our custom plugins and themes and so forth. That way, no changes to WordPress’s files in their SVN can ever touch our own files.
So we need to make a folder in the root called “custom-content”. Or whatever you want to call it. Since this name will be visible in your HTML, you might want to choose a good one.
Now inside that folder, make a plugins and a themes directory. For the themes, you’re probably using a custom theme for your site, and you can just put it in there directly.
Plugins are a different matter.
Plugins as Externals
I assume that whatever plugins you are using are coming from the plugin repository. Or at least, some of them are. For your custom ones, you can do pretty much the same as the themes and just drop the plugins into your plugins directory. But for plugins from the repo, there’s a better way.
In much the same way as we made the wp directory an external pointer to the core WordPress SVN, we’re now going to do the same for our plugins.
So step one, choose a plugin you want. Let’s choose Akismet for a demo.
Step two, in your plugins directory, do the SVN Properties thing again, and this time, add this as an svn:externals of
“akismet http://plugins.svn.wordpress.org/akismet/trunk/” to get the akismet trunk.
Step three, commit and update again, and voila, now you have Akismet.
But wait, we might want more than one plugin. Well, we can do that too. Let’s add the stats plugin.
Step one, go back to the SVN->Properties of the plugins directory.
Step two, edit the existing svn:externals setting. This time, we’re going to add “stats http://plugins.svn.wordpress.org/stats/branches/1.8/” on a new line. Basically, you can have as many externals you want, just be sure to put each one on a new line.
Step three, commit and update and it’ll download the stats plugin.
Repeat for all the plugins you want to keep up-to-date.
You’ll note that I used a branch of the stats plugin instead of the trunk. That’s because the trunk isn’t the latest version in the case of the stats plugin. Not every plugin author treats the trunk/tag/branch system the same, so you should investigate each plugin and see how they keep things up-to-date with their setup.
Note that I am using a wholly custom theme, but you might not be. Maybe you’re using a child theme of twentyten. Themes exist inside an SVN too, and you can create externals to them in the same way.
For example, in the themes directory, you could set svn:externals to “twentyten http://themes.svn.wordpress.org/twentyten/1.1/” and get the twentyten theme for use. Any theme in the Themes directory should be available in this way.
Now we need to create our wp-config.php file. Grab a copy of the sample wp-config file and put it in the root. Yes, not in the wp directory. WordPress looks in both its own directory and in one directory above it, so having it in the root will still allow it to work and will keep the wp directory untouched.
Edit the file, and go ahead and add all the database details. Then add these lines:
You’ll need to use your own directory names and URL, of course. The purpose here is to tell WordPress that the wp-content directory isn’t the one to use anymore, but to use your custom content directory instead.
Because we’ve installed wp in a subdirectory off of what will be the root of the site, it would normally be referenced as http://example.com/wp/ which is undesirable. So I crafted some simple .htaccess rules to move the “root” of the site into the /wp directory, and still have everything work.
The Options -Indexes just turns off the normal Apache directory indexing. I don’t like it when people try to look through my files.
The rest basically rewrites any URLs for directories or files that don’t exist into calls to the /wp directory, without actually modifying the URL. The rewrite is internal, so the URL remains the same. This has the effect of moving the root to the /wp directory, but still allowing calls to the custom content directory to serve the right files.
After you’re done, save the file, and commit everything you’ve done so far.
Running it on the site
At this point, you should be capable of going to the site and loading up all that you’ve done onto it. So SSH in (or whatever) and do a checkout of your new SVN setup into the proper location for it. You may need to rename your existing public_html directory and/or set proper permissions on it and such.
If you’re setting up a new site, you’ll be able to go to it and have it create the database tables and such as well.
What’s the point?
Okay, so you may have read through all this and wondered what the point was. Well, it’s simple, really.
Go to your server, and do “svn up public_html”… and then watch as it proceeds to update the entire site. WordPress, plugins, themes, your custom files, everything on the site. The externals makes WordPress and the plugins and such all update directly from the WordPress SVN systems, allowing you to do one command to update them all.
If you didn’t use trunk, then updating is only slightly harder. Basically, you just change the externals to point to the new version, then commit and do an svn up.
In fact, if you want to live dangerously, you can hook everything to trunk and then have it automatically do an svn up every night. Not many people recommend running production sites on trunk, but for your own personal site, why not? You’ll always get access to the latest features.
An additional thing to keep in mind is that with a system like this, the files on the site are always backed up on the SVN server. For things like inline file uploads, you’ll need to log in every once in a while and do “svn add” and “svn commit” to send the new files to the SVN server, but for the most part, everything on the site will be in your SVN and you can work with it locally before sending it to the site proper.
And it’s expandable too. You can get your sites files from any host that has svn on it. You could run more than one webserver, and have them on a rotation or something. There’s a lot of possible configuration methods here.
I recently acquired a short domain name, otto42.com (the otto.com domain is owned by a German company, and I use Otto42 as my alias a lot on sites as “Otto” is usually already taken). So I decided to use it to make my own URL shortener.
I looked at various methods for this, including simply writing my own (honestly, it ain’t that hard), but I wanted to see what was already available first.
First thing I looked at was the shortlinks system built into Google Apps. I’ve used it before, and it’s fairly nifty. They even have an API available for interfacing it to other things. And hey, the redirections would be served up by Google’s servers, which you can’t beat for reliability. Sadly, after screwing around with this for a while, and trying out some example code, I was totally unable to get their API to work. The whole thing is written in Python, which I have an intense dislike of (whitespace my ass!), and when trying to access the thing via direct calls, it gave me nothing but errors and annoyances.
So I searched around a bit more, and was relegated to building my own, when a tweet by @ozh mentioned that he’d put a blog up on yourls.org. This looked promising, as I know Ozh is active in WordPress, and so of course it would have a plugin. After investigating, I went with it. It works pretty well, actually.
How to do it
First thing I did was to point my short domain at a directory on my hosting account. If it’s going to run code, it needs to have a place to do it from. So I made a yourls directory and pointed the domain to it using my hosting control panel.
Next, I grabbed a copy of the yourls code and installed it there. 300+ files to FTP? Yikes. Complex. A quick bit of reading told me that it needed a database and a config file. Very similar to WordPress in this respect, except the config file resides in the includes subdirectory for some reason. Not so obvious, but whatever.
I toyed with the idea of using the same database for yourls that I already use for WordPress, but ended up creating another one for it. I’m now thinking that it might be worth merging them though, as that way, VaultPress would probably back up the yourls tables too.
Installing the WordPress plugin is a snap. Just find it in the Add New Plugin interface and hit install. After Network Activating it for all my sites, I went to configure it. I had to configure it on each site separately, but no big deal.
Configuration is fairly straightforward. Tell it URL of the API interface, give it my username and password, and voila. Worked first try.
There’s a bunch of Twitter stuff there as well which I only set up to make it stop bothering me about it. I don’t want this plugin to send out my tweets on new posts, as I already use my own Simple Twitter Connect for that. Still, it bugs you with an error message if you don’t set it up, so I did. Thankfully, there’s checkboxes to turn the autotweeting on and off, so I just leave these turned off. Honestly, I think this whole Twitter thing should be removed from the plugin, but I can understand the “easy” factor here for new users. Making them totally optional would be a nice enhancement though.
At first, I was confused because when I turned it on, I saw no way to make it back-populate my old posts into the shortener. Turns out I didn’t need to, it started doing it all by itself shortly afterwards. I think it actually does shortening on an on-demand basis, creating a shortlink whenever there isn’t one already there for a post.
The plugin also hooks into the Shortlink API, meaning that my Twitter plugin will automagically use the new shortlink. You can see that the shortlink box below this post has the otto42.com shortlink in it. I had to make zero changes to make that work. Isn’t interoperability fun?
One other thing I did have to do was to turn off the old wp.me shortlinks I used. These are provided by the WordPress.com Stats plugin, and there’s a checkbox in its options page to turn them off. No big deal.
So yeah, if you have a short domain and want to make your own shortlinks, then YOURLS is a pretty good choice. I haven’t played with the stats gathering part of it yet, for the simple reason that I only just turned it on and thus have no stats to view. Still very easy to do, on the whole. Of course, if it could be entirely a WordPress plugin, then I might think it much cooler.
Update: There is a minor problem in the way the YOURLS plugin handles the WP Shortlink API. I’ve reported it upstream, hopefully it can be fixed soon. Still, it’s a minor issue. The workaround for now is to call wp_get_shortlink(get_the_ID()) when you want to get the shortlink for a post inside the Loop.
I’m about half done with this, and just wanted to give an update to those people I know who are awaiting it.
I’m ditching the multiple-plugin thing. Too many complaints and too much confusion. Also, the plugin directory and updaters don’t support it well. So 1.0 will have a checkbox area where you can select the pieces you want instead.
Login works. Register needs some more work.
Automatic publishing now works for both Fan Pages and Applications! I just worked out how to make Application posts through the Graph API properly. Manual publishing isn’t quite there yet.
Widgets are largely unchanged, but will all be rolled into one sub-module.
Fan box got replaced by the Like box, which is the same thing with a different name. So I’m going to keep calling it the Fan Box in the interface.
The bookmark widget is going away, because it doesn’t work properly anymore anyway.
New widgets for the Facebook Social Plugins are working.
Like and Share will remain unchanged, although the Like now uses the XFBML to do its thing. Doesn’t really make a whole heck of a lot of difference, though.
Comments pull-back from Facebook is possible. I know how to do it. I’m debating whether or not to turn them into “full-fledged” comments or just display them separately.
Comments push *to* Facebook is also possible. Meaning that if somebody leaves a comment using FB and clicks the share checkbox, it will send it to Facebook (no popup) and also include the text of their comment (or an excerpt, at least). This is not done yet, but it’s actually quite easy to add now.
All dependence on the FB-Connect library will be gone. Ditto for their PHP library. I’m writing this with pure calls to the Graph API and XFBML. PHP 5 is still required, and there’s still an activation check for that.
One last thing: Upgrading from old versions to the new one will be a hassle. Things will just stop working properly when you upgrade. Can’t be helped. So I recommend deactivating SFC and all sub-plugins entirely before upgrading, then reactivating it afterwards. There will be a note to this effect on the WP plugins screen.
Google Apps has always been a bit of a black sheep in the Google account system. If you had an email on a Google Apps system, then it was kinda like a Google account, except not really. Some of the features were the same, some were not. What made it more confusing is Google’s tendency to create a separate Google account using your email address, which meant data sharing across the two was broken and tricky to work with. So most users ended up maintaining two separate Google accounts, which annoyingly had the same email address/username (unless you added GMail to one, in order to get access to Buzz, which then made it forced to have a gmail account as the primary email).
But recently, Google has been making efforts to pull these systems together into a more unified whole. They started off with the multiple account sign in features, which works, but is pretty lame. Having to choose which account you’re on throws all the complication back on the user.
A better way is to simply make all Apps accounts into full-fledged Google accounts. They’ve taken this step and now (some) Google Apps administrators can choose to integrate their Apps account into the larger Google account-o-sphere. I did this the other day, and while it’s taken a bit of effort, I’m now starting to pull all my information over into this new, fully-capable, Google account.
So this post is just a few notes on the process of migrating from two accounts to one, as I do it. Note: This is disorganized and random. I’m just making notes here. Read them if you like.
– Don’t use the multi-sign-in thing. It makes things really confusing.
– Change your passwords on one of the accounts. I noticed that when I had the same password on both of them, sometimes I’d log into a Google property and it would log me in using the wrong account. With different passwords, that stopped happening and I started getting in on the correct account, based on the email I gave, every time. Basically, it appears that the migration process changes your old GMail-account which was tied to your old non-gmail based address to use an account on gtempaccount.com. Using this, it can still recognize your old email address as being on that account, if the password fits. By having different passwords, it can’t do that and thus you get the correct account for the email you’re signing in as.
– YouTube accounts can be delinked from one Google account and relinked to the other Google account. Check the account settings page on YouTube. Yes, I know they say YouTube won’t work on the Apps accounts. It does. I did it.
– Google Voice accounts *CAN* be transferred to non-gmail based Google accounts. This link works: http://spreadsheets.google.com/viewform?formkey=cjlWRDFTWERkZEIxUzVjSmNsN0ExU1E6MA . Even though it says there that it will not work with a Google Apps account, it *will* work if you’ve migrated your Apps accounts into the general system. I did it, and if you do it, make a note saying that the account migration had been done. They transferred it over just fine. Took about an hour for me. Probably will take longer for them to get to you.
– Chrome Sync works on the new accounts, just go into Chrome, disconnect the sync, then reconnect it to the new account.
– If you use Reader, you can export your subscriptions from one as an OPML file, then reimport them to the new Reader account. Although your followers *seem* to transfer, there may be an issue there as I always get errors when commenting on shared posts.
– Google Talk works fine, but you need to sign it out then back in to the new account.
– AdSense can’t migrate. You’ll have to close your old AdSense account and create a new one on the new account.
– Strangely enough, somehow in this process, Wave got added to my Google Apps account. Which is weird, as I thought they killed that. Not that it matters or anything, just thought it was unusual.
– One HUGE benefit: The new Google Chat. A few days ago, they rolled out “call by phone” to Google Chat. You can call anywhere in North America for free through Google Chat on your GMail. While they didn’t roll this out to normal Google Apps accounts (yet), they did roll it out to migrated Google Apps accounts. I got it in my GMail today and used it to talk to my mom. She said the voice quality was fine. Afterwards, I signed into Google Voice and lo and behold, my GChat was available as a Google Voice forwarding account! So now if I’m on GMail (which I always am) and you call my Google Voice number, I can answer through the computer. How awesome is that?
This is not final. I will be updating this post as needed. I’m just posting it now so that people can benefit from it now.
If you don’t get immediate responses from me for the next few days, that’s probably because I’m not here. As you can tell from my new sidebar badge, I’ll be in Savannah, GA for WordCamp Savannah 2010. I’ll be around the SCAD River Club all of Saturday and Sunday, and also Friday (if they’ll let me hang out, I didn’t sign up for that). Looks like it’s going to be awesome, Jane has really pulled it together nicely.
I will be trying though, and the hotel claims to have internet, but this is going to be my first real road-trip for a WordCamp, so I’ll be mostly unavailable for quick answers like I know a lot of people are used to getting from me. Don’t worry, I will get to you. Eventually.
If you’re coming to Savannah, please make it a point to come and ask me anything you like. I’m looking forward to meeting people and getting to know the community better. My only meat-space connection with the WordPress community has actually been meeting (and working for) Matt, and he’s clearly a biased source.
So enjoy your week, everybody! I know I will!
And I WILL be having dinner at the Crab Shack. This is a requirement.