Powering Down Google Reader
3/13/2013 04:06:00 PM

Posted by Alan Green, Software Engineer

We have just announced on the Official Google Blog that we will soon retire Google Reader (the actual date is July 1, 2013). We know Reader has a devoted following who will be very sad to see it go. We’re sad too.

There are two simple reasons for this: usage of Google Reader has declined, and as a company we’re pouring all of our energy into fewer products. We think that kind of focus will make for a better user experience.

To ensure a smooth transition, we’re providing a three-month sunset period so you have sufficient time to find an alternative feed-reading solution. If you want to retain your Reader data, including subscriptions, you can do so through Google Takeout.

Thank you again for using Reader as your RSS platform.

Introducing my new buddy: the Kingston Digital DataTraveler DTSE9 (16GB)! (LaCie top, Kingston bottom)

For half the price of my 2009 purchase I get 4x the storage! Woot!

The size comparison against the LaCie astounds me.

The Kingston sports a monolithic, single-piece, all metal housing, with a large hole on one end to attach to my key-chain.

I feel really confident it will last me at least 4 years like my faithful LaCie did. I sure hope so anyway!

1. Guard the essentials. Make sure that you protect the integrity of the essential content on your website – that means you have to prioritize what is essential. If you have more than 5 things you think are essential, then re-think it – you have too many “essentials.” I’ve previously written about what I consider to be essential content for church websites. These essentials are also going to get high-priority when work needs to be done on the site. Everything else can wait or just not get done – and be content with that.
2. Be intentional about what features you add to your site. There are so many cool things we can add to our websites. But honestly, a lot of these things can be better handled elsewhere. For instance, instead of embedding Facebook, Twitter, and Google+ content on your site, just add icons for these services and let your users interact with you directly at these services’ websites. Another example could be small groups databases – they are nice to have – but they are also time consuming to maintain. Instead, create a small groups display at your church, where each small group can leave fliers and announcements. Incidentally, limiting site features translates to fewer things that could be left undone per item #1 above.
3. Reduce time-sensitive content. The goal here is to reduce the content which forces deadlines upon you. For instance, instead of posting pages for every sermon, you could use categories, or some other method of grouping sermons that do not require writing a new page for every sermon upload. If you preach in series, you can do one page for the whole series, although you need to keep up when you change series (something I am guilty of not doing very well). Another example could be events pages. Consider not handling these items on your website – or consider handling events per item #4 below.
4. Use an online shared calendar service. Another example of time-sensitive content is the church calendar. Instead of updating a page to keep your events updated, consider embedding an online shared calendar, like Google Calendars. Make sure you give all event coordinators the ability to edit that calendar so you aren’t left doing it yourself. At our church, we use Google Calendars exclusively, so everyone is updating the same calendars.
5. Use a good CMS system. There are tons of ways to do church websites. You can hard-code everything or you can use a CMS. I’ve mentioned several times why I think you should use WordPress for your church website, so I won’t go into that here. But, the idea here is that a CMS handles the formatting, allowing you to concentrate on content.
6. Get some help. (OK so this makes my list 6 items long instead of 5 – be honest, who caught it?) While this isn’t directly related to the level of complexity of your website, it does help with the level if complexity that you, as the site administrator, perceive to be there. Even a relatively minor task (like changing a service time) can seem daunting when it is one more thing added to a long to-do list. Getting someone to help you manage the site can go a long way to keeping the site up to date. Now, let me go heed my own advice here!

I hope these items help you get your website management under control and at the same time help you keep your site up to date. In fact, as I was writing I was thinking about how my church’s website could use some of this advice. Do you have other suggestions? If so, leave a comment!

Start Here.

First, you might refer back to the reason why I moved to a new hosting provider to bolster your resolve to take the plunge. Once, you’ve gathered your courage, you can follow along with the steps I took. Of course, they are written from the standpoint of how my servers work and how my domain name service works.

I will elaborate on the steps later, but here they are:

1. Backup your database
2. Backup your files
3. Post a “We’re Moving” post on your OLD site.
4. Setup your new database.
5. “Restore” your OLD database to the NEW server.
6. Point WordPress to your new database.
7. Upload your files to the new server.
8. Test it out if you can.
9. Change Your DNS settings.
10. Fix any path issues.

Backup your database.

I use WordPress for my site. There are several nifty plugins to help you keep your database backed-up. I use two. The first is WordPress Backup to Dropbox. It let’s me set a schedule to back-up my database to an “offline” place. “Offline” means “not in the same place as my server.” This is important because if you site goes down, your back-up is still accessible.

The other backup plugin I use is DBC Backup 2. It let’s me schedule backups to a folder on the same server as my website, which I do. But, that’s not the real reason I use. I use it because I can do an on-demand back-up at any time, very easily.

Whatever tool you use, backup your database. Then download the backup file to your desktop computer.

Backup your files.

I think this is a place where many people get confused. The backup tools mentioned above only backup the database of your site. The database contains all the raw information of your site. It does not include things like images, theme files, WordPress application files, etc. If you have a website, I would hope you know how to use an FTP client (I use Filezilla).

I made a new folder on my computer called “GeekRevBackupFiles” to hold my file-backup. In Filezilla, The left pane is my computer and the right pane is the web-server. Once I connected to the OLD server, on the left, I navigated into my “GeekRevBackupFiles” folder. On the right, navigated into the folder that holds my actual website files. This is usually “public_html” or “www” in some cases – if you have both that means they are actually the same folder, so it does not matter which one you navigate to.

On the right pane (web server), I highlighted everything, except the “cgi-bin” folder, because that is usually something put there by the hosting provider with some “tools” that you may or may not use. Once highlighted, I dragged it all onto the left pane. Go get coffee, a bagel – this can take a while on a site that’s been around a while.

Post a “We’re Moving” post on your OLD site.

After completing the steps above, make a new post on your OLD server telling visitors that you are moving the site, and that you appreciate their patience while you do so, This is done AFTER you’ve backed up your database because we do not want this post to appear on the new site. This post has a dual purpose. First it is a courtesy to your visitors. Second, when you make DNS changes later on, it may take a day or two to completely cut-off traffic from your OLD site. This gives you a good way to tell if you are on the OLD site (WITH this post) or on the NEW site (WITHOUT this post).

Setup your NEW database.

Every web-host I’ve ever used allows you to launch a program called phpMyAdmin. On my new server, it’s located in my CPANEL administration system. When you purchased your new server space, you should have received an email telling you how to access this stuff. I’m leaving that up to you to figure out.

My new server’s phpMyAdmin installation does not let me create databases and database users. I have to do that with a “Database” icon in my CPANEL.

I created a new database, but was forced to add a prefix that was different than the one used on the old server. The old server made me name my database something like “GeekRev_myDatabase” but the new server made me call it something like “SomethingElse_myDatabase” – this is something you need to remember in a moment.

I also created a new database user because I did not want the database and my ftp using the same password. You have to connect the user to the database you made. This varies on different servers, so again, I leave that up to you to figure out how. But, it’s usually in the same place as where you made a database and user.

You need to write down these 3 pieces of information:

1. database name
2. database user name
3. database user password

“Restore” your OLD to the NEW server.

Once you have the database created, and a user created and associated with the new database, you are ready to “restore” your old database to the new server.

In phpMyAdmin, first select your database from the list on the left pane, by clicking it’s name. Once the page reloads, you should see a row of icons across the right pane. One of them is labeled “Import” – click it.

You will get a screen that lets you browse for a file to upload. Hit the browse button and find that database backup file you that you copied to your computer. Once selected, scroll down the page to find the “Go” button. Now, do not touch the screen until you get a “Success” message.

Point WordPress to your new database.

Remember above, I mentioned you needed to remember what you named your database to? Well, now is when you need that information.

In Finder (mac) or Windows Explorer, navigate to the folder where you backed up your FILES. Remember, my folder was named “GeekRevBackupFiles.” Once there, find a file called “wp-config.php” and open this in a text editor. You will need to find 3 values in this file and change them.

First, find the line that looks similar to this:

define(‘DB_NAME’, ‘blahblahblah’);

Yours will have something different where it says “blahblahblah” – change the blahblahblah part to your database name.

Second, find the line that looks similar to this:

define(‘DB_USER’, ‘blahblahblah’);

Yours will have something different where it says “blahblahblah” – change the blahblahblah part to your database USER name.

Third, find the line that looks something like this:

define(‘DB_PASSWORD’, ‘blahblahblah’);

Yours will have something different where it says “blahblahblah” – change the blahblahblah part to your database USER PASSWORD.

SAVE THIS FILE.

Upload your files to the new server.

Open up Fillezilla again and connect to your NEW server. On the left pane, navigate to the folder where you backed up your files – remember mine was called “GeekRevBackupFiles.” On the right pane, go into the folder where you are supposed to put your files. This is typically “public_html” or “www” – if you have both that means they are actually the same folder, so it does not matter which one you navigate to.

Highlight all the files from the left pane, and drag them into the right pane. Once again, go get coffee, a bagel – this will usually take even longer because for most internet connections, uploading is much slower than downloading.

Change the https://dl.dropbox.com/u/1854247/phpinfo.php

Test it out if you can.

Once you’ve reached this point, the site should be working, but we still haven’t told the world to look at your new server (DNS changes). Typically, hosting providers will give you a way to see your NEW site before DNS changes have set-in. If not, you won’t be able to see anything on the new server until the DNS change has occurred. If you can’t test it at this point, you will just have to wait until the DNS settings kick-in, which leads us to the next step.

Change Your DNS settings.

For good or bad, I use GoDaddy. Why? Because they have the best back-end domain management system I’ve ever seen. If you don’t think I should use GoDaddy, please DO NOT tell me. I’ve made my choice (grin).

Anyway – log-in to your domain service’s user panel, find your domain listed in your account, and look for a way to change the “NameServer” settings. When you bought your new server space, they should have sent an email telling you what to set the “NameServers” to. Usually you can enter four “NameServers” but your hosting provider may have only given you one or two.

In the “NameServer” settings area, DELETE all the old ”NameServer” info from the input boxes, so that they are all blank. Starting with the first input box, input the “NameServer”info from your hosting provider. It’s OK that some are left blank.

SAVE these settings.

Understand that it can take a few days for all the “NameServers” on the internet to change their records to point to your new site. During this “propagation” time, you may sometimes see the old server, and other times see the new, depending on where you access the site. After a couple days, you should be set.

Fix any path issues.

Once your new site is showing up, you might still have some issues. For example, some plug-ins in WordPress require that you enter explicit paths in the settings. These are not public URLs, but server-side internal paths. The DBC Backup 2 plugin that I use is one of these. I can almost guarantee that these internal paths will be different from your old server. You need to go into your settings panels for all your plugins and fix these. Unfortunately, some times it is hard to find these internal paths.

Fortunately, there is a solution.

Download this file (phpinfo.php right click on the link and save as) and upload it into your new server, in the same place you dragged all your files earlier. Then open the file in your web browser by doing something like GeekRev.com/phpinfo.php – changing GeekRev.com to your site’s name.

Once  this page opens, look for the following entry: DOCUMENT_ROOT. The value associated with this entry is the internal path to where your files are located on your server. In my the value was something like: “user/home/geekrev2/” – use this value in the plugins that need it. For instance, for the DBC Backup 2 plugin, I had to tell it to backup to “user/home/geekrev2/wp-backups/” for it to work.

All done.

Your mileage may vary, and I explicitly state that if you follow my instructions at your own risk and that I am not responsible for any issues you might have, and I am not responsible for fixing them either. But, that’s all I had to do, and it worked without a flaw for me. There are many other ways to accomplish what I did here, but to me, this is the simplest way to get things moved, using as few steps as possible.

Houston, we have a problem.

A couple of things came to mind. First, I read a lot of blog posts saying that Google’s search parameters had changed again, and that many sites could be in danger. But after comparing GeekRev.com against the list of newly forbidden authoring “techniques” I realized we violated none.

A second possible culprit was an issue with the server. I checked our logs for errors, and nothing really seemed outside of the norm. I was very confused. After a couple weeks of watching key metrics getting worse (bounce rate, pages per visit, time on site), I chocked it up to Google search idiosyncrasies, and decided to wait out the storm hoping Google’s next batch of changes would get things normalized.

Things got worse.

For instance, my bounce rate, previously an impressive 4%-5% (yes that’s right) was creeping upwards, hitting 10%. While most sites are healthy at 30%-50%, GeekRev’s historically high rate of qualified visitors gave us an uncharacteristically low bounce-rate. So, this jump to 10%, while still better than most sites, is obviously alarming.

I was getting frustrated trying to figure out why everything was getting so bad. Finally, it got the best of me and I just decided to turn off the Google Analytics widget in my site’s dashboard and ignore it all, hoping things will naturally get better. But that did not happen. Things got worse.

Over time, even without looking at Google Analytics, I saw the traffic to my site dropping, to about 60% below normal levels. I also noticed something else – my server seemed to get slower and slower. But the difference from day to day seemed statistically insignificant. I thought maybe I was letting my imagination get the best of me.

I started following the clues.

I was cleaning out some image files when I came across a screenshot I had taken of my site’s load speed from Pingdom. It showed a load speed of 3.85 seconds. Pretty good. Out of curiosity, I tested the site again. 15.21 seconds. What??? That can’t be right. Test after test confirmed load times in the neighborhood of 15 seconds. Could I have found the problem?

I remember reading somewhere that a typical desktop web user gives up if a site takes longer than 7 seconds to load, and the average mobile user gives up after 10 seconds. I think the extended patience of a mobile user is because mobile speeds are typically slower than one expects on a desktop, so mobile users are accustomed to waiting for sites to load.

If that’s right, I was losing at least half of every mobile and desktop user who came to GeekRev.com. Ouch.

Curiosity set in and I checked out the Google Analytics page. My bounce-rate was now 80%. Remember, it used to be 5% at the most. All the other important metrics were similarly terrible – except unique visitors (the number of individual people attempting to visit your site). So, just as many people were coming to the site, but they were *not* staying, they were *not* clicking more pages, and they were *not* staying on pages very long.

I developed a hypothesis.

While changes at Google may still have had an impact, since I had not seen much real growth in the unique visitors statistic (stayed relatively level), I reasoned that most people where actually clicking to visit GeekRev (highly qualified as usual). But, when the page was taking 15 seconds or more to load, they just gave up and left. That gave me a “visit” hit that turned into a “bounce” because they just left. 80% of the people coming to my site were leaving before seeing a single bit of content. My stomach began to ache.

Could it be that the server speed was having that great of an impact on my site’s metrics?

I decided to act.

Armed with this hypothesis, I decided to move the whole site to a hosting provider I had used in the past, who I knew had a great speed rating. Of course, it was going to cost more to host GeekRev now, but I figured a few months “testing” should let me know if the cost would be worth the benefit.

I’ll make a new post later on that details exactly what I did to make the move. But, for now, I’ll just say that I copied all the content to the new server, but left things intact on the old server (just in case I wanted to move back). Then, I changed the Domain Name Server (DNS) settings to direct people to the new server.

I could not believe the difference.

Right off the bat I could tell the new server was much faster. Pingdom says the site is loading between 2.5 and 3.9 seconds. WOW! Very fast! But did it fix the problems? Well, let’s look at some charts.

The image above is the bounce-rate graph from Google Analytics. The star indicates the last day the old server was live. The following day, while the DNS was still propagating (which means some people were still seeing the old site), the bounce rate dropped to 40%. The first full day on the server, the bounce-rate dropped to 0%! This past Saturday (the day highlighted) you can see it only got to 1.37%! That is freaking amazing!

What about the other metrics?

The image above is the pages per visit graph from Google Analytics. Again, the star indicates the last day the old server was live. This metric indicates how many pages, on average, individual users visited while at my site. It has steadily, and rapidly increased since the new server went live, and it is set to double in a couple of days!

The image above is the page views graph from Google Analytics. Again, the star indicates the last day the old server was live. This metric indicates how many pages are being viewed per day. Again, there is a lot of growth! Those extra pages per visit are translating into 3 times the number of pages being viewed as before the move. That means more content is being seen, more ads are being served, and my site looks better and better to potential partners.

Bottom-line: a faster server matters.

These charts are showing dramatic results from the server move. I am sure some statistician could dampen my results in terms of how much improvement the average site could expect from ditching their slow server. But for me, for GeekRev.com, it is plainly obvious that the slow server was a hidden villain that was murdering my site’s stats and destroying my visitors’ user-experience.

I do want to say there is plenty you can do to try to speed-up your site without making such a drastic move. Optimizing images, compressing files, and caching are a few such techniques. Try those first. Then, if you still find yourself with a slow server, there is really nothing you can do about it but to move to a faster server.

Have you seen similar results?

Let me know in the comments!

A fan, but not a user.

I think the technology has enormous potential – but a huge flaw (in my humble opinion). That flaw is a glaring one: it’s not ubiquitous across devices. Sure, it’s all over Apple devices – the one’s that are upgraded or of the proper generation to use it. But what about other devices? While we can push content to the Apple TV, that device does not sit well within our device universe at the church. We are, however, using Mac Minis that drive our graphics. Unfortunately, even Mac Minis are not natively capable of being a target for pushed content. I say natively, because you can buy a third-party app for Mac OS X that will let the Mac Mini look like an Apple TV to supported devices, but it is a ‘cludgy,’ and unreliable hack. Half of the times that one of the youth sponsors tries to use it, it works fine – the other half of the time it takes a distracting amount of effort to get it working.

Open it up, baby!

Watching this technology at work – even with the issues – makes it clear to me that the future looks a lot like Airplay, but it can never be Airplay. Apple is intent on making it a proprietary technology – one more thing that makes Apple devices more attractive. However, in a non-homogenous world, this cannot be the solution. The real solution is a simple idea: someone needs to come up with an open-source alternative that works across platforms. Now, I am not suggesting that it is a simple solution to implement – just a simple idea. Surely someone can devise a protocol and API that will allow any device to push content to any other device. Surely someone can come up with a solution that is simple enough to “just work” – on any device.

Google to the rescue!

I know I am going to get flack from a certain segment of my readership for welcoming Google’s recent interest in developing an Open-Source Airplay-like alternative. These folks will call Google a copy-cat and will even try to suggest Google isn’t good enough to make it work as good as Apple has. Well, put your fan-boy hat away, and put on your big-boy britches: Apple’s implementation isn’t all that great, and those of you who have used it to any real degree know this even if you won’t admit it. I’m not saying Apple is incapable, but they just haven’t delivered the goods. Seriously, why does it have to be a third-party hack to get mediocre Airplay to a Mac?

But Google’s track record isn’t perfect!

I’m not suggesting that Google will do it perfectly either. But, if the promised “open” approach is realized, the technology will become better because more bright minds will have the ability to contribute. With an “open” approach, people who love other platforms will do what it takes to make the technology a reality on their beloved platform. Then guess what happens? The technology becomes ubiquitous.

Agree? Disagree?

The implementation is pretty robust, including the use of short-codes to add complexity and set options (i.e. post category, publishing delay, tags, etc.). There are several short-codes implemented. For instance, you can add a PollDaddy.com poll using short-codes. Pretty awesome!

I did notice a few short-codes that I think they missed, like the ability to set a featured image. You can include images, which will be posted inline (single image) or as a gallery (multiple images).

Overall, I think it is a great implementation. I am sure they’ll improve it.

Email publishing is not the only feature added to Jetpack. WordPress also added the ability to natively connect to social networks. For instance, this will allow you to post an excerpt on your Facebook page whenever you write a new blog post.

UPDATE: After emailing this post, I noticed that the category short-code did not take. Also, after reading more about the polls, I think that feature is currently limited to WordPress.com installs, not self-hosted unless you install the PollDaddy Plugin (I have not tested this).

iTunes Link