This was very helpful. The most challenging thing about finding information about Python decorators, when I encountered them, was that searching for “python @” didn’t bring up anything useful.
Archive for the ‘ How To ’ Category
I went on my first real wordpress odyssey last week[skip the tiresome narrative]. I encountered a number of sites that helped me on my way. Now I plan to “give something back” in the form of documenting the steps and missteps I took in the hopes that, should someone else find themselves in a similar situation, they can use this post as a resource to find their way home.
A number of tools of modern web development (and software development in general) attempt to provide a clean and simple(r) interface to rather complicated processes. WordPress is one such tool. The idea is to abstract away the various elements of site development and allow the WordPress user to focus on content. The obvious advantage of all such tools is the inclusion of non-expert site developers among the potential software users. This expands the base of people that can communicate their ideas in modern networked forums.
The downside is, when something goes wrong, it can often be at a “level” that the site maintainer may not be expert in, and may not even be aware of.
I am a novice user of WordPress. My level of expertise was such that I could install updates–a process which with my provider must be done manually. I had version 2.7.1 installed when I saw that an update was available. Knowing that updates are generally responses to super-heinous security vulnerabilities, I attempted to upgrade using my trusty notes on the process.
Upon completing the upgrade, I looked at the “new” site and saw this. A totally blank page. Being the computer genius that I am (and following my wisely conservative notes), I had the old version on hand, so I rolled it back in and went googling for information. I saw a couple of other people had encountered this problem, but all of their situations seemed, at a glance far more complicated than mine. I didn’t see any simple solutions provided so I decided to wait awhile in the hopes that somebody would notice and fix the problem in the next WordPress release–I adopt this type of tactic frequently, with mixed results.
A couple weeks passed (I’m the opposite of a prolific blogger) and another version of WordPress was released. I tried again to upgrade and I got the same results–blank screen. This time, I was determined put in some time and fix whatever it was that was broke. Thus began my adventure . . .
I make numerous indirect references to my install instructions.
Part of the setup at my provider is a personal “public” folder that is the document root for the entire site. My WordPress installation is a sub-directory of public (
/home/public/wordpress). As a step in my (and any) upgradeThe first thing I did, to be extra super safe is to create a tar file of my old wordpress installation,
wordpress.20100216.tar. No matter what, I’d have a working version [foreshadowing]. Now I could operate in my typical manner, with reckless abandon.
I had three wordpress installations–three subdirectories of
wordpress-old, the working original copy;
wordpress-blank, the latest wordpress install, but with my
wp-config.php and wp-config directories copied over; and
wordpress which was
latest.tar.gz unzipped and extracted with a generic
My first reference was Velvet Blues, who have, apparently, suffered all kinds of blank page woes. Another site, High Tech Dad, was the first place I saw the term White Screen of Death (WSOD). Searching for WSOD brought a bunch of additional stuff. If you’re suffering WSOD, you’re solution is out there . . . unless you have the problem I was having*.
I was able to rule out all of the content, plugin, theme problems. I copied the
wp-content directory over and built a new
wp-config.php (via the web interface) which resulted in a functioning wordpress install–without my content. When I copied
wp-config.php over, WSOD.
So I followed #5 from the Velvet Blues article, excerpted from another excellent WSOD article by a McNulty–which is awesome, I’m a huge Wire fan. He suggested that white space in the
wp-config.php file could be the culprit. When I crack it open in vi, my config file looks like this:
My provider hosts with FreeBSD. I transfer the files from a windows machine and, there or in the original, the control-M (carriage return) is tacked on the end of each line. FreeBSD doesn't use carriage returns, but the control character is still on there. Of course, this hadn't been a problem for my old wordpress installation, but maybe the latest release is finicky? In any case, I figure I'll try to strip them out. While I'm at it, I decide to strip them out of the entire distribution. After popping over here to refresh my memory on entering control characters, I do the following:
find . | xargs perl -pi -e "s:^V^M::g"
Still got WSOD. Oh, and I accidentally ran in in public, instead of public/wordpress, so I stripped all the control characters (^M) out of every file under the document root. Careless move, but no big deal, they're not used in unix [more foreshadowing].
I should have made note of this when it happened, the details are fuzzy a week later--maybe I'm trying to blank it out. Somehow in all of the moving things around I deleted
wordpress-old (or maybe just wp-contents in there). Anyhow, I'd lost my original installation. Luckily, I had my tar file . . . without the ^M's that are apparently used in non-text files, even in FreeBSD.
Without ever solving my first problem, I was now facing a second--how to connect a totally new wordpress instance with my still existing database backend.
At first, this looked trivial. According to the codex, I just needed to point a clean copy of wordpress at the existing DB. So I extracted a fresh copy of the latest distribution and attempted to point it at the existing database. It wouldn't let me continue, giving the following error:
"Already installed! To reinstall please clear your old database tables first."
So then I tried giving it a "fake" table prefix so that it would complete installation, and then go end and change the table prefix by hand to match my existing DB . . . WSOD. It was getting late and I was resigned to the fact that I wasn't going to get my upgrade/recovery done before my cognitive skills degraded to the point that I would further endanger my chances of ever succeeding.
Upon waking up the next morning, I had a pretty good feeling that I could fix my site. I figured the damage must be inside my database itself, so I would just copy the tables one-by-one until I got the WSOD. Then, knowing the culprit, I would repeat the procedure but leave out the corrupted table, which I would copy over from a new installation.
So I unzipped a new copy of the latest distribution. This time, upon creating the
wp-config.php--again, from the web interface--I provided another, totally new, prefix. During the course of my searches on prefixes, I discovered that I probably should have a non-standard prefix anyway. Apologies to the original source--I couldn't find it again. I picked up and installed the phpMyAdmin plugin. It showed my original wp_ prefixed tables as well as a set of tables for each of my two other installs.
One-by-one I dropped the tables from the new installation and copied the wp_ tables to the new installation prefix. It turns out, something in the options table was causing the problem. I copied all the other tables over, and voila, a functioning website.
To be honest, there was one additional hurdle to do with the salts in the options table (or keys, as they're labelled in
wp-config.php). They need to match, and . . . something else is required as well. In any case, I've forgotten exactly what the problem was--I solved it by dropping the options and user tables and creating a new wp-config.php (all together) "via the web interface".
* My problem may have been on the list. I may have had to figure it out the hard way.
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:
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.
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.
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.
mv wordpress wordpress-old
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.
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.
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