Category Archives: How To

Where I show you how to (or how not to) do stuff.

How To

A new lease on old hardware

In 2003, I bought an HP OfficeJet 7110 all-in-one, a big, boxy monster that did (and still does) printing, scanning, faxing and copying. I’ve barely ever used it to fax, but the feature is there in case I need it. Now I’m using it over our wireless network with an Apple AirPort Express, and it works great.

HP couldn’t wait to retire this model. A year after I’d bought it, I had a hard time getting support for it, in spite of the fact that I’d bought an extended support plan. Less than two years after I’d bought it, HP had already discontinued it. They stopped developing the drivers for it sometime in 2003 or 2004. The development for Mac drivers stopped at 10.4 (officially) but more likely, at 10.3. I used their drivers on 10.4 and there were serious problems. Switching accounts, for example, disabled printing, and it couldn’t be re-enabled unless one restarted the computer. I complained numerous times to HP, via tech support, via messages to their executives, but no one cared. Basically, HP’s support is horrible, and my experience was no different with the OfficeJet 7110.

Fortunately, I found a way to get more use out of this dinosaur without needing to buy a new printer (yet). Back in 2005, I purchased an Apple AirPort Express, a small device that does quite a few things. One of them is printer sharing. You plug in a USB printer, and it will share it wirelessly.

I’d wanted to do this ever since I’d bout the AirPort Express, but there were no usable Bonjour/network drivers for the 7110. With the introduction of Leopard, however, the story changed. Quite a few CUPS drivers came pre-loaded with the OS, and one of those drivers was built exactly for the 7110.

A couple of weekends ago, I took a half hour to relocate our printer and its stand, plug it into the AirPort Express, and install it on both our Macs via Bonjour. This was after I’d joined the AirPort Express to our existing WiFi network through the AirPort Utility. The whole process is fairly easy to do, except changes to the AirPort Express may require a reset or two before they commit properly. This may only be a bug with the older version that I have (from 2005), and it may not affect the newer versions of this device, like the 802.11n that just came out.

Now our printer is networked reliably and it’s usable immediately from both our Macs, which is something that wasn’t possible before. It’s not tethered via the annoying USB cable, and we don’t have to deal with its bulk next to our desks. Although the drivers are print-only, when we need to scan something, we simply take my laptop over to it, connect it via USB, and scan to my Windows XP virtual machine, which runs on VMware Fusion on top of Leopard. This is because the XP drivers are the only ones that still work reliably for this printer.

What also satisfies me is that I get a new lease on old hardware. I don’t have to go out and buy something new to get the functionality I need. I already spent good money on working hardware, and thanks to Leopard’s built-in printer drivers and AirPort Express, I get to use it years after HP decided to discontinue it and force people to buy new printers.

Standard
How To

How to transfer photos between Lightroom catalogs

This screencast will show you how to transfer photos between different Lightroom catalogs, and it will go beyond that by also demonstrating how the whole process could be made a LOT easier if Adobe wanted to.

In the screencast, I refer to an article I wrote a while back, entitled “The next stage for Lightroom“, where I put forth a proposal for improving the way Lightroom stores photos, with an eye on catalog portability (laptops, for example). If you have the time, please read through that article after you see the video.

The video is about 10 1/2 minutes long, file size is 78MB, and it’s 720p HD, MOV. You can view it online by clicking on the screenshot below, or download it.

Standard
How To

How to install or upgrade WordPress via SSH

If you know how to log in via SSH (Secure Shell Access), then you will be able to upgrade your WordPress site in three minutes or less by using the following lines of code.

I have to admit right away that I’m highly indebted to this pre-existing tutorial from Techtites. But that tutorial is a little dated for the newer versions of Linux, and one of the commands given there no longer works on my web server, because it’s been deprecated (I use 1and1). I thought it useful to provide the right commands in this post, and to keep it updated in case something changes.

A few words of CAUTION:

  1. BACK UP all of your site files and your site database before running the upgrade. Take the time to do both, or you may deeply regret it later. As a matter of fact, it’s a great idea to back up your site files and database on a weekly basis, if not more often, just in case you get hacked or the web server crashes, etc.
  2. I’m not a Linux expert. I’m just glad I found these commands and that they’ve made the upgrade process easier for me. Don’t ask me to help you configure this for your web server. If the commands don’t work there, or something gets screwed up, you’re on your own.
  3. Should you use the WP-Cache plugin, disable it and delete any cached files BEFORE running the upgrade process. Even better, disable ALL your plugins before the upgrade process. If you don’t do this, you may get a big, fat 500 error afterwards.

Now, initiate a SSH session to your web server (I use Putty). Your web host should have the directions on how to do this. Go to the root level of your site/WP install folder (this is NOT the same as the root level of your SSH login).

Once you’re at the root level of your WordPress install (the one where you can see the wp-config.php file), enter the following Bash commands, in the order they appear. Wait for each of them to execute successfully before proceeding to the next one.

This will download the latest version of WP directly from WordPress.org:

wget http://wordpress.org/latest.tar.gz

This will unzip it, creating a directory called wordpress:

tar xfz latest.tar.gz

This will delete the wp-includes and wp-admin folders:

rm -rf ./wp-includes/
rm -rf ./wp-admin/

This will take you inside the wordpress folder:

cd wordpress/

This will copy everything inside the wordpress folder to the root level of your site, overwriting any existing files and directories. This line is the only line that’s changed from the Techtites tutorial:

cp -rpf -f * ../

This will take you back out to the root of your WordPress install:

cd ..

This will delete the wordpress directory and the downloaded WP archive, since they’re not needed any more:

rm -rf ./wordpress/
rm -f latest.tar.gz

Hope this helps!

Standard
How To

A look at hard drives: finding the best deals

Given my recent push to find a feasible solution for my photo library, which resulted in the purchase of a Drobo (three, actually, but that’s beside the point), I’ve gotten to know a bit about hard drive prices. Here are my two cents on the issue.

Keep in mind that this advice is applicable only during the present time, since prices will continue to fluctuate and larger hard drives will become available, driving down the prices for the smaller ones. Let me also say that if you didn’t get your hard drives before, during or after Christmas, you missed out on some great deals.

Right now, the most economical drives (best size to price ratio) are the 500 GB ones. You can get great SATA drives with 16 MB caches (current standard size), 7,200 rpm and 3.0 GB/sec transfer speed at $120 (retail-boxed; OEM drives are cheaper).

If you must get a drive smaller than 500 GB, you can, but it’s not economical. The price per GB starts to go up once you go smaller. It’s about the economics of the thing. Regardless of the actual size of the drive, the price of the components and labor has to be factored in. Even if the drive is smaller in size, and it stands to reason that it should be cheaper, it costs money to put it together, and that cost is fairly inflexible. That’s why you may gasp when you look at the prices of 40 GB or 80 GB drives (if you can still find them) and you wonder why they cost so much when no one uses them anymore.

Back to bigger drives. I remember just 1-2 months ago, the 750 GB hard drives were double the price of the 500 GB ones, but the prices are coming down. In just another few months, or even less than that, they will close the gap and become the most economical drives you’ll find. That time isn’t here yet though. Right now, the least expensive 750 GB drives (retail-boxed) I can find start at $199. If 500 GB can be gotten for $100-120, then, proportionally speaking, 750 GB drives should be $150-180 in order to be as economical as the 500 GB drives. Not yet.

➡ Updated 2/27/08: The 1 TB (1,000 GB) drives have just dropped in price enough to be just as economical as the 500 GB drives. I’m very surprised that it’s happened this fast. The market has leapfrogged the 750 GB drives, as I thought it would. I’ve seen the WD 1 TB SATA drive pictured below for as as low as $230.

The 1 TB (1,000 GB) drivesaren’t economical yet, either. It’s likely that in 6 months or so, they’ll get to be great deals. It’s even possible that market forces will cause the prices to leapfrog over the 750 GB drives and push the 1 TB drives to the forefront. Right now, the least expensive 1 TB drive comes in at $260, which is more expensive than if you were to get two 500 GB drives. Keep in mind I’m talking strictly about the GB to price ratio here, not the convenience of having a single drive instead of two, which trumps the price difference somewhat.

Because I have a Drobo, I’m isolated somewhat from having to worry about whether I have a single drive or two drives. I can still get plenty of space if I stuff my Drobo with four 500 GB drives, then replace them with 750 GB or 1 TB drives later. Or, even better, I can take the wait and see approach. Right now, there’s plenty of space on the Drobo that stores my photo library, even with only two 500 GB drives inside. That means I can wait till the bigger drives get cheaper and buy an extra drive at that point.

Similarly, the Drobo that stores our movies and videos, plus our various other files, is doing just fine with three 500 GB drives. I don’t think I’m going to fill it up in the next month or two, and that means I can wait until the 750 GB drives, or maybe even the 1 TB drives, become economical.

With hardware, it’s about striking the balance between what you must have, and what can wait. Thankfully, even 500 GB is a ton of space for most people, so it’s a buyer’s market, as they say.

Another thing you can look at, once you know the prices of internal hard drives, is the prices of external drives. When you know how much an internal drive costs, you can subtract it from the cost of an external drive and figure out how much you’re paying for the enclosure and design alone, and whether it’s worth it to buy it.

This is why I said that the 500 GB LaCie drive was a bargain, and why I recommended that people buy it. Given that you can get a 500 GB drive for $100, and the drive costs $118 (at one point it cost only $109) you know this is a bargain. You’re paying only $18 to get the drive packaged nicely in a great USB 2.0 enclosure that makes no noise. Having fiddled around with plenty of enclosures in my time, I know a great deal when I see one.

By the same token, when you look at the G-Tech Quad Interface 500 GB drive, you know that’s not a bargain. When the drive itself costs only $100 and you pay $270 to get the drive and the enclosure, that means you’re paying $170 for just the enclosure and the quad interface. Is that worth it? You decide.

Don’t think I’m implying your decision has to be guided by price alone. While I dislike paying a premium for a product, I do it if I think it’s worth it. I think the Drobo is overpriced. I still bought three of them and I recommend them to others. I think Apple products are overpriced, but I still buy them and recommend them to others. (You’ll have to excuse my tone in that post — I was seriously irritated with Apple at the time, but what I said was true.)

It’s just that it’s worth knowing what you’re buying. If you’re going to spend your money on something, then you should do the research to back up your purchase decision. This is also why I’m steamed up about Apple’s non-transparency when it comes to their hardware specifications. I don’t know what I’m buying, and it bothers me. It doesn’t mean I don’t want to buy, it’s just that I’d like to know where my money’s going.

I hope this has been helpful to you.

Standard
How To

How I moved all my content from comeacross.info to raoulpop.com

A place in this world

Background info

As midnight approached this past New Year’s Eve, I was busy working on a long-term project. I was about to move all of my content (every article and post I’d written) from comeacross.info to raoulpop.com. There were many reasons for this, but consolidation was the most readily apparent.

As detailed on my About page, I’d already combined my content from other sites of mine onto comeacross.info, but there was one more piece of the puzzle that needed to fall into place. I’d alluded to it already. I was thinking about doing it in 2006, believe it or not. As a matter of fact, when I sat down and thought about whether to start writing at comeacross.info or raoulpop.com, I knew deep down I should choose to start writing on my personal domain, but worried it might be too difficult for people to remember and type the name.

After a year or so at ComeAcross, I realized that the subjects I was writing about were much too varied for a standalone site. I was writing in a personal voice, using a lot of 1st person, and it only made sense to have that sort of content reside on my personal site. Plus, there were so many splogs (spam blogs) on the .info TLD, that I worried whether I would be taken seriously if I stayed on .info. I’d owned raoulpop.com for a long time, I wasn’t really putting it to good use, and it didn’t make sense not to.

I set a deadline of 12/31, and got to work on planning and research. What better time for such a big change as this than New Year’s, right?

I’m documenting this for you because someone else might need to know how to do it. And I figure the thought process that went on behind the scenes is also worth knowing.

Planning and research

My biggest challenge was to figure out how to redirect all of the traffic from comeacross.info to raoulpop.com, reliably and accurately. I needed to make sure that every one of my articles and posts would redirect to my new domain automatically, so that a URL like

http://comeacross.info/2007/12/30/my-photographic-portfolio/

would automatically change to

https://raoulpop.com/2007/12/30/my-photographic-portfolio/

and the redirect would work in such a way that search engines would be properly notified and I wouldn’t lose my page rank.

I knew about 301 redirects, but I wasn’t sure how to accomplish them in the Linux/WordPress environment the way that I wanted them to work. I had worked mainly with Microsoft web servers until recent times, and Linux was and still is fairly new to me. I was using John Godley’s Redirection plugin for WP (it’s an awesome plugin btw), and I knew it could do 301 redirects quite nicely. I had been using it heavily when I changed post slugs or deleted/consolidated posts at ComeAcross.

I worked out a line of Regex code that I could use to create a site-wide redirection, I tested it and it worked fine. In case you’re wondering, you can easily test it by creating a 307 (temporary) redirection instead of a 301 (permanent) redirection. Here’s how to do it:

Create a new 301 redirection where the source URL is

/(.*)

and the target URL is

http://www.example.com/$1

Make sure you check the Regex box, add it, and you’re done.

Just to make sure, I contacted John Godley to confirm whether it was the best way to do things. He said that would certainly do the job, but there was a MUCH easier and faster way to do it, one that saves a lot of the overhead that comes into play when WP gets used. It works through the .htaccess file. He was kind enough to provide me with the code, which is reproduced below.

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

</IfModule>

Just paste that into your .htaccess file (remove all other code but make sure you back it up somewhere in case you need it), save it, upload it, and you’re done.

Don’t do anything yet though! Not before you’ve thoroughly backed up everything! Let me outline the steps for you, and keep in mind that I wanted to mirror all of my content from two separate WP sites using the same WP version, and to redirect from the first to the second. These two conditions have to be met in order for my advice to apply to your situation.

  1. Make sure both sites are on the latest and greatest version of WP, or at least they’re on the SAME version of WP
  2. Back up the database from the old domain
  3. Download all site files from the old domain
  4. Upload site files to new domain
  5. Restore database to new domain
  6. Make changes to .htaccess file as shown above
  7. Log into your new domain’s WP admin panel and change the site and blog URLs. Now you’re done! Check to make sure the redirection works properly and all of your content is there.

Upgrade your WP installs

The two sites have to be on the same version, or else things might not work as expected. Upgrade both sites to the latest and greatest, or at least make sure they’re on the SAME version before you do anything else. Go to WordPress, download and install the latest versions. There’s also an Automatic Upgrade plugin, but I haven’t tried it yet, so I can’t vouch for it.

BEFORE you do any sort of upgrade, you need to back up. Yes, you can’t get away from this… You’ll need to do two backups, one before you upgrade, and one after you upgrade, before you transfer the content.

Back up your content

This combines steps 2 and 3 listed above. Backing up your site files is easy. Use an FTP client to access the files on the web server and download them to your hard drive. I always keep a local copy of my site files. It just makes sense.

Backing up your database is a little more involved. Your database contains all of your site content (posts, links, comments, tags, categories, etc.) so you definitely don’t want to lose it. There are detailed instructions on backing up the database on the WordPress site. You can follow those, or you can go to your site’s Admin Panel >> Manage >> Export and download the WordPress WXR file, which you can import into your new site afterwards.

While this is great for backups, restores are another matter. I tried it and found that the import operation kept timing out at my web host. Given that I have thousands of posts, I didn’t want to sit there re-restoring the WXR file only to get a few posts done with every operation. I needed something quicker.

There is a plugin called WordPress Database Backup which lets you download a zipped SQL file of the database. You can use this to restore the database through the MySQL Admin Panel, if your webhost provides you access to it.

What I did was to simply point my new site install to my old database. This is a very handy and easy solution if you plan to host both sites with the same web host. But this still doesn’t excuse you from backing up the DB before you upgrade the WP install! 🙂

Restore your content to the new site

This is a two-step process (see #4 and #5 above) and involves reversing the steps you took during the backups. You will now upload your site files to the new domain, and you will restore the database to the new domain as well. If you’re in my situation, where you’re using the same web host, you can simply point the wpconfig.php file on your new domain to the old database.

Make sure all your content is properly restored before going on to the next step!

Make changes to the .htaccess file

You will need to make sure you don’t touch the .htaccess file before you transfer it to your new domain. Only the .htaccess file on your old domain needs to change. Remember this, or you’ll be wondering what’s going on with the redirects afterwards…

Use the code I’ve given you above, in the Planning and Research section, to make changes to the .htaccess file on your old domain, after you’ve made absolutely sure that all of your content is now mirrored on the new domain. Once this is done, the redirects will occur automatically and seamlessly.

Final checks and tweaks

This is very important. Surf to your old URL. You should get re-directed to your new URL. Do a search in the search engines for content of yours that you know is easily found. Click on the search results and make sure the links get redirected to your new site. Because you’re using 301 redirects, the search engines will automatically change their search results to reflect the URL changes without affecting your page rank, so you shouldn’t lose any search engine traffic if you execute the content move correctly.

There are a few more things you’ll need to check:

If you’d like to make changes to your site feed (and I did), you’ll need to handle that properly. I use FeedBurner, and there are people that subscribe to my content via RSS or via email. I needed to transfer both groups of subscribers to my new feed seamlessly. The FeedBurner folks helped me do just that, and I didn’t lose a single subscriber during the move. I detailed that process in this post.

What about internal links? If you’ve blogged for a while, you’ll have linked to older posts of yours. Those link URLs now contain the old domain, and you’ll need to change all of them at some point, or you’ll risk making those links invalid if you should ever stop renewing your old domain. Fortunately, there’s a Search and Replace plugin for WP that lets you do just that. It works directly with the database, it’s very powerful, and it’s very fast. That means you have to be VERY careful when you use it, because there’s no undo button. You can easily mess up all of your content if you don’t know what you’re doing.

What I did was to replace all instances of “.raoulpop.com/” with “.raoulpop.com/“. That did the trick nicely. I then did a regular site search for all instances of ComeAcross and manually made any needed changes to those posts. (Here’s a thought: back up the DB before you start replacing anything. This way you can restore if something should go wrong.)

Finally, if you’re using the Google Sitemaps Generator plugin, you’ll want to make sure you manually rebuild your site map. You don’t want to have your old site information in the site map as Google and the other search engines start to crawl your new domain.

That’s about all I did for the site content transfer. It occupied half my New Year’s Eve night, but it was worth it. It’s quite a bit of work, but if you plan it out, it should only take you 4-5 hours or less to execute the transfer, depending on your familiarity with this sort of thing, and the speed of your internet connection (keep in mind that upload speeds are a LOT slower than download speeds on most broadband connections).

Given how much work is involved, I was a bit surprised to see Matthew Mullenweg (founding developer of WordPress) talk about doing his own switch to a new domain in “2 seconds“. I think what he referred to is the changes to the .htaccess file and the blog URLs, which are the fastest parts of the process. There is, however, quite a bit of work that needs to take place behind the scenes before those switches can get flipped. And I also believe (someone correct me if I’m wrong) that he pointed both domains to the same web files — in other words, re-used his existing WP install — so he bypassed a lot of the steps that are otherwise required.

Hope this proves helpful to someone!

Standard