My WordPress Installation
I have just installed WordPress on my home network, and appear to have emerged unscathed.
More than that, in fact. I now have a robust, modern blog-server and have also learned a great deal about MySQL.
Abstract (who me?)
Why did I build a blog server? Good question. The foremost reason was to understand the technology, learn how the various components fit together, and get some sort of grasp on where we’re all headed with Web 2.0 and beyond.
So yes, it was a technical exercise. I had no intention of publishing a blog.
Ironically, the more blogging technology one plays with, especially the underlying systems like Google Webmaster Tools, sitemaps and such things, the more one relies on regular and relevant content for its success.
Unlike a banking application for example, the success of a blog is not simply dependent on correct technical installation, efficient webservers or high-availability ADSL links; the success of a blog is largely influenced by social components like link sharing, search engine optimisation, and old-fashioned word of mouth to generate traffic.
Planning & Prepatory Work
I wanted to install WordPress on a development system. It’s new software, and software I’m largely unfamiliar with, so I used a test system rather than run the risk of jeopardising customers on a production system.
This meant I had some extra ground-work to do. My development system is a Fedora Core 3 server sporting a modern, rather fashionable Pentium 133 MHz with 64 MB of RAM. This might come as a surprise to many Windows-users when they learn that a machine with these specs can run an Apache web server and an SQL server with WordPress on top. But that’s what it’s doing. Such is the world of Linux.
Most of the ground-word was installing the latest packages for Fedora Core 3. WordPress has minimum platform requirements. For version 2.0 these are:
I upgraded my server to the latest (last?) supported packages for FC3.
The online WordPress documentation was invaluable.
MySQL
SQL stands for Structured Query Language and is a common way for applications to communicate with databases.
MySQL is a very popular, open-source database engine for Linux. I needed to install three specific packages on my development server:
- mysql
- php-mysql
- mysql-server
PHP is a web page scripting language which is understood by many web servers. PHP allows developers to write webpages which are created dynamically by the web server when they’re requested.
The php-mysql module provides a web-based interface for the administration of the MySQL database engine; this interface is written in PHP and is known as phpMyAdmin. By using phpMyAdmin, it is easy to configure the database from a graphical interface in a web browser, instead of trying to do it all with command-line instructions at a “mysql” prompt.
I did experience some difficulties setting up databases for WordPress, and setting the correct permissions for the “wordpress” user. Make sure the “wordpress” user has full access to your new WordPress database. Use the command line to test if need be, by logging on as the “wordpress” user.
Installing WordPress
This was surprisingly easy. I simply followed the directions in the online WordPress documentation.
WordPress itself is a collection of PHP files and configuration files, which reside in the root of your web server. Blog content and postings are stored in the database you created. Plugins and themes are stored in subdirectories.
Configuring WordPress - Issues with Permalinks (updated 13/06/2007)
A Permalink is the URL to a blog post or page. Once you post to a blog, the URL should remain unchanged because it will be indexed by search engines, it will be linked to by other bloggers and it might even be added to people’s bookmarks and favourites.
The default permalink structure used by WordPress looks like this:
- http://www.drron.com.au/?p=123
This is a bit unsightly, and is hard to interpret if you’re not a web server. “?p=123″ is also meaningless to a search engine, whereas “dr-rons-holiday-snaps” makes a bit more sense.
To change your Permalink structure into something more appealing, WordPress supports an additional two formats and also allows you to create your own. From the WordPress dashboard, click “Options / Permalinks” to change the format. I wanted to change my Permalinks to the Date/ Postname format, i.e.:
- http://www.drron.com.au/2007/06/13/sample-post/
Note that WordPress doesn’t create a new directory structure to hold your posts, instead it uses virtual directories for you to retrieve your posts.
Note too that if you already have a number of posts on your WordPress blog that might have been indexed by search engines for example, these links will all break as soon as you make this change. To combat this problem, there are Permalink Redirect Plugins <– like this one (although I can’t vouch for its effectiveness, I’m not using it on my blog).
In changing my Permalink format, I did run up against some permissions problems on my Apache web server. For those interested, or in case it’s relevant, I’m running httpd-2.0.53-3.4.legacy on a Red Hat system.
In addition to the permission problems, I also found that WordPress tries to write to the “.htaccess” file in the root of your blog. I had to change the permissions on this file to stop WordPress from changing it and bollocksing it up:
- Add this to the top of the .htaccess file, before anything else: “Options +FollowSymLinks“
- Remove the write permissions on .htaccess to stop WordPress from trying to help: “chmod 555 .htaccess“
Also make sure that in your site’s httpd.conf file, the “AllowOverride” directive for your WordPress directory is set to “All”, not “None” which is the Apache default.
If you don’t do these things, you may find that after you make the Permalink change in the WordPress Control Panel, you start getting “Permission Denied” errors when you write a new post or edit an existing one. This is what was happening to me after the Permalink change.
Johnathon Brazil’s blog was very helpful and explains these issues in more detail. This post on Recommended Web Tools was also relevant and helpful.
Possibly helpful tips?
- Remember if you make changes to your httpd.conf file, reload httpd for the changes to take effect, like this: “service httpd reload“
- Keep an eye on your server’s error log, which might give you some helpful clues. I was getting plenty of these: “Options FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden” which gave me something useful to Google.
To be continued… I will keep updating this page as I encounter & resolve issues with my WordPress installation.
Update 24/06/2008 - server upgrade!
After a year of my poor little development system running a fledgling WordPress server, at last I have migrated the blog to a bigger, better platform.
The P-166 with 40MB of RAM, running the Red Hat 7.2 operating system, was starting to struggle under the load. People were saying “Hey Dr Ron, your blog’s kinda cool, but runs pretty slow”. Well, they weren’t actually saying the bit about it being kinda cool, I just made that up. Anyway, I decided after a year that maybe blogging was something I would continue doing, so Graeme Callaghan and I set our minds to building a brand-spanking new Fedora 9 system.
The new platform is a PIII-450 with 256MB of RAM and was donated to the cause by a work colleague, having been destined for the scrap heap (”it’s way too slow to run Windows, it’s useless, I’m throwing it in the bin, have it if you want it”).
We set-up the system to run in text-mode and installed a firewall, a name server, a time server, and a DHCP server. This system now does Network Address Translation on my home network. Graeme also loaded Squid which is a proxy server, to make my web browsing a more enjoyable experience.
One thing that jumped out at me, installing Fedora 9, was how EASY it has become. I’ve got to the point of writing this blog on a brand-new server without downloading any source code, or untarring or ungzipping, or compiling anything. This is very different to the process we went through in 2002 when we built the Red Hat system. Linux has come a long way in a short time.
Graeme decided enough was enough at 1:30 A.M. on a school night, and left me to my own devices. Again, I found it very easy to install the Apache web server, the MySQL database engine and the WordPress blog software. I used the magical yum for each of these packages without a hitch. Instead of downloading source code, compiling, fixing broken dependencies and mucking around, you just type “yum install wordpress” for example, and the yum updater takes care of everything. Again, we’ve come a long way in a short time.
The “export old database/ import to new system” process worked very smoothly. There was some wrangling with Apache vs WordPress, with respect to file permissions, and I seemed to recall being down this road before. After a few hours of fiddling around, my blog appeared on the new server! Cool.
Hopefully you notice the speed improvement. I certainly do!
Update 08/07/2008 - Search Engine Optimisation
Hundreds of thousands of articles have been written about the “best way” to optimise your website for good search engine rankings; specifically, good Google rankings.
But it’s not an exact science. Here’s some stuff I’m trying at the moment:
- I added Meta Tags to the header.php file, which lives in my WordPress /wp-content/themes/default directory. Meta Tags aren’t added to WordPress blogs by default. There are also meta tag plugins for WordPress if you don’t feel comfortable text-editing your PHP files. I’ve added “description” and “keywords” tags which I’m hoping the Googlebot will relish. For more details, have a look at this article: Adding meta tags to Word Press blogs.
- I added a Site Map to the WordPress directory root. This is an XML file designed for search engine robots, which contains information about what documents are stored where, and their relative importance in your site. You can code this manually (I did) or use a WordPress sitemap plugin, like this one.
- I added a robots.txt file to the WordPress directory root. This is a text file, also designed for search engine robots, which contains information about which pages you want crawled. You might want to limit search engines to crawling just the front page of your site, or restrict them from crawling comments (which might contain duplicate content in quotes and replies), or you might even want different search engines to crawl different pages. This is where the robots.txt file is used. If you don’t have one, search engines will just crawl everything. Again, code this manually (I did) or use a WordPress robots.txt template like this one.
- I created an iGoogle account, then set up Google Webmaster Tools. This makes Google aware of your site and schedules it for crawling and indexing. Link back the sitemap and robots.txt files in Webmaster Tools. Verify the site by adding a meta tag or a file in the web root. This is all explained in the Google Webmaster Tools online help.
More soon! Dr Ron.