Posts Tagged ‘ nearlyfreespeech

Upgrading WordPress

So it’s time for you to upgrade WordPress. Maybe you keep hearing about how dangerous it is to leave old versions of WordPress lying about. Maybe it’s been awhile since you’ve posted anything anyway and you figured, “meh, have at it, hackers.” Maybe you’re returning to the installation not entirely sure that it’s even being hosted anymore. Maybe that’s just me.

I haven’t upgraded since the original install, I’ve misplaced or forgotten all passwords related to my host, installation, database, etc., and I’ve no recollection of how I did the original install in the first place. I intended to write a post on installing wordpress the first time I did it, but I found a couple existing posts that were pretty good, so I skipped it. Luckily, the internetz memory is better than mine, so I was able to dig these back up.

In any case, I’m going to document this 1. for my own purposes, since WordPress comes out with new versions with alarming frequency 2. so that I have something to post to my updated wordpress blog.

Here’s what I did:

  1. Find my passwords: they were in a log book among a number of log books in a box that I hadn’t opened since we moved. This doesn’t help you, of course, unless you’re seeking to physically steal my passwords and hijack my website–and I didn’t tell you *which* logbook, did I!

    Writing down relevant passwords in a logbook was a big organizational step forward for me. Typically, I rely on gmail archives and “forgot your password” links each time I return to a site after a long absence.

  2. Logged onto my service provider (nearlyfreespeech.com) and found the machine name for my website. I connect using secure shell (ssh), which is an encrypted remote shell. You can find many open source ssh windows clients. If you have the good sense to run Linux, ssh should be available to you on the command line:
    ssh myaccount@mymachine.myhost.com
  3. Once logged on to your host machine, you need to find your document root–the directory from which your website is served up. Many hosting services will direct you there automatically when you log in. For most others, the document root is directly off the machine root directory or in the home subdirectory. The document root is typically called htdocs, httpdocs, web, www, public or public_html. Aren’t standards great? If you can’t find the document root, try running the following command:
    
    find /  2>/dev/null | grep wordpress  
    

    This will recursively list every file in the filesystem and “pipe” the results through a program than searches for the name “wordpress.” The results should all be within your document root. the “2>/dev/null” part will direct all error messages into a blackhole–sort of a trashcan for output.

  4. Let’s say that your document root is /home/public_html. After you’ve found your document root, change to that directory:
    
    cd /home/public_html
    

  5. Run the following command:
    wget http://wordpress.org/latest.tar.gz  
    

    This will get a file from a URL and put it in the local directory. The file name is "latest.tar.gz" which indicates a a compressed (gzipped) tape archive file (tar). Tar files are a legacy from an ancient time when archives were stored on reel-to-reel tape. Although the tapes are gone, the name remains and "tar" files are single files that store a bunch of individual files and/or directories in a single entity.

  6. If your wordpress directory is named "wordpress," you might want to move it so that the new wordpress files don't overwrite anything that you have modified:
    mv  wordpress wordpress-old  
    
  7. Then uncompress and "untar" the file that you just wgot:
    tar -zxfv latest.tar.gz  
    

    the -z indicates that the file be uncompressed with gzip, -x indicates that files should be extracted, -f means that the file will be name in the next argument, and -v means that you will see the names of the individual files and directories as they are extracted from the archive.

  8. Now you should have a directory "wordpress" in your working directory. Enter it:
    cd wordpress
  9. Since we already have a wordpress installation, we will eliminate the bits that are used for the initial installation and that we plan to transplant from our existing website.
    
    rm wp-config-sample.php 
    rm -rf wp-content  
    

    Now copy your existing websites wp-config.php, .htaccess and wp-content directory to the new wordpress directory:

    
    cp /home/public_html/wordpress-old/wp-config.php .  
    cp /home/public_html/wordpress-old/.htaccess . 
    cp -rf /home/public_html/wordpress-old/wp-content .  
    

    If your original wordpress directory isn't called "wordpress," (let's say it's called "blog") then replace the wordpress-old in the above commands with blog. The -r will tell the copy to act recursively, descending into subdirectories while copying and the -f will tell it to force the removal without querying you.

  10. If your wordpress directory isn't named wordpress (let's say again that it's named "blog"), move it out of the way: mv blog blog-old and move the new wordpress in mv wordpress blog You should then be able to reach it via the web. If your wordpress directory is wordpress, you should be able to reach it via the web and may skip this step.
  11. Finally, if everything is in order, delete your old wordpress directory (either wordpress-old or blog-old in our examples).
    
    rm -rf /home/public_html/wordpress-old  
    or  
    rm -rf /home/public_html/blog-old  
    

and you're done. A more thorough version of these instructions from whence my material was derived can be found here: http://codex.wordpress.org/UNIX_Shell_Skills

Webery with WordPress

A couple of weeks ago, I started looking for software packages that could “host a website.”  My criteria were simplicity, since I’m not terribly web-savvy; and extensibility, because I don’t want to cobble together 3 or 4 packages to get all the features I’m looking for.  I knew that WordPress was pretty popular, and I’d heard users of the package talk about their surprise at the variety of plugins it supported.

I gave it a shot, and now consider myself to be a believer.  An expert user might be better off with a combination of stand-alone blog, wiki, and forum software.  He/she would have the chops to tie the disparate pieces together with a single theme, authentication piece and database back-end.  For the rest of us, wordpress provides an excellent blog, good-enough forum and wiki pieces, as well as automagic database administration and user authentication.

The WordPress community provides tons of modifiable ‘themes,’ which provide the overall look-and-feel for the website; and ‘plugins/widgets,’ providing added functionality from discussion forums to tagging, post-calendars, and site-search.  While the complexity for installing these extras varies, the themes and plugins I’ve played with have been trivial to install, set-up, and customize.

Although WordPress’ customizability is initially overwhelming, the defaults are typically sane.  I discovered most of the features when I wanted to make a change to the structure of a page/plugin and went about discovering how to do it.

WordPress is written in PHP.  To get a WordPress driven website up, you’ll need to find a web-hosting service that supports PHP.  The WordPress recommended host page lists webhosts who have worked with WordPress to ensure a friendly hosting environment.  I myself went with nearlyfreespeech.net, a pay-as-you-go host.  I will probably end up spending about 50 cents/month (the mySQL support required for WordPress costs 30 cents) for the forseeable future.  I may detail my experience with nearlyfreespeech in a future post.