Out, Damn’d Quote!

The Shakespearean Flaw in PHP Prompts
WordPress’ White Screen of Death

Thus conscience does make cowards of us all,
And thus the native hue of resolution
Is sicklied o’er with the pale cast of thought,
And enterprises of great pitch and moment
With this regard their currents turn awry,
And lose the name of action

— William Shakespeare, Hamlet, Act III Sc.1

Alas poor Yorick! He couldn't code worth a fiddler's damn, Horatio.Okay, maybe the potential fragility of computer language code, specifically PHP as utilized by WordPress, doesn’t quite compare with Hamlet’s dawdling and proto-angst or Macbeth’s murderous ambition – their fatal, tragic flaws, if you are a Shakespeare buff, or at least were paying attention in high school English. Indeed, exaggeration of Swiftian proportions, this. But this fragility can bring on the dreaded WordPress White Screen of Death quite easily when one begins modifying code (code that works just fine as it is) to customize it to one’s own wants and needs.

In fact, one misplaced apostrophe – or, rather, one misinterpreted single quote — can break an entire installation of WordPress, prompting the aforementioned White Screen of Death. Think of the thousands of lines of code involved in a Website, WordPress or otherwise, and then think about that. Here is this magnificent digital tower: a fortress of light standing staunchly at the crossroads of Gibson’s cyberspace, destroyed (albeit temporarily) by one tiny, misplaced, digital brick.

It’s not just tragic – okay, not really – but also ironic in that one of the great things about WordPress is that it’s open source, has lots of really knowledgeable coders working on it, and as such is really stable. Someone who doesn’t know jack squat about computers and the series of interconnected tubes can get WordPress up and running with relative ease and speed, joining their voice to the cacophony of the blogosphere. It’s actually quite hard to break WordPress, in point of fact. It’s like my old Subaru: until you go tinkering under the hood fixing stuff that isn’t broken, it works flawlessly.

Case in point: I was recently working on a site that will use WordPress and the Thirty Ten theme, which is a three-column version of WordPress’ own Twenty Ten theme, the default theme that comes with WordPress. I wanted something as simple and clean as Twenty Ten for this particular site, but, I wanted three columns. Rather than reinvent the three-columned wheel, I looked to Aaron Jorbin’s Thirty Ten theme.

This is exactly what I wanted: a child theme of Twenty Ten that adds a third column. Yay for Aaron Jorbin! I only needed to change the link colors and add custom text to the footer.

I wasn’t quite thinking when I attended to the latter; after all, what could go wrong, just replacing text? You can see the tragic Shakespearian downfall coming, yeah? PHP uses single quotes around text that will appear in your browser. For example, if we look at the footer.php file in Twenty Ten, there is this line:

<?php printf( __( ‘Proudly powered by %s.’, ‘twentyten’ ), ‘WordPress’ ); ?>

Lady Macbeth looks for the problem in her PHP code. That line produces the “Proudly powered by WordPress.” line at the bottom of every page in the default Twenty Ten theme. Thirty Ten modifies this, along with some of the other default text that appears elsewhere in the Twenty Ten theme, with a file called text-wrangler.php – the beauty of a child theme is that it doesn’t modify the underlying parent theme files. Among my customized footer text were the word’s “Gecko’s Bark” – no, really. Now, an experienced Web coder would know that single quote, doubling as a possessive apostrophe in this instance, would have to represented by the proper code for its symbol, lest a browser interpret it as part of the actual PHP code. Specifically, I needed Gecko&#39;s Bark.

But I’m still a n00b, really – well not really a n00b, after all, I realized where my problem lay within minutes. But I obviously lack the expertise and instincts that someone that has coded all his her life, for a living. Ironically, if I hadn’t been a journalist all my life, being grammatically correct wouldn’t be instinctive and I probably wouldn’t have sweated the possessive. So there you go; my own tragically Shakespearean flaw in miniature.

Anyway, that little coding boo-boo was enough to completely break WordPress. I went to look at how the footer appeared with the changes, and … nothing. Zilch. Nada. It was a sea of white space in the browser. I tried to go to the WordPress admin page, but saw only more white space.

Yep. One little single quote caused a cascade effect that broke WordPress completely. Usually something like this will only cause certain pages not to load, or the site and/or the admin pages to look wonky. Or you get some sort of PHP-related error. But not this time; I tried different browsers and there was nothing but white space or the “can’t get there from here” error that Internet Explorer throws up. That little misplaced single quote caused my browser to subsequently misinterpret all of the rest of the underlying code that otherwise works fine.

Fortunately this wasn’t a live site (the beauty of having a local WordPress installation). I looked at the MySQL database and restarted Apache – typically the rare WordPress White Screen of Death involves issues with one these things – but neither one of these were the problem. I would have been surprised if either had; the site was working moments before I went to tinker with the footer text, now it was busted – doesn’t take Sherlock Holmes to logically deduce that I must have broke things messing around with that footer text. Sure enough, a perusal of text-wrangler.php revealed the problem.

The damn'd spot, er, apostrophe cum single quote in question. D’oh! Out, damn’ed quote!

This is where it’s nice to have a text editor that can represent different parts of code with different colors; in this case the telltale devil was in the pink text, or lack thereof. When looking at PHP code in Gedit, the text editor in versions of Linux that use the Gnome GUI, such as Ubuntu, it portrays text in between quotes — the text that will appear in your browser — in bright-pink-not-quite-fuchsia. A quick glance revealed my errant apostrophe and the subsequent line of text that should have been pink, but wasn’t.

No, not the stuff of Shakespearean tragedy. Not even comedy. But hopefully this will server as a warning and lesson to others who set out to customize WordPress. Be careful tinkering under the hood, lest your hubris cause your tragic downfall – or that of your Website.

To-morrow, and to-morrow, and to-morrow,
Creeps in this petty code from screen to screen
To the last syllable of re-coded line;
And all our yesterdays have lighted fools
The way to white screen death. Out, out, brief mon’tor!
Website’s but a walking shadow

– Jeff Chappell (with apologies to the Bard. To see the inspiration/original, consult Macbeth, Act V, Sc. V).

If you’d like more Shakespearean parody, please go here.

WordPress in Ubuntu

A Local WordPress Install and the Windows Refugee Experience: chownED by Ubuntu!

Ubuntu: sudo /what/the/hell?This isn’t a tutorial per se, unlike these posts on setting up a local WordPress installation under Windows using WampServer. There are several comprehensive tutorials or sets of instructions out there on the Web about setting up LAMP – Linux-Apache-MySQL-PHP – along with WordPress on Ubuntu.

Furthermore, while I can’t say I’m a Linux noobert, per se, I would still consider myself a de facto noob. I find it easier to tinker under the hood in Windows, simply because I’ve been doing it for so long. I’ve only been using Ubuntu for the past year or so, however; prior to that the last time I saw anything resembling a Unix environment was 1997. Back then I installed FreeBSD alongside Windows 95, because I got tired of the latter’s constant crashing.

On the other hand, if I could successfully get FreeBSD and Windows 95 both working on a dual-boot configuration in 1997, I feel like there’s not much I can’t do. Where I lack in intelligence I compensate with considerable intuition and implacable, obdurate will; I’m stubborn to a fault – a good trait when it comes to tinkering with computer operating systems.

And it’s especially good coming to Linux from Windows. As my best computer nerd friend – he doesn’t bother using package managers; he does everything from the terminal off the top of his head – Linux is a “completely opt-in OS; Windows is the exact opposite.” I’ll get to what he means in a minute, Windows users. Just remember:

Pigheadedness prevails.

LAMP: Linux, Apache, MySQL and PHP (or Perl, or Python, etc.). And how 'bout my mad Photoshop skills? Meh. Anyway, Ubuntu’s own documentation on installing LAMP and WordPress, as well as its specific docs on installing Apache will likely get you up and running without too much problem, even if you’re a complete Linux noob. You don’t have to, but I would suggest reading the Apache docs too; particularly if you are security minded; the Apache doc will show you how to edit the ports.conf file so your Apache server is only accessible by your local machine — it will only dance with itself on Port 80, rather than looking all over the world for every type of girl in any ole’ port.

But I digress. These two docs are fairly comprehensive without telling you a bunch of stuff you don’t really need to know or care about (unlike me; I’m often wont to digress). Then there is Ubuntu Geek’s tutorial on WordPress and Ubuntu 10.4 specifically.

And if you are completely scared of a do-it-yourself install, then you probably shouldn’t be messing around with Linux. I think it’s safe to assume if you’re looking for information on how to run a local Web server on Ubuntu so you can, in turn, run a local WordPress installation for development purposes, you must be reasonably tech savvy.

But then, on the other hand, there are more and more laptops/nettops/netbooks/tablets/what-have-you gizmos running Ubuntu or some other variation of Linux these days, and consequently more and more WinD’oh!s users are finding it necessary to get familiar with it. Plus, I would guess there are probably some folks out there that just don’t want to shell out for a new Windows 7 system disk when Ubuntu is free and relatively easy (times are tough, after all).

Alert: stuff you may not need to know/care about: But then Windows 7 is actually pretty stable and much more secure than previous incarnations, and rather easy on old hardware, particularly if you turn off the Aero bells and whistles. I’ve seen it installed on a decade-old desktop with a whopping 512 megabytes of memory, a 10 gig hard drive, and a creaky-old Pentium 4 CPU, and it ran really well, barely taxing this ancient box; I wouldn’t have believed it if I hadn’t seen it myself. It even booted a lot quicker than my Win XP laptop with its 3 gigs of memory, dual-core Intel CPU and 100 gig drive – and I had my XP boot pared down to the bare essentials. So there you go.

But generally speaking, Ubuntu is lighter on the hardware than Windows – even Windows 7 – and considerably more secure (although Vista and Win 7 go a long way towards addressing Windows’ lingering security issues). Plus, did I mention it’s free? And it’s open source, and it’s been around a long time now, so there is plenty of support, third party apps and so forth out there.

Close Windows, Turn on the LAMP, Ubuntu and WordPress

So I thought I might just point out a few things for Windows users who have seen the Linux light and who also happen to work with WordPress and want to get a local installation of it up and running for Web site development purposes. Of course this reflects my own experience, and what what follows is what works for me on my hardware; your mileage may vary depending on your particular version of software and hardware.

First off – and this is one of those tangents you may not care about, particularly if you came here from Teh Google — one of the odd things for Windows converts in a Unix/Linux environment is its concept of users, rights and security. As my previously-referenced computer nerd pal puts it, “You have to tell Linux exactly what to do; it’s never going to assume anything.”

Windows User Account Control: "Your user can't help you now, little program!"Up until Vista came along, if you had a login credential on a Windows machine – a user name and password – you could easily wreak havoc at will (and often inadvertently) in Windows. You were the God of the Keyboard; you could pretty much do whatever you wanted to (and so could anyone else). With Vista came the dreaded UAC, “user account control,” however, and notifications that you had to run various and sundry programs as administrator in order to do what you were trying to do.

I remember the first time I encountered this on a Vista box and thinking “WTF is this now? Did Microsoft steal a page from Apple’s playbook and just slap a fancy GUI over Unix and call it the new Windows OS? Or did they hire the Master Control Program from Tron?” Not quite either, of course, but still it reminds one of Unix.

The idea behind this is security; ostensibly if someone were able to remotely hack into your machine with bogus credentials (or were able to purloin your actual user name and password), the damage they could do would be limited, because they couldn’t run programs as an admin. They could not aspire to be the Keyboard God, but rather a minor, malicious cherubim or seraphim at best.

sudo /phil/collins/sussudio.conf ... surely I'm not the first to make this pun.This may have been novel for Windows, but old hat for Unix, Linux and their various derivatives, of course. When you log into Ubuntu you’re a user and as such you don’t have admin or “root” privileges; you’re low man on the OS user totem pole. You can of course temporarily elevate yourself to root – using the sudo or su command – but not the Sussudio command — in conjunction with some other command in a terminal (think DOS window in Windows), for example.

Even when it comes to files and folders, you can encounter this issue; files and folders are owned by certain users and other users and groups of users are assigned various rights accordingly – a file’s owner has read and write permission, but another user may only have read permission, or perhaps not even that.

There’s mountains of more info on this out on the Intertubes; Google and Yahoo are your friends. However I would suggest this Wikipedia entry on file system permissions if this is a completely new concept for you. It’s a pretty good yet brief overview of permissions and rights for various operating systems, and details rights and permissions used in Unix – and consequently Linux – environments and their notations. You’ll be down with the 411 on the 755 in no time at all, not to mention the -rwxr-xr-x.

On the other hand, if you’re a reasonably knowledgeable Windows user who can tinker underneath Window’s hood without breaking it, then file system permissions in Linux are seemingly a pain in the ass sometimes – you’ll miss having the god-like powers that Windows entrusted with you (or at least used to). Sometimes it does feels like you’re Flynn and you have to outwit the MCP. On the other hand, it’s why Unix/Linux is so much more secure – it’s much more difficult to hack into remotely. Plus it’s difficult for your non-techie friends and family to accidentally eff up.

Um, Yeah, LAMP? WordPress? Don’t Worry, I’m Getting to the Point

This issue of users, rights, and ownership is important to keep in mind when setting up your WordPress installation in Ubuntu. If WordPress folders – let’s call them directories since this isn’t Windows – subdirectories and files don’t have the correct ownership, rights and privileges assigned to them, it won’t work, or at least not well. You may be able to navigate to your local site, but WordPress won’t be able to create new posts/pages. Or it may be able to do this, but when you try and navigate to that new page or post, you’ll get the 404-not-found error. Furthermore, you won’t be able to update WordPress automatically, install plugins, etc.

So, with this in mind, in the section in the Ubuntu installation instructions where it says this:

For automatic updates to occur, the folder and all its files and subfolders must be owned by www-data:

chown -R www-data /usr/share/wordpress


The “chown” command is shorthand for “change owner” and the -R means the change is recursive; it applies to all subdirectories and files. Who is this www-data user? It’s a system user account that your Apache Web server creates to do its thing. And since WordPress relies on Apache to do its thing, www-data needs ownership.

Apache’s Running, WordPress is Installed and Using the MySQL Database, but I Got Nothin’

I learned about www-data the hard way. I had installed WordPress a number of times on Windows, in both XP and Windows 7, so I didn’t really think there would be much to getting it up and running on Linux. I installed Apache, MySQL and PHP individually via the Synaptic Package Manger in Ubuntu on my laptop and verified it was all running correctly. So far, so good. Went to phpMyAdmin, set up my databases for the WordPress sites I’m currently working on, downloaded the WordPress files and installed them in the various directories for each site, and proceeded apace – pretty much the same process in Windows.

Only I couldn’t actually see or navigate to any page locally beyond each site’s index.php file. I could create a new page in WordPress, and it showed up in the database, but I couldn’t see it when I tried to navigate to it in the browser. I solved this by giving the whole world access to all of my WordPress directories and files – 777 – but then I noticed I still couldn’t update automatically inside WordPress. Files would download, unpack, and then the install would fail.

A little more research revealed my issue with www-data ownership. Moral of the story? When all else fails, read the effing manual.

So now WordPress works fine on my local machine under Ubuntu, and I didn’t have to invoke Keyboard God mode. Huzzah. Beyond this, installing LAMP and WordPress on Ubuntu isn’t that different than it is in Windows.

Update: Don’t Assume Ubuntu Works Like Windows

So I just learned something else about this directory ownership issue. I was setting up a new site that will use WordPress on my Ubuntu box. The theme I installed for this site comes with some dummy data – pages, posts and comments – to populate the site, allowing you to experiment with its appearance.

Everything was fine until I went to import this data in WordPress via an xml file. WordPress kept asking for ftp login credentials, which it shouldn’t have to, since www-data has ownership of this new subdirectory I made in my www folder – or does it? After some hair-pulling and cursing, I looked and nope, ownership and permissions were assigned to my user account.

WTF chownED by Ubuntu’s MCP. Again.

I'm Linux! It's funny because it's true. I copped this from Whil Wheaton's blog. Dunno where he copped it from though.See, I’m a Windows refugee — well, not really, since I run Win 7 on my desktop box, and have  no compelling reason to switch. Although the next time I order something form NewEgg or Amazon, I’ll probably order another hard drive and slap Ubuntu or Kubuntu on it. I guess you could say bi-curiOS.

Anyway, since I assigned ownership to the parent directory to www-data and made that ownership recursive, I assumed – and we all know what happens then – that any new subdirectories created in that folder would automatically inherit www-data ownership and the characteristics of the existing parent directory. In Windows, of course, you can set the characteristics of a file folder to be recursive, and any subfolders you add after that will assume – heh – those same characteristics – although there’s no ownership, per se – not in the sense that there is in Unix/Linux.

As the aformentioned friend noted, Linux never assumes; you need to tell it if you want ownership to differ from the user account used to create it – which in retrospect makes sense. But like I said, I’m a veteran Windows tinkerer, and I’m used to being the Keyboard God, and not having to outwit the MCP.

But if you’re reading this, then I hope that my frustration is your gain.

ZOMG! WordPress running locally on Ubuntu.

WordPress in Windows: Part Two

Installing WordPress in Windows with WampServer

So, we’ve got WampServer installed on a Windows machine, verified that it’s working – no port conflicts – and we’re ready to forge ahead with installing WordPress. If you’ve just arrived from the Google, thanks to my search engine optimization (SEO) skills and/or SEO plugin, head here for Part the First of my modest WordPress in Windows tutorial. Otherwise, let us proceed to rock, in a computer nerd sort of way.

Step One: Setting up WordPress’ local MySQL Database

First thing’s first, and that’s setting up the database that WordPress will use. Launch WampServer if you don’t already have it running and left click on the system tray icon. In the resulting list of menu options, click on phpMyAdmin. If you’ve already used WordPress on a live Website – especially if you’ve ever migrated a WordPress site from one Web host to another – then you may be at least passingly familiar with this user interface for MySQL databases, phpMyAdmin.

phpMyAdmin: Danger Will Robinson! Root with no password!When you installed WampServer, you were asked if you wanted to create a user name and password for MySQL; if you did, I hope you wrote it down, as you’ll need this to log into phpMyAdmin. Otherwise the default is “root” with no password, and you won’t be asked to log in.

Now you may notice the warning that appears at the bottom of the initial page in phpMyAdmin (click on the image to the right to embiggen it and see). Unless other and nefarious persons use your computer with your Windows login credentials – your Mom, your brother, Skeletor, Jonathan James – or you plan on using your Web server to actually serve up Web sites to the Internet at large, I’m not sure it’s necessary to create a user name and password for phpMyAdmin.

On the other hand, phpMyAdmin isn’t terribly secure even with a user name and password; I wouldn’t use it to access a MySQL database for an online site from an unsecure connection – say a public Wi-Fi spot – unless I had to. Certainly wouldn’t want to make a habit out of it. But on your own computer that you’re not sharing? No worries, in my humble opinion. If someone physically steals my computer and managed to hack my Windows password, the last thing I’m going to worry about is that they get to see the new CSS I’m working on.

Time to Administrate that Local WordPress Install

phpMyAdmin: creating a new database is easy.So there’s phpMyAdmin; let’s get down to some database administration. We still need to create said database for our local version of WordPress. At the top of the page you’ll see a list of tabs; click on the one labeled “Databases.” At the bottom of this page you’ll see “create new database.” Enter the name of the database that WordPress will use.

You can name this whatever you want; if you just plan on creating one Website that uses WordPress locally, you can simply call it WordPress, if you want. If you plan on creating several sites locally – and with WampServer you can do this just as easily as one site – I would suggest naming it something relevant to the particular site — the domain name, perhaps — as all of your local sites will use MySQL databases which you can administer here through phpMyAdmin; you’ll want to be able to keep them sorted out.

In my example I’ve called my database Ralph, as you can see. But again, call it whatever you wish; call it database, or even Johnson. As for the other box, leave it to its default, Collation, and click create. And WAMP, there it is (and there’s that bad joke again). As you can see, Ralph is listed over in the left hand column of phpMyAdmin, along with the “information_schema” and “mysql” databases (these are databases used for MySQL’s internal administration; you don’t have to worry about them – at least as far as setting up and using local WordPress installations).

Okay, we’re done with phpMyAdmin for now. But keep the name of that database handy, if you think you can’t remember it, along with your phpMyAdmin/MySQL username and password, if you created one. We’ll need them for WordPress, which we’re finally ready to actually install.

Step Two: Unpack and Move WordPress Into Your Windows ‘hood

download WordPressSo, if you haven’t done so already, go to the WordPress Website and download the latest version of WordPress (3.1.1 as of this posting). Since we’re working on Windows you’ll want the *.zip file, of course.

Once that’s downloaded, unzip it and move all the files and folders to WampServer’s www directory (C:wampwww) or wherever you installed WampServer. Again, if you plan to make more than one local WordPress site, or think you might in the future, I’d suggest making separate directories – or folders (since we’re talking Windows, I suppose I should use Windows lingo) — in the www folder for each one. In my example here, I’m using a directory/folder called Ralph (C:wampwwwralph).

Installing WordPress in Windows: unpacked in the Ralph folder.So now my Ralph folder (C:wampwwwralph) looks like the picture at right, now that I’ve moved all of the WordPress files here.

Again, if you’ve used WordPress on an actual hosted Website, and you’ve used ftp to administer it or move files around, this should look familiar, and you can guess what we need to do next; in fact you could probably follow WordPress’ installation instructions from this point forward and be fine. But we’ll go through the steps just to be sure.

I should note here that when you unzip WordPress, all of the files and folders are themselves in a folder called WordPress; we want to move or unzip those files and folders inside the WordPress folder into our the Ralph folder, or whatever you call it.

Step Three: Configuring Our Local WordPress Install

Now we need to edit the wp-config.php in our WordPress directory; in this case that’s the Ralph folder. We would need to do this same step were we creating a WordPress site on a Web host out on the Internet, too. Literally what we’re doing is telling WordPress where the database is that it will use to keep track of all our site’s posts, pages, images, and whatnot.

And actually wp-config.php isn’t in our folder – yet – but wp-config-sample.php is (refer to the image above of the Ralph folder). Like WordPress’ own install instructions, I’ll suggest that you make a copy of this in the same folder and rename it wp-config.php; wp-config-sample.php will server as your backup. This way, if you make a hash of it, you can start from scratch. But don’t worry, this is pretty simple.

Configuring WordPress for a local installation in WindowsOpen the wp-config.php you just made in Notepad or Wordpad – don’t use Microsoft Word or OpenOffice or some other word processor, particularly one that uses xml, as both of these do. You’ll end up with a bunch of junk in your file that you don’t want.

Incidentally, the same goes for if you are writing a post in your word processor first and then copying and pasting into the text editor inside WordPress. If you look at the html editor you’ll see a bunch of unwanted code came along with the text, and will probably make your post or page look goofy.

If you plan on doing a lot of file editing – php, css, html, etc. – I can suggest Notepad++; it’s a great text editor that’s designed for working with code. Furthermore it’s got spell check and a bunch of other features; you could use it for everyday writing/word processing as well (plus it’s got tabs!). Here is the wp-config.php file opened in Notepad++; I’ve circled in red the part of the file we need to edit (see the image on the left).

To wit:

/** The name of the database for WordPress */
define(‘DB_NAME’, ‘database_name_here’);

/** MySQL database username */
define(‘DB_USER’, ‘username_here’);

/** MySQL database password */
define(‘DB_PASSWORD’, ‘password_here’);

/** MySQL hostname */
define(‘DB_HOST’, ‘localhost’);

/** Database Charset to use in creating database tables. */
define(‘DB_CHARSET’, ‘utf8’);

/** The Database Collate type. Don’t change this if in doubt. */
define(‘DB_COLLATE’, ”);

Unless you made changes or used options beyond what I’ve discussed here, the only thing you need to worry about is the MySQL database name, username and password (DB_NAME, DB_USER and DB_PASSWORD); the default settings for hostname, charset and collate type in our WampServer setup should be the same as what is listed here.

  • Where it says ‘database_name_here’ enter the name of the database we created earlier in phpMyAdmin; in my case, that’s ‘ralph’. Make sure you keep the single quotes.
  • If you didn’t assign yourself a user name when you set up your MySQL database with phpMyAdmin, then where it says ‘username’ (in between the single quotes) type root, as in ‘root’. Again, be sure to keep the single quotes.
  • If you didn’t assign yourself a password then you can just delete password_here from between the single quotes – but leave the single quotes in place, with nothing in between them.

So in our example those three lines should look like:

/** The name of the database for WordPress */
define(‘DB_NAME’, ‘ralph’);

/** MySQL database username */
define(‘DB_USER’, ‘root’);

/** MySQL database password */
define(‘DB_PASSWORD’, ”);

Save these changes to wp-config.php, and close your text editor.

Step Four: Login to Your Local WordPress Install,
See if You Done Good

Yay! We installed everything right, and WordPress is running locally in Windows.Now we’re ready to log into our local WordPress installation. Open your Web browser and go to http://localhost/whatever-I-named-my-WordPress-folder/. In my case, that’s localhost/ralph/. If we did everything right, then we should see this, the initial installation screen for WordPress (on the right).

If you see this screen, congratulations; WordPress is installed and running locally on your desktop or laptop. From this point things are pretty straightforward – provided you remembered to enable the Apache rewrite_module.

If you’re thinking “what?” then check back at the end of the first part of this local WordPress installation tutorial. I’ll stress this in caps, even: ENABLING THE APACHE REWRITE_MODULE IS IMPORTANT! If this module isn’t enabled you may be able to see WordPress – if you are copying over an existing installation you can even navigate to your local site’s homepage and WordPress admin page, but if you try and navigate to any other pages, you’ll get 404 file-not-found errors.

As for the rest of the WordPress install, it’s up to you if you want to use a username and password for your WordPress admin login – well sort of. It used to be that way. Again, unless someone else has access to your computer and you share login credentials/user accounts for Windows, there’s not much worry. Certainly, if this were the case, I would password protect my WordPress admin login, just as I would for a Web hosted installation. But for my own computer, I don’t bother, to be honest.

However, the latest versions of WordPress now create a random password for you, if you leave the password sections blank – hence the “sort of/used to.” You can change this to something else later on, but you can’t leave the password blank, so it’s easiest to just set up an easy to remember password here at the initial install screen. Myself, for my local installs I usually stick with admin/admin or root/admin or some such combination of user/password that’s easy to remember.

You can uncheck the “Allow my site to appear in search engines” box, but unless you’ve configured your local server to be public in your WampServer setup and enabled external access in your firewall – and of course you’re using a firewall, because it’s Wind’oh!s – there’s not much worry. I suppose if you are running a public Web server from your home machine, some search engine spider could crawl your IP address and find your local development site.

So go ahead and name your site – you can change this later on in WordPress, of course – and enter your email address. WordPress will insist on this, so you’ll need to enter it. You can actually set up the mail function later on, if you wish – not sure I see the point for a local installation, but again, it’s up to you.

At this point, if we go to localhost/ralph (http://localhost/ralph) we see the default WordPress theme and the default “first post” and comment. If you navigate to localhost/ralph/wp-admin you can login into WordPress just like you would if you had installed it on an remotely-hosted Website.

That’s pretty much it. From this point you can begin experimenting with themes, plugins, CSS, page layouts, widgets, sidebars and so on and so forth. Or if you want to add content so that when you do put your live site up on your Web host, you have a bunch of content ready for your site visitors’ perusal, you can.

Pretty cool, huh?

Wait, what? How do you migrate a local site to your live site online, once you finish tinkering with it, you ask? I’ll save that for another post, but it should be pretty straightforward if you’ve gotten this far. But here’s a quick and dirty synopsis if you can’t wait and suddenly forgot how to use a search engine.

Uploading Your Local WordPress Site to Your Web Host

  • Export your database (as SQL) from phpMyAdmin (compress it via zip or tar to be on the safe side; default MySQL installs have a limit of how big a database it can import). As a backup method, also use WordPress’ export function, which exports all your relevant data in a single xml file.
  • Import your database into your MySQL installation on your Web host (you can probably do this from your host’s cPanel or something similar, or from phpMyAdmin. If you have problems here – different versions of MySQL or phpMyAdmin can be fussy about importing databases from one another – just create a new database with the same name; you can import that WordPress xml file later.
  • Upload your WordPress files (via ftp/sftp, cPanel, or whatever file manager your Web host provides).
  • Configure your wp-config file accordingly (database name, user name, password – you should definitely be passwording your online installation, of course; these can be different from what you used on your local machine; you don’t have to use the same ones).
  • Navigate in a browser to wherever your “index” page would be for your hosted site; if everything went well you will probably see a page telling you that WordPress needs to update its database and asking you to click “OK;” then it should take you to the admin login.

If you’re using a fresh install of WordPress, you’ll need to manually configure any plugins you use with your site; you’ll also won’t be asked to update the database. At this point you an also import your old WordPress site at this point by importing the xml file you exported on your old or local installation.

You’ll also likely need to fix/update your WordPress permalinks, depending on how you have your local installation of WordPress installed. For example, locally my site’s home/index page (index.php) is at http://localhost/ralph; if I had a page created in WordPress called Photos it would be at localhost/ralph/photos. On my Web host, assuming I install WordPress to my assigned root directory, my site would be at simply http://ralph (or whatever my domain name is); the Photos page would be at ralph/photos. Any internal links to the Photos page would need to be fixed, as they would still be pointing at localhost/ralph/photos (if I had installed locally to my root folder in WampServer, C:wampwww, then my links to Photos would be fine, assuming my domain name/URL I’m using on my Webhost is http://ralph).

There are several different plugins you can choose from to update your links automatically – the one’s I’ve used have worked fine, and you only have to run them once. Of course, if your site is fairly simple, you can do it manually from within WordPress for your various pages, too.

Well, that was  little longer than I intended — but I’ll address this topic later in a more in-depth post.


WordPress in Windows

WAMP it into Shape: Installing WordPress Locally Under Windows

You can easily install WordPress locally on WindowsI’ve been working with WordPress in one way or another – personally and professionally – for several years now, but it’s only been in the past year or so that I began to feel the need to have a local installation. For the non-nerd reading this, that means having a Web server and database installed along with WordPress on my own computers – desktop and laptop – so I can work on and develop sites offline.

Whether creating a new WordPress Website or working on an existing one – say changing or modifying a theme, or trying out new plugins/developing your own – or developing some other sort of site or Web app that requires something more than simple html, it’s nice to be able to work locally, offline. This is especially true if you have an existing site that you don’t want to risk breaking. Of course you can create a subdomain of a live site for development and experimental purposes, but I find it’s easy to just do it locally then upload the files when whatever it is I’m working on is ready for the public eye.

Certainly this idea is nothing new to Web developers and programmers, and for the technically savvy, it’s rather simple to setup a local Web server and do this. But then there are many people blogging nowadays or otherwise using WordPress as a content management system for their or their employer’s Websites who probably still think of Native Americans if they here the word Apache, as opposed to Web server software. It wasn’t too long ago that I would have fallen into this latter category.

Thus it is with these people in mind – as much as for my own edification and future reference – that I take pen to paper (er, rather, keyboard to LibreOffice Writer) to help elucidate how to go about setting up and installing WordPress locally on your own computer. I’ve done this on both Windows XP and Windows 7, as well as Ubuntu. When I originally set about setting up WordPress locally, I found a lot of helpful information on various blogs, so you could say this is just my effort to pay it forward and add to the pool of DIY knowledge of Web nerdom and/or geekery out there on Teh Internets.

With that said, bear in mind that this is what works for me on my particularly hardware and software; it may or may not work for you, for a variety of reasons – no, this is not rocket science, but this is computer science. As such it can get wee bit complex.

WAMP! There It Is!

To work with WordPress locally, you need to set up a Web server on your computer, one that can accommodate MySQL database management and the PHP scripting language; these are two basic components of WordPress; this is what’s under the hood. Typically you’ll want to use Apache for your Web server; this free and open-source server software is pretty ubiquitous these days, and there are versions available for just about every operating system (OS) there is. The odds are your own Web host uses some version of it, and it gets along just fine with the software that WordPress uses.

Of course if you’ve used WordPress before, you’re probably familiar with some of the PHP files it incorporates, and have probably used phpMyAdmin, a Web-based user interface for MySQL.

WampServer 2: Apache, MySQL and PHP on WindowsYou could install Apache – or some other Web server software – MySQL and PHP individually on your Windows machine. Or you can opt for easy mode, and install it in one fell swoop, with WampServer 2. WAMP is an acronym for Windows, Apache, MySQL and PHP (or Perl or Python) – W-A-M-P. Because we can’t talk tech without an acronym.

But it’s no joke: WampServer 2 makes getting all this up and running on your Windows box almost ridiculously easy. There are other WAMP packages out there besides WampServer 2 (previously WAMP5) – XAMP is another one, for instance. Wikipedia has a nice comparison of the various WAMP packages out there; there are plenty of options. But WampServer is what I use, as I’ve had almost no trouble at all with it under both XP and Win7, and can vouch that it will work just fine with WordPress. A further bonus: it’s open-source software and free to use – although I’m sure it’s author, Romain Bourdon, would appreciate a donation via PayPal. Vive le Français!

You can learn more about WampServer — how to install it and how it works with Apache, PHP and MySQL — and there you can also download both 32-bit and 64-bit versions, depending on what version of Windows you are using. Currently I’m using the 64-bit version of WampServer 2.1 on Windows 7 Professional; I’ve also used WampServer 2.0 on my ancient XP laptop (which is now an Ubuntu laptop).

Step One: WampServer is Easy Mode for a Local WAMP Install

So download it, install it, and run it just like you would any other software package. You may notice during the installation, however, that WampServer’s default installation process doesn’t install to Windows’ usual Program Files directory. Left to its own devices, WampServer creates a root directory under Windows (C:wamp), where you’ll find a www subdirectory (think of it as your local Word Wide Web), among others (C:wampwww). It is here where your local WordPress install will reside. You can of course install WampServer and the related files and sub-directories/folders wherever you wish, but to keep things simple later on, I’d suggest sticking with this default setup.

WampServer is online in Windows -- as indicated by the system tray icon.When WampServer is running, you’ll see a little icon in the Windows system tray. In 2.1 on Win7, the tray icon is a stylized W; on 2.0 under XP it was a little analog dial. With this latest version it’s easy to tell if it’s offline or online; online it’s green; offline it’s red – green go, red stop. Simple enough, yeah?

An important thing to note: WampServer uses port 80 – or rather, Apache does — and this can sometimes conflict with other apps that also use this port, namely Skype. You can assign different ports for your various software – just make sure the ports you assign are not used by other apps. But if you want to keep it simple, just open WampServer first before you open Skype; Skype automatically chooses another port if port 80 is taken, and you can then run both Skype and WampServer happily at the same time.

If you launch WampServer and it can’t seem to get online within a few moments, it is probably some sort of port conflict; if you have Skype running it almost certainly is (speaking from personal experience here). Also note that WampServer must be online for you to access it locally – which you can do even if your computer itself is offline, i.e, not connected to the Internet.

You shouldn’t have any problems with Windows Firewall running WampServer; it automatically sets up an exception for the Apache server for local use during installation. Again, if you have trouble with it getting online, I would look for some sort of port conflict first. Of course if you run a third-party firewall, you may need to manually enable an exception for WampServer – or if you want to actually use the Web server for consumption out there on the Intertubes.

Step 2:
Verify Your Local Web Server is Up and Running — and Writable!

the WampServer 2 menu in WindowsSo, if you have WampServer up and running and online, we’re just about ready to start installing WordPress; there’s just one more thing to do and that’s make sure everything is copacetic with our install. Left click on the WampServer tray icon; you’ll be presented with a menu list – here you can start or stop WampServer, make changes to your Apache, MySQL and PHP configurations and navigate to your local directory where your Websites will reside.

In fact, if you click on the first option, “localhost,” you should see an information page open in your Web browser that provides details on your WampServer installation: the versions of Apache, MySQL and PHP it is using, configuration tools, links to the local directory and subdirectories, and so forth. This page you see is actually just a PHP file in your root directory (C:www) that WampServer creates during its installation. If you enter http://localhost/index.php in your browser when WampServer is running, you’ll see the same page; you can see an example from a screen cap at the bottom of this post.

Of course if you can see this page, then everything is hunky dory with WampServer. There’s just one more thing to do, but this is important, particularly for Windows 7 and Vista users. We need to make sure that WordPress has the rights to create, edit, and delete files in our www folder/directory. To do this:

  • Finding the Apache rewrite_module in WampServer 2right click on the WampServer tray icon to get the WampServer menu (pictured above)
  • right click on the Apache item to expand the submenu
  • right click on the Apache Modules item to expand that submenu (pictured to the right)

Now you should see a long list of modules that can be enabled in WampServer’s Apache configuration; you’ll probably have to scroll down to see the one we need to enable, the “rewrite_module.” Click it to enable it; if it has a check mark next to it – as in the image you see here – it’s enabled and you’re good to go.

Okay, we’re done tinkering with WampServer and ready to get rolling on that WordPress install. But this post is long enough; go here for the next step in this tutorial for installing WordPress under Windows.

The WampServer 2 landing page - index.php. If you can navigate to this, everything installed and is running correctly.