a free hosting service run by Automattic using the multi-site version of WordPress (originally WordPress MU). You can install themes and plugins through the Dashboard but you can only enable or disable the choices that come preinstalled. Further, you will not have access to the underlying MySQL databases and core code, or be able to integrate WordPress with other systems. You can redirect one of your own URLs to wordpress.com, but if you want full control over everything from the code to the URLs used, you are probably looking at a paid option. The free route may be a reasonable first step for you, but for this book it is assumed that you are going to want to perform surgery on your installation.
You will find a starter list of for-fee hosting providers on www.wordpress.org, including the paid option on wordpress.com. Most have the latest, or close to latest, releases of the WordPress core available as a package to be installed in conjunction with MySQL and a web server. The third hosting option is to install everything on servers that you own and operate. If your servers live in a hosting facility but you enjoy root administrative access that is equivalent to a do-it-yourself installation. These are all options for putting your WordPress installation on the public Internet. If you are just looking to explore, Chapter 3 covers running WordPress locally for development.
WordPress requires a web server with PHP support, a URL rewriting facility, and an instance of MySQL. Apache is the most popular option for front-ending WordPress because it provides PHP interpretation through mod_php and URL rewriting in mod_rewrite. There is growing interest in lighttpd (Lighty) and nginx as replacements for Apache. Finally, you can use Microsoft’s IIS 7.0 as a web server with its URL_rewrite module. The emphasis on URL rewriting stems from WordPress’s support for “pretty” permalinks to content entries, allowing you to create a URL tree organized by date, category, tag, or other metadata. Those mnemonic, or human-readable, URLs are converted into MySQL database queries to extract the right WordPress content based on titles or other keywords as part of the WordPress main loop, which is covered in detail in Chapter 5. Your web server decides whether the URL should be parsed by WordPress or if it refers to a specific HTML file based on what is in the .htaccess file, and the URL rewriting rules ensure that its contents are interpreted properly. Technically, URL rewriting is not required to install WordPress, but it is good to have because it gives you tremendous flexibility in the presentation and naming conventions used for your content’s URLs. Permalink design and practices are covered in more detail in Chapter 2, but keep the requirement in mind as you select your WordPress substrate.
Up to this point, MySQL has been mentioned only in passing, but a brief review of MySQL requirements rounds out the hosting prerequisite list. It is worth establishing some terminology and distinguishing between the MySQL software, database instances, and WordPress instances using MySQL. When you install and configure MySQL, you have a full-fledged relational database system up and running. It does not have to be configured on the same machine as your web server, and some hosting providers will create horizontally scalable MySQL “farms” in parallel to their web server front ends. An instance of MySQL running on a server can support multiple databases, each with a unique name. When you install WordPress, you will need to know the name of the MySQL database reserved for your content, although this information may be auto-generated and configured for you if you are using a provider that supports WordPress and MySQL as an integrated package. WordPress creates a number of relational data tables in that named database for each website that you create.
Confusion can result from nomenclature and complexity. You (or your hosting provider) may run multiple MySQL instances on multiple servers, and you will need to know where your database is hosted. Because each instance of MySQL can run multiple databases, and each database contains groups of tables, it is possible, even common, to run multiple MySQL-based applications on the same hosting platform, using one MySQL instance or even one MySQL database.
If you want to have multiple WordPress sites on the same server, you can share a single MySQL database instance for all of them provided you configure WordPress to distinguish the MySQL database table names within the MySQL database. It is a simple configuration option that is covered in the next section, and it highlights the distinction between multiple sets of tables in a database and multiple databases for distinct applications.
Once you have secured the necessary foundation, it is time to get the code up and running. Even if you are using a hosting provider that installs MySQL and WordPress for you, it is worth knowing how the server-side components interact in case you need to track down a problem when you’re deep in plugin development.
The famous, fabled, fabulous five-minute WordPress installation is a reality when everything is configured and coordinated properly. This section walks you through the steps that are often hidden from view when you use a provider with packaged installs, and highlights some of the common misfires between WordPress and MySQL instances.
The installation process is quite simple (assuming that your web server and MySQL server are already running): Download the WordPress package and install it in your web server’s directory tree, and then navigate to your top-level URL and complete the configuration. One (compound) sentence describes it completely.
It is possible and even advisable to install a fully functioning WordPress instance on your laptop or development machine, particularly if you are going to be working on the core, developing plugins, or otherwise making changes that would create embarrassing failures during testing on a public website. Mac OS X comes with an Apache web server (with PHP and URL rewriting); download MySQL from www.mysql.com, or use a prepackaged configuration such as MAMP (www.mamp.info, which includes the phpMyAdmin tool), and you will have a self-contained development and deployment lab. For other platforms, XAMPP (www.apachefriends.org) has a neatly integrated platform stack that runs on Windows, Mac OS, and Linux foundations. Furthermore, the use of virtual machines for your development environment has grown immensely, and now there are packaged VM solutions to get you started. Having everything under one hood is a powerful option for examining failure modes, as you will see in the next two sections. More information on working with WordPress locally is covered in Chapter 3.
Installing WordPress Files
If you download the WordPress code from wordpress.org, you will get a zip (or tarball) archive that expands into a directory called wordpress. The first part of a WordPress installation is to get the code into your web server’s directory structure; ensuring you have it in the right place is a critical step. Gloss over this part and you will find your website ends up with a URL like http://example.com/wordpress and you will either have to start over or e-mail ugly URLs to your friends and family. If that is what you want – to distinguish your WordPress site from other content on your website or to isolate multiple sections – choosing the filesystem layout is equally important.
Pick the top-level directory where you want to install WordPress. Most commonly, this is the root directory for your web server, and if you are using a hosting provider it is probably the subdirectory called public_html in the file tree. If you are using a packaged install where there is a menu asking you for the target location, make sure you pick this top-level directory (and yes, you know that it already exists, that’s the point!); if you are copying files from your local machine to the web server target using an FTP client, make sure you pick the right destination. The somewhat obvious move to copy the zip file to the server and then unpack it will put everything into a wordpress subdirectory, and if you want your WordPress site’s URL to be http://example.com rather than http://example.com/wordpress, move the files up one directory level before proceeding. There is a configuration option to have your WordPress installation in a subdirectory to your top-level URL, so it is not fatal if you drop WordPress into a less-than-desirable filesystem geography. That is covered at the end of this