Moving From Self-Hosted WordPress to WordPress.com

Most people want to move from a hosted WordPress,.com site to a self-hosted WordPress.org site. I went the other way. here’s why and how I did it.

Most people move from the hosted WordPress.com to a self-hosted WordPress (WordPress.org) site. They want the flexibility of a self-hosted WordPress site. In my case I’m going the other way. I’m moving my self-hosted WordPress site to WordPress.com.

Why am I doing this:

  • Simplicity – everything comes from WordPress and is hosted by them. I don’t have to worry about an update to WordPress breaking my theme or a plugin. WordPress.com won’t be perfect, but it is simpler.
  • No more updates – I’m paranoid and want security updates applied immediately. Even if the updates aren’t security related (although it seems most are these days) I hate running old software as I figure there’s a landmine in there just waiting to blow up on me. It seems like there’s a never ending string of updates these days so I spend more time doing maintenance than I do writing or exploring. it doesn’t help that these updates seem to arrive at the worst time.

Some “gotchas”

  • Technically, photos are not exported. They are imported if the old site is online and the photos are accessible by WordPress.com
  • Photos that use relative URLs in posts will not be imported because WordPress.com cannot find them. They must include the full URL.
  • Some of my photos did not get “attached” to the post although they still appeared in the post. This is more a media library management issue. It’s not something that affected me but it may affect you if you really need that mapping. They can be manually attached after the import. See step 8 for more information.
  • If you use the JetPack plugin on your self-hosted site and you want to migrate the data contact WordPress.com support. They can probably migrate the data. I did not use JetPack so did not deal with this.
  • It will cost $13/yr. to map your existing site domain name to the new WordPress.com site. This will allow all exiting external links to still work and search engines will not have to process and re-directions or site renames.
  • If your existing domain is used for anything other than your WordPress site you may need to research the DNS setup. WordPress.com provides good documentation and automation for using Google Apps email along with several other email providers. I use Google Apps for email. I don’t include those instructions here because the WordPress instructions worked fine.
  • There will be a DNS change at the end. To speed this up you may want to lower the TTL for your old sites DNS entries a couple days before making the change. This isn’t critical but may speed things up. I set mine to 30 minutes.

Doing the Move

So here’s the basic process I followed to move this site. The screenshots are from a blog I used to test this process (BWOTAE.COM).

I initially did all my testing and site design on a test blog with a small number of posts and comments. This meant that there was minimal time between when I imported the full site and I actually cut over since I already knew the settings I wanted and the tweaks that would have to be made.. This is recommended.

  1. You’ll need to create an account at WordPress.com, if you haven’t already.
  2. In your WordPress.com account select the “Create Another Blog” button in the “My Blogs” section of your account.
    Screenshot showing the create new blog selection
  3. On the next screen enter an address for your blog. Since we’re moving a blog that already has a domain name this isn’t very important. Do not enter your current blog address. We’re going to transfer the domain name along with the blog. But we need a WordPress.com sub-domain to get going. The first screenshot shows that the address I wanted is already in use.
    Screenshot showing my first selection is in use
    My preferred name is in use, but that’s OK

    Once I pick a name that’s available at WordPress.com I select the option to keep my blog private which means users will need a logon ID to see it. This will be changed once the site is ready to go on WordPress.com.

    Then put in the name of your blog. This can be changed later, so you may want to name this slightly different than your other site so that you don’t get confused during the migration, but other than that there’s no reason not to use the same name as your self-hosted site.

    Then select the “No thanks, I’ll use the free address” selection.

    screenshot showing the initial blog selections
    Pick any available name, make the site private (for now), use the name from your self-hosted site and then use the free address.

    Scroll down the screen and click the “Create Blog” button under the “WordPress.com Beginner” column. You can pick one of the packages if you absolutely know you want all the features. You can add these features later at the same bundle price if you want. There’s no benefit to picking them now. Personally, I do not use the bundles since the add-ons I want cost less than the bundle.

    Screenshot showing the "Create Blog" selection
    Go for it! Create the site
  4. You’ll receive the confirmation message once the blog is created (almost immediately). You can click “Visit your dashboard”
    screenshot of the confirmation message
    Success!

     

  5. Check your privacy settings, You don’t want visitors and you don’t want your site indexed until it’s ready to go. Go to “Reading” under “Settings” and verify that the site visibility is private.
    screenshot showing the private setting
    No guests or search engines allowed.

     

  6. Now go to the Dashboard of you old site, the one that’s self-hosted. Go to the “Export” section under “Tools”. Verify “All Content” is selected as the items to export. Then download the export file.
    screenshot of the export settings
    Export everything

    You’ll be prompted to save the file. I just use the default name and save it to the desktop to make it easy to find. Just remember the name and location.
    screenshot of the file save dialogDo not shut down your old site or change the domain name. The site must remain online to import the photos and images.

  7. Once the file is saved, go back to your new WordPress.com site dashboard. It’s time to import. Select “Import” under “Tools” then click “WordPress as the import type.
    screenshot showing the import types
    Select WordPress as the import type.

    You’ll be prompted to select a file. Select the file you downloaded in the previous step and click “Upload and import”.

    screenshot showing the import file selection
    Pick the file you just downloaded and upload/import it.

    You’ll be prompted to map any authors. This does not mean the authors have any actual posts, just that they are set up as users. Map them as you see fit, which is probably all to your WordPress user. Click “Submit” when you are ready. As previously mentioned your old site must be online so the photos can be imported.

    screenshot showing the assigned authors
    Map your authors.

    You’ll be told that the import is running. Depending on the blog size and current WordPress.com load this may take several hours. (Up to 24 per WordPress.com).

    screenshot of in progress status
    Now we need to wait for the completion email

    You’ll receive an email when the import is done. You may see posts and data appear before the email but be patient and wait for the email, it is still working to import and link things up.

  8. Photos seem to be the biggest import problem area, both in my testing and in the forums. After the import go to the “Media” section (of the new WordPress.com site) and select “Library”. Some things to check:
    Is the number of photos close to the number in your old site? Note that unused photos will not be imported.Do you have a lot of unattached photos? Is this more than what your old site had?

    screenshot iof the media library
    Any unattached photos?

    If you have a lot of new unattached photos you may want to contact WordPress.com support through the forums. In my case the difference was minimal and I didn’t meed them attached. They were in the library and appeared in the correct posts.

  9. Before you start cleaning things up go to “Settings” then “Discussion”. Uncheck “Attempt to notify any blogs linked to from the article”. You do not want to notify blogs just because your cleaning things up. You can turn this back on once the new site is live.
    13-NoNotifications
  10. At this point you want to pick your theme and site design and verify your settings. Then go through your posts and make sure they look OK. Due to the volume I mainly just checked the most recent year and the posts that get a lot of visitors. Your old site should still be up and running. If you post articles or get comments on the old self-hosted site you will need to transfer them over.

Once your new WordPress.com site is ready to go “live” here are the steps.

  1. If you use the JetPack plugin on your self-hosted site go in and disconnect it from WordPress.com. If you don’t do this the old site will remain in your WordPress.com dashboard.
  2. Now we need to buy the domain mapping. In the dashboard of the new WordPress.com site select “Store” then click the “Buy Now” button for “Add a Domain”
    screenshot showing buying a domain
    Go to the store and Add a Domain

    Then select “Map a Domain Name You Already Own”

    screenshot showing order type
    Map a domain you already own

    Enter in the domain name used for your self-hosted site.

    screenshot showing domain entry screen
    Enter in your domain name

    Even though you already said you’ll be using your already owned name you’re told the domain is in use. Verify you didn’t make a typo and then select the option to use the domain.

    screenshot showing the domain already taken screen
    Pick the selection to use the domain.

    Complete the wizard to purchase the domain mapping option.

    The domain will be made the primary domain for your site. If you need to change it you can select “My Domains” under the Store section of the dashboard.

  3. You’ll need to change the DNS servers for your domain. This varies by registrar but the domain servers should be ns1.wordpress.com, ns2.wordpress.com and ns3.wordpress.com. It may take some time for the DNS change to propagate. I’d recommend leaving your old site online for a couple of days to avoid people getting a site not found message.
  4. Time to go public. Navigate to the “Settings” -> “Reading” section of your new site and change the Site Visibility to “Allow Search Engines to index this site”.
screenshot of site visibility
Go Public!

Now your new site is alive an in public. You’ve moved from self-hosted WordPress to WordPress.com hosting. An external links will go to the correct page on the new site, no redirects needed.

Adding A Trusted SSL Certificate

I’ve been using a self-signed certificate for years in order to encrypt my admin traffic to my websites. Some of my integrations have had problems with self-signed certificates, wanting a trusted certificate. Most had a work-around but I finally decided to bite the bullet, spend some money, and get a trusted certificate from a respected certificate authority. Here’s the setup, completed on a Sunday afternoon.

Up until now I’ve only used SSL on my web server to encrypt my WordPress admin traffic. A self-signed certificate was fine for that since I wasn’t worried about confirming the identity of my server. But recently I’ve had a couple situations where I wanted integration that required a trusted certificate (one issued by a recognized certificate authority). I’ve been able to implement work arounds but they seemed to compromise security, if only by a little. So I decided to go out a get an “official” SSL certificate.

I’ve been considering it for awhile. I’d basically decided on DigiCert to provide the certificate long ago. They came to my attention, along with a lot of information about certificates in general, while listening to Steve Gibson’s Security Now! podcast. In 2011 he was shopping for a new certificates provider and talked about it over several episodes over a couple months. They aren’t a bargain basement shop, but they aren’t outrageous either.

What I Have Now – What I Want

I have a VPS server with Linode with one IP address and a self-signed certificate used by all sites on that IP address. I want to get to a configuration where one of those sites uses a trusted certificate and the others continue to use the self-signed certificate.

Implementation – Pulling the Parts Together

1. First step is to add an IP address to my server for the new certificate. There are certificate types that can secure multiple websites on one IP address, but I’m only buying the certificate for one site. So I need one IP address for the self-signed certificate and one for the trusted certificate. Linode requires a support ticket to justify the new IP address. There were some forum threads that said this was a difficult process. Maybe it’s because I only need 1 extra IP, but it was fast and simple. I just said I was adding a SSL certificate. I had the new IP address about an hour later (on a Sunday).

2. I followed these instructions to add my second IP address once it was assigned. The only difference from the instructions was I did list the gateway for the second IP address and I needed to reboot the server to recognize the new IP address. Cycling network services wasn’t enough and in fact displayed a message that it might not work.

3. Next I needed to get the SSL certificate. I removed domain privacy on the domain for which I was getting the certificate in order to streamline the proof of ownership. I did restore privacy once the certificate was issued. I followed DigiCert’s instructions on Apache. Those instructions include a tool to create the Certificate Signing Request (csr). When I used the tool it recognized I wasn’t their customer and offered a 30% discount along with an extra 60 days. So if your planning multiple purchases be sure to try the big one first, the offer hasn’t come up since I bought my certificate. The tool generated a command line I had to run on my server to create the csr. After running the command I copied the generated .csr file to my local computer, opened in in a plain text editor and pasted the contents into the DigiCert certificate order form. Since it was Sunday, and DigiCert says they don’t offer support on Sunday (except for emergencies), I didn’t expect a response. Instead I go one a short time later asking for supporting documentation to prove who I am and I sent that along. I had the certificate about 2 hours after submitting the order.

Implementation – Adding the SSL Certificate

1. At the time I generated the CSR (step 3 above) it also generated my private key which needs to be protected. I’ll keep the private keys in /etc/ssl/private which is the default location on my Debian 6 server. So I copy the file there and make sure it’s only accessible by root.

sudo mv /path/to/file/www_mydomainname_com.key /etc/ssl/private
sudo chown root:root /etc/ssl/private/www_mydomainname_com.key
sudo chmod 600 /etc/ssl/private/www_mydomainname_com.key

2. I’ll keep the actual certificates in /etc/ssl/certs which is also the default location on my Debian 6 server. Once I received the certificate from DigiCert I copied it to my home directory on the server then moved it to the /etc/ssl/certs directory and made it accessible only to the root user.

sudo mv /path/to/file/www_mydomainname_com.crt /etc/ssl/certs
sudo chown root:root /etc/ssl/certs/www_mydomainname_com.crt
sudo chmod 600 /etc/ssl/certs/www_mydomainname_com.crt

So now the certificate is in place. It’s time time set up networking. I now have two IP addresses on the server, I’ll call them 1.1.1.1 and 2.2.2.2 where 1.1.1.1 is the original IP that everything is configured to use. I use named hosts and use 1.1.1.1:80 as the host that all my sites run on. I’ll want the newly trusted SSL site on 2.2.2.2:443 and for convenience I’ll move the regular website to 2.2.2.2:80. But since DNS takes time to propagate I’ll want the regular site to listen on both IP addresses for awhile.  Servers differ so your server may differ but this is how I did it.

1. Change the /etc/apache2/ports.conf file with configurations to listen on both IPs individually and both simultaneously.

NameVirtualHost *:80
NameVirtualHost 1.1.1.1:80
NameVirtualHost 2.2.2.2:80
Listen 80

2. Then for SSL I configure the SSL hosts as follows.

NameVirtualHost 2.2.2.2:443
NameVirtualHost *:443

The NameVirtualHost *:443 statement is so that multiple sites can share an IP address with my self-signed certificate.

Then it’s time to edit the host file for the domain.

1. I change the <VirtualHost 1.1.1.1:80> statement to <VirtualHost *:80> so it runs on both IP addresses.

2. I change the SSL host statement from <VirtualHost *:443> to <VirtualHost 2.2.2.2:443> so it runs only on the new IP address. I will not be able to administer the WordPress site until DNS propagates but this isn’t a big deal.

3. I then add the necessary statements to the host file in order to enable the certificate:

SSLCertificateFile /etc/ssl/certs/www_mydomainname_com.crt
SSLCertificateKeyFile /etc/ssl/private/www_mydomainname_com.key
SSLCertificateChainFile /etc/ssl/certs/DigiCertCA.crt

The first two lines are the certificate and key files that I added earlier. That last line is the DigiCert intermediate certificate that needs to be added to the certificate chain. DigiCert provided the certificate when mine was sent. If I had multiple certificates from DigiCert they would all use this same certificate as the intermediate certificate.

5. Now it’s time to reload apache. At this point it will run the regular site on both IP addresses. WordPress administration (which uses port 443 for SSL) will only listen on the new IP address so I won’t have access to the admin console.

sudo /etc/init.d/apache2 reload

6. I update DNS to point the domain to the new 2.2.2.2 IP address. I wait a little while for the DNS to propagate. DigiCert has a tool that will check the certificate installation. I ran it and it confirmed a valid installation. I could access the regular site and the SSL site without a problem.

7. I wait another day to allow the DNS change to propagate and then I change the regular site to only run on the new IP address by editing the Apache configuration one more time. I change the /etc/apache2/ports.conf file to listen on both IPs individually but not simultaneously.

NameVirtualHost 1.1.1.1:80
NameVirtualHost 2.2.2.2:80
Listen 80

I remove the ability to list on both IP address for the regular websites. I don’t change the SSL port configuration.

8. Then I edit the site file for the domain so that it runs on the new IP address.  I change the <VirtualHost *:80> statement to <VirtualHost 2.2.2.2:80> in the site file for the domain.

9. I reloaded Apache one last time.

sudo /etc/init.d/apache2 reload

At this point my trusted certificate is running on my website. I know longer get the untrusted site or invalid certificate warnings.

One benefit over the free certificates offered by some is that all my browsers already recognize DigiCert as a valid certificate authority that issues these certificates. No need to load another certificate in my browser.

While not a cheap process, it was surprisingly fast and easy.

WordPress and Other Security Concerns

Security ShieldThere’s been a lot of press recently about increased attacks on WordPress sites, and I run WordPress. At first I considered it BS since it seemed ike a standard brute force attack. Not that I didn’t think attacks were going on, a view of logs on my own small servers shows attacks all the time.  But Brian Krebs published an article about it and I figure he has a better BS detector than me in these matters. So maybe there has been an increase. I figure I’m pretty safe, I don’t use the default accounts and I do use long, complex unique random passwords.

Some reading I did also indicated that the volume of logon attempts could cause resource problems on the server, so I decided I would try to specifically block them. After a few other attempts I decided to go the plugin route and used the plugin Limit Login Attempts. It’s a nice simple plugin that does what its name says. I dislike adding plugins to WordPress but I made a exception in this case. Eventually I hope to figure out a way to block this at the server level. But this will give me some protection and any easy way to get stats on whether or not my site is actually being attacked this way.

I’ve always been good about keeping WordPress and my web server updated with the latest patches, but I decided to reboot it this past Friday to make sure all those updates were really in the running software. Maybe it’s because I come from the windows world where patch reboots are a monthly reboot, but I figured it would be a good thing after having the server online for 220 days. So apologies to anyone trying to access the site this past Friday during a certain 9 minutes (I decided to do a full backup with everything shutdown for good measure).

It’s only been a day, but so far the only lookout has been from my testing

Apple (and other) 2-Step Verification

Apple added 2-step verification to their iCloud and iTunes accounts. I have to admit I like it. I especially like that they turn off any sort of password recovery that could be socially engineered. If I lose all the registered devices and the emergency recovery key then I’m screwed. But I’ve always wanted the option to tell these high-value vendors to disable password resets based on those stupid “pet name” security questions. I usually answer them with garbage, but the fact they exist worries me. Not necessarily for every little account, but for any that protects something of value.

I’ve also been going through and adding two-step verification to my other accounts that support it. Some places have apps that generate a token, or use the Google Authenticator App, but codes sent via SMS seem to be the most common. I guess SMS can be spoofed, but I suspect that doing so would have to be highly targeted and take more effort than I’d be worth.

Updates, Updates, Updates and More Updates

Everyone got into the patch game recently. Microsoft patch Tuesday sent a half dozen or more patches to PCs. Windows 2011 got some care with a a rollup patch. Then my web server had updates for evey major component. Naturally, it’s this site, down last, but where the problems began.

There have been a lot of updates this past week. Much to my relief most of these updates went smoothly. The main problem were with the updates to this site but I half expected it so allowed extra time to get them done and I did plenty of backups before starting.

WHS 2011 Update Rollup 4 & More

I was happy to see WHS 2011 is alive and well within Microsoft, even if it has been marked for death. Tuesday’s patch bundle included Windows Home Server 2011 Update Rollup 4 with 10 documented fixes. I’m pretty aggressive in keeping my WHS box up to date so it was updated back in November, but it still had 8 patches waiting in addition to the rollup.

I generally take Microsoft’s default selections when I chose which patches to install then do the unselected ones after, if they are still needed. In this case I also unchecked UR4 and started the update.

A couple updates failed and I selected them and the other remaining updates after the reboot, only excluding UR4. It was fine this time and UR4 was successfully installed after that reboot. The connector updates were then pushed out to the clients automatically. This required a reboot, but that was done when the client patches were installed.

No problems so far.

Windows 7 & Windows 8 PCs

Lots of updates all around and they all needed reboots. Windows RT got its share of patches, including a firmware update. I haven’t noticed any difference but some report better performance.

Windows 8 threw in another patch on Thursday which also required a reboot. These are annoying since I run a lot of apps and unlike my Macs they don’t restore running apps automatically. So while the actual reboot is fast, it’s a frustrating 15 minutes of preparation and recovery.

Mac OS X

My new Mac Mini had a BIOS update related to HDMI monitor connections. I haven’t had an issue. My monitor goes through an adapter to the Mac’s HDMI port. I’ll be moving my old Windows monitor to the Mini and then it will be HDMI direct. So probably a good update to have.

The iTunes 11 update wasn’t problem free. But the new bugs were minor compared to the nightmare that is iTunes anyway. More on this in a future post.

Debian 6 and WordPress (My Web Server)

WordPress LogoThis was the big one for me. Just about every major software component of this server was slated for an update. Apache, MySQL, PHP and WordPress all had updates waiting. I held off on the Apache, MySQL and PHP updates until WordPress 3.5 was released. I’d do it in two phases – everything except WordPress, then WordPress. Of course, before starting I did a full server snapshot backup and a file system backup of my web server.

The OS updates and Apache, MySQL and PHP updates all went fine. Everything tested out OK after the update. Then the problems began.

The WordPress upgrades on my test sites only had issues on the ones using the new Twenty Twelve theme. The theme is now part of the core WordPress installation and I install through Subversion (svn). The sites were broken until I deleted the Twenty Twelve directory and re-ran the svn update. That wasn’t going to be a problem on this or my other production sites since they didn’t have the Twenty Twelve theme installed.

I saved this site until last, since it’s my biggest one. So naturally, that’s when the problems began. Short version – the SVN update went horribly wrong. It was possibly self-inflicted. I had deleted the old Twenty Ten theme since I never used it. SVN didn’t like that and threw an error. This must have affected the rest of the update. While pages were still being served from the cache, the site was basically down.

I spent some time trying to work around the error but without success. Finally I did a fresh WordPress installation to a temp directory using Subversion. Then I copied those files over the installation for this site, being careful not to overwrite or delete and files I added or changed. After that, and a restart of Apache all seems fine.

Piwik Stats – Email Reports

Piwik has the ability to send emails with site statistics. Unfortunately Piwik doesn’t update the stats before sending the email. So if I hadn’t triggered a report update I would get a email showing 0 visitors. It was time to fix this.

Piwik bannerI use Piwik for my website analytics. I like that I host and control the data and it’s a learning experience. It’s not as full featured as Google Analytics but it’s more than I need for my little website.

I can get an email every morning showing my sites traffic for the day before. This email has always had a problem of often not having the previous day or days stats. I finally determined it was because the archives were only generated when someone (like me) viewed the reports. And the email came from this data. I ignored this problem because there was also an iOS app that I could use to check stats and it was easier than email. So I typically ignored this email even when I hadn’t turned it off.

But then I was ignoring stats for awhile and those “0 visitor” emails didn’t cause any alarm. Unfortunately I had a website problem that went on for longer than it should.  So it was time to get those emailed stats working.

I’m running Piwik on Debian and Apache. Everything is on the latest versions. I figured my solution was to implement their stat archiving script in a cron job. This is recommended for larger sites to limit the impact of compiling the stats.

Their instructions for setting this up are pretty good so I won’t repeat everything here, just add some comments on the issues I had.

Curl is needed. I installed the php5-curl package.

sudo aptitude install php5-curl

Rather than schedule a job through crontab I just added the script file to the /etc/cron.hourly directory.

The script contains three lines, only one of which does anything important:

#!/bin/bash
#Generate Piwik Stats – Everything below is on one line
/usr/bin/php5 /path/to/piwik/misc/cron/archive.php –url=http://example.org/piwik/ –accept-invalid-ssl-certificate > /home/example/piwik-archive.log

Most of the parameters are described in the Piwik documentation. I added this one to deal with my self-signed SSL certificate. This is not the best security choice but I figure the risk is minimal for me.

–accept-invalid-ssl-certificate

Don’t forget,like I did, to make the script executable: chmod +x /etc/cron.hourly/scriptfile

Hourly updates are more than I need but at least I don’t have to worry about coordinating the email and stats generation

@#$%!@ Web Host

image of WWW on goldAbout 3:30PM ET today I got an alert that my site was down. Sure enough, it was not accessible. I logged onto my Linode management console and there was a notice that they were investigating a problem affecting my server, They problem was so recent that the status page hadn’t been updated with the incident yet, but it soon indicated a power problem was reported at the site. Long story short, utility power failed and the generators failed to kick in automatically so power was lost to some servers and equipment.

Unfortunately when my server came up about an hour later there was a problem with Apache and it was returning my default site (just a placeholder page) instead of this site and it wasn’t until I restarted Apache a little while ago that the site was being served.

I give Linode high marks for communication, although the outage still stinks. According to the logs it looks like they tried to reboot the server, probably when power came back, and that reboot failed with an “already running” error. So it looks like there was a problem with the power on reboot.

I’m still looking through the logs to see if I can see what the problem is. I also need to see if I can change my alerting to identify my site. I got the email may wite was up, but it was returning the wrong page. So properly identifying my site will be on my to do list.

While I like doing the hosting myself, on an unmanaged VPS this is the downside. Problems occur at inconvenient times and I don’t have anyone to yell at to come up with a solution. Guess I can’t have everything.

Moving FeedBurner Feed to New Account

It was time to consolidate my old FeedBurner feeds into my primary Google Apps account. It proved to be an easy and quick process.

I’ve been using FeedBurner from before the days Google owned it. When I converted it to a Google account I used my GMail account. I’ve been trying to consolidate everything to my Google Apps account and now it was time to move the FeedBurner feeds. This was a simple process and despite a warning that it could take up to 72 hours, I was done in minutes. (It took longer to write this article.)

You can only transfer between Google accounts, but I was able to transfer from a regular Google account to a Google Apps account.

  1. Log on to the existing FeedBurner account
  2. Click into the feed you want to transfer and select “Transfer Feed…”
    fb_transferfeed
  3. Enter the email address of the recipient then click the “Send Transfer Acceptance Request” button.
    fb_transfertoaddress
  4. Despite the warning that it can take up to 72 hours I received my email within moments. There’s a link to click in the email. When clicked you’re asked to accept or reject the transfer. I accepted and the feed was instantly in my new account.

This will be the first post since transferring the feed so we’ll see if it broke anything. [Update: It worked!]

[Update June 26th] I use FeedBurner to tweet when I have a new post. This broke when I moved the feed since the receiving Google account wasn’t authorized for Twitter. In FeedBurner I went to the Publicize tab, then the Socialize selection on the left. Then I just clicked the “Add a Twitter Account” button and authorized it. Then the Tweets started working again.

Adjusting Logrotate And Lesson Learned

Back when I upgraded my web server I also implemented logrotate to save off the logs each day so they don’t grow too large. At the time it seemed like a good idea to just save the logs for a year since I had the disk space. In retrospect that was a mistake. Why?

image of WWW on goldBack when I upgraded my web server I also implemented logrotate to save off the logs each day so they don’t grow too large. At the time it seemed like a good idea to just save the logs for a year since I had the disk space. In retrospect that was a mistake. Why?

Logrotate numbers each file as it’s rotated out. What probably should have been obvious in restospect was that each time logrotate rotates it increments each log file by 1, and that number is part of the name. So each time the logs were rotated every log file was changed. This didn’t seem to affect the server at all, but since each file was changed it got backed up each night. This made the backups take considerably longer and used more bandwidth than necessary.

So I changed the logrotate configuration to only keep a month of logs. I’ll still backup all 31 files each night, but that’s less than the 70+ I’m already doing, and less than the 365 once a year passes. This changed will give me a little over a month of logs and if I really want more history I can archive the new file off every week. The decision for 365 was more due to laziness than a justifiable decision.

I also found logrotate isn’t smart enough to know when it has extra files. When I reduced the files to keep from 365 to 31 logrotate just deleted file 32 and kept all the higher numbered logs so I’ll have to delete them manually. I’ll go back in and delete the files but since they’re not updated anymore they won’t be backed up each night.

Now the logrotate file for my web logs looks like this:

<PathToLogFiles>/*.log {

rotate 31

daily

compress

delaycompress

nosharedscripts

postrotate

/usr/sbin/apache2ctl graceful > /dev/null

endscript

}

It’s not so much the compressed log archives that I want to keep small, but I want to keep the active log itself small enough so that I can easily open it and read through it when necessary. So while a weekly archive file would still be manageable, opening or copying the active log file.

I retrospect it was pretty obvious the way logrotate would work, I just didn’t think about it too much.Easy enough to fix.

 

 

WordPress Stats Plugin Goes Jetpack Only

When visiting the admin panel recently I noticed a message that the WordPress Stats plugin would only get future updates via the Jetpack plugin. Both are from Automattic, the folks who run WordPress.com. JetPack is a bundle of many plugins from Automattic. I have an instant aversion to bundles like this so I’ll be moving that site off of WordPress Stats. I’ve no idea when the lack of a separate upgrade will cause me problems but I’ll chose one of the options I’m testing on this site. Read on to see what I’ve been test driving…

Web Traffic GraphicI no longer use WordPress Stats on this site, but I still use it on one of my other sites. When visiting the admin panel recently I noticed a message that the WordPress Stats plugin would only get future updates via the Jetpack plugin. Both are from Automattic, the folks who run WordPress.com. JetPack is a bundle of many plugins from Automattic. I have an instant aversion to bundles like this so I’ll be moving that other site off of WordPress Stats. I’ve no idea when the lack of a separate upgrade will cause me problems but I might as well replicate what I do on this site.

I’ve currently been trying out three stats options on this site. One is free, one is free for basic service with additional costs for larger logs, and the third has a small one time charge,

In the case of WordPress Stats it’s a plugin that maintains the stats on their own servers, taking the load off my own server. It provides summary data along with some search and post tracking. And it’s free, It integrates with the admin panel. So my requirements were admin panel integration and plugin support. Off site stats maintenance wasn’t a requirement.

Google Analytics

Website: www.google.com/analytics

Pros: Free, Off site stats storage, Long-term historical data detail

Cons: More data to Google (some may consider this a con, others may not). I’m on the fence.

Plugin: Many. I use Google Analyticator.

Google Analytics is easy enough to use for basic stats although it becomes more complex as you dive into what’s available. Due to it’s popularity there’s a plethora of information about setting it up and books about using it.

StatCounter

Website: StatCounter.com

Pros: Free for summary data and detail on the last 500 visits. Additional detail logs for a fee. Offsite stats storage.

Cons: Depending on how busy your site, the 500 line limit may not be enough, requiring added cost.

Plugin: Official StatCounter Plugin

StaCounter is easier to extract the detail information than Google Analytics. The downside is the log file size limits how much detail you can keep with one line equating to one page view. So the free 500 is good for 500 views. I like that the detail includes the search terms that bring visitors to the site and StatCounter makes it easy to view and analyze this information.

Personally I like StatCounter better than Google Analytics but would have to pay for additional logs to make it useful. Summary information is kept long term which is often all I want.

Mint

Website: Mint

Pros: You maintain the database and control the data. Flexible configuration, only track what I want.

Cons: $30/domain. You must maintain the database.

Plugin: Mint Analytics (which I’ve edited to ignore my visits)

Mint’s stats database can be on another server, but it needs to be a server you control. Since your installing the software and database locally it’s significantly more complicated than the other options. You can choose which plugins (called Peppers) to install. These peppers can be developed by the Mint community, not just the owners, I’ve had problems integrating some of the more complex features such as RSS feed tracking and on site search tracking, Some of these problems arise because of conflicts with some of my other choices, such as using a Google custom search for on site searches and aren’t necessarily the fault of Mint.

Summary

I want to like Mint because it lets me control the data. But I don’t like the hassle of maintaining it myself. While not a lot of effort once it’s installed, it’s more effort than the other options. In theory Mint would place more load on the server although I haven’t had any performance issues. Also, I had to manually edit the Mint plugin to not track my own visits, something the other options already include.

I also like StatCounter more than Google Analytics as I get to the data I care about easier than with Google Analytics. But I’ll have to pay for added log space in order to get the 30 days I’d want.

Finally Google Analytics has the long-term logging and is free. Still, I’m less and less confortable with all the eggs I’m putting in the Google Basket.

If you use WordPress Stats will you keep it once it’s part of jetpack? Do you use Jetpack already? Any other stats options you’d recommend?

Skimlinks

At the beginning of July state (Connecticut) changed their tax law to incorporate an “affiliate tax” (aka Amazon tax). Naturally, most affiliates simply dropped their Connecticut affiliates. While I don’t make a lot of money on this site I would like to cover the hosting charges. So it was necessary to find some alternative income sources.

Skimlinks logoAt the beginning of July my state (Connecticut) changed their tax law to incorporate an “affiliate tax” (aka Amazon tax). Naturally, most affiliates simply dropped me and along with all their Connecticut affiliates. While I don’t make a lot of money on this site I would like to cover the hosting charges. So it was necessary to find some alternative income sources.

What I came across was Skimlinks. In short, it’s a service that converts regular links into affiliate links. They also offer a second service, called Skimwords, that will add affiliate links to regular text but I haven’t tried that service. Skimwords already had Amazon and Newegg in their program and these were two sites where I did most of my linking. The main benefit of Skimlinks is I could link to wherever I wanted and if they were a Skimlinks affiliate then it would be turned into an affiliate link.

I did have to go through and replace my old Newegg affiliate links with regular Newegg links since Skimlinks won’t rewrite existing affiliate links. Although they did make a recent change to optionally allow rewriting Amazon affiliate links which saved me from having to find them all and change them. The option is off by default but easy enough to turn on.

Skimlinks itself is implemented with a snippet of javascript and there’s a WordPress plugin available for WordPress websites. There’s also install guides and a few plugins for other popular platforms. Overall, it seems to be working well.

They have another feature, called Skimwords, that will add links to a website based upon settings. I’d prefer to do all my own linking so I haven’t tried this feature. While it does convert links to affiliate links, at least this way I’m still in complete control of where those links go.

I like that I didn’t have to change the way I do my links and can keep linking to the same places I did before since I stick to linking to places I use or frequent myself. In general, they take a cut of the affiliate commission so the payout to me could be less than if I had a direct agreement. But they do have preferred merchants where they payout is comparable due to their own agreements with the merchant.

I probably wouldn’t have found it if I hadn’t lost my affiliates but if your in one of the growing number of states that are changing their tax laws and affiliates are dropping you then it’s worth checking out.