WordPress MU – a bit too limiting
One solution to this is to use WordPress MU which allows you to run many blogs in the same installation. The problem with WordPress MU is that it is quite a hassle to install, and it requires the kind of server access that you won’t have if you run on a standard shared hosting account. Another problem with WordPress MU is that it is usually a few versions behind the regular WordPress, so the latest and greatest (and most secure) features and plugins won’t always work. The WordPress people have stated that moving forward WordPress MU will be one of their areas of focus, so I expect that all the negative stuff I just mentioned will be gone in a year or two, but I want a solution now!

WP-Hive to the rescue
Lately I have started to use the WordPress plugin WP-Hive to solve my multimple WordPressblog problem, and so far it has worked very nicely. Install WordPress and the plugin according to the plugins documentation, it requires some copying of files but otherwise it is pretty much like the standard WordPress install. After you have one blog setup with WP-Hive you can add more blogs to the same WordPress installation, each blog with it’s own domain name and it’s own unique settings. The great thing is that all the blogs you install will share the same basic WordPress installation, the same plugins and the same themes. So you only need to update WordPress or a plugin once and it is updated for all blogs, that is a real time saver. Since WP-Hive is a WordPress plugin you can also use the latest and greatest WordPress verison and all the other plugins that you want.

At the moment I am running some Swedish wedding sites this way, for example Bröllopsinbjudningar, Bröllopsmeny and Bröllopsbukett. They all use the same plugins and the same theme, but all have different settings and different content. With some help from WP Super Cache all my blogs are running nicely from a shared hosting account. The only negative thing I have noticed is that if you have several domains starting with the same letters (“br” in my case) you need to do some manual setup in the database to get things to work.

Do you use something else than WordPress MU or WP-Hive? Tell us all about it!

Basic setup
I assume you have WordPress installed on your local computer, including a MySQL database and all. There is a really good guide on how to do this on WordPress.org. Once installed I also assume you have played around with your theme and settings and gotten the WordPress site to look and work just the way you want it.

My second assumption is that you have an account at a web host that supports PHP and allows you to setup a MySQL database. If you don’t then you can easily find many good cheap options via my web hosting price comparison site WebHostNinja.com. Many web hosts have one-click installs of WordPress, but this is nothing you need right now.

My third assumption is that you have a domain or subdomain where you want to have your fantastic WordPress site installed on. In this post I use the target domain name f1almanac.com, since that is the latest WordPress site I have deployed. Of course you need to replace “f1almanac.com” with your own domain name in all examples below.

Move the files
The first thing to do is to copy all your WordPress files from your local computer to your webhost. In my case this is all the files under /projects/f1_wp/ that I move to the directory on my host that corresponds to the domain I have choosen. For now just move all the files, no need to change anything in any file.

Move the database
Next thing is to move the database structure and all it’s content from your localhost to your web host. First of just do a MySQL dump of the structure and content of your WordPress schema. This can be done in most MySQL GUI applications. Personally I use Sequal Pro and there the MySQL dump option is hiding under File->Export. Refer to the help files of your MySQL GUI app (or MySQL command line if you are hardcore) how to do a dump. The dump should result in a .sql file containing SQL statements to create all tables needed as well as inserting all the data needed into those tables.

Now we need to change some stuff in that .sql file. Open the file in a text editor and replace all local URLs to the URL of your new site. For me this means changing “http://localhost/f1_wp” to “http://www.f1almanac.com”. Without doing this your production WordPress installation would refer back to your localhost, and stuff would just not work. As always with search and replace, take it easy so that you dont break anything.

Create a new MySQL database on your web host, and open phpMyAdmin (or MySQL client of choice) for that database. In the “Import” tab of phpMyAdmin you can import an SQL file, so choose your newly edited .sql file and click “go” to import it. This creates all the tables needed and fills it with all the content you need, this includes pages, posts, plugin settings etc.

Change database configurations
At the moment the WordPress installation on your web host do not connect to the newly created and populated database, to do that just open wp-config.php on the host in a text editor (this is one of the files you uploaded to the host ealier). In the top of the file you find all the DB settings, so change DB_NAME, DB_USER etc to correspond to your new MySQL database and not your local database.

Once that is done you should have a fully working WordPress installation on f1almanac.com, or at least on your own domain

Final touches
Now things are working fine, but there are still some final touches before all is done. First of all your should probably login to /wp-admin on your newly deployed site and change the password of your admin user. I use extremely simple passwords on my localhost while developing, but I do not want to use simple passwords when things are live. So if you work the same way as me go and change the password to something harder to crack than “guest”…

Last thing to check is that your media files are uploaded to an existing directory. Login to the WordPress controll panel and go to Settings->Miscellaneous. It is very likely that the “Store uploads in this folder” is set incorrectly, since it was set when you installed WordPress on your localhost. Change it to the default “wp-content/uploads”, otherwise you will not be able to upload media files successfully.

That’s it. This is a technique that has worked fine for me many times, but I am sure smarter people than me has better solutions to this. If you are one of those smarter people please share them with us all in the comments of this post…

Before getting started I want to thank Alexis Bellido at ventanazul.com for his patients with my Django questions, check out his post Django questions and answers with a Swedish guy for some more info on Django setup (if you didnt figure it out I am that Swedish guy).

Installation guides
When I set up Django locally I wanted to make my local development environment as similar to a production environment as possible, it will hopefully make production deployment easier down the line. To do this I am running Python 2.5, Django 1.0, PostgreSQL 8.3 (and thus the neccessary python driver psycopg2) and mod_python on Apache. There are some good installation guides out there, so setting up this stuff was mostly a walk in the park, check out the install guide in the Django Book, the quick install guide at Django Project or the install guide at WebMonkey. Of course there are some gotchas that took me quite some time to figure out…

Uninstall old versions of Django
Before getting started I already had Django 0.96 installed, and I  just installed Django 1.0 over it assuming that it was going to replace the old version. I was wrong and when I tried to run my new Django installation I got errors like “NameError: name ‘url’ is not defined” and “ImportError: cannot import name WEEKDAYS_ABBR” – neither which made much sense to me. It turns out that if you do not uninstall an old Django installation first you get a mix of new and old Django files, and that just do not work very well. So take care to acctually read and follow the instructions at Remove any old versions of Django.

Use the right version of the db driver (duh!)
To get the PostgreSQL working correctly with your Python install you have to use a version of the driver Psycopg2 that matches both your Python version and your Apache version, otherwise things just do not work and you do not really get a helpful error message. You can get the window versions of Psycopg2 here.

Configure Apache for mod_python
Once Django and Apache are installed you can create your new Django project (via django-admin.py startproject myNewProject) where Apache can find it (in htdocs for example). To be able to use Apache as your webserver you also need to install and configure mod_python. Installing is straight forward (see the install gudies above for more info), but configuring Apache took me some time. You need to edit httpd.conf and add the following to the end of the file:

<Location "/myNewProject">
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE settings
PythonOption django.root /myNewProject
PythonDebug On
PythonPath "['C:\Program Files\Apache Group\Apache2\htdocs\myNewProject'] + sys.path"
</Location>

myNewProject is of course the name of your own Django project.

Hopefully this is of use to someone other than me, if not, then at least I have my notes organised for the next time. If I have missed anything or gotten anything wrong I would very much appreciate your feedback!

At the moment I am using WordPress as a CMS for several websites. Of course this blog is running on WordPress, not that suprising really since it is a blog. The main site of blendapps.com is all WordPress, while the acctual chat application that integrates Meebo chat with Ning social networks, run on the subdomain chat.blendapps.com and is implemented on Google App Engine. For Blendapps.com there is both a seperate blog section and a content section, so it is by no means a pure blog. Mashup.se is also running WordPress, and there I have tried to have more of a newspaper feel than a pure blog. The purest use of WordPress as a CMS is probably on restillmexico.se (swedish travel guide to Mexico), that site doesn’t even have a blog.

Why WordPress?
My requirements for a CMS are simple – it should be quick to implement a new site, it should be easy to maintain a site and it should be easy to expand and customize the site when it grows. A plus is if it runs on LAMP, so I can hack it if neccessary and so I can host it anywhere. There is not really any need to support multiple concurrent users since it is mostly going to be yours truley doing the work. Not rocket science really, but evidently damn hard to implement since most CMSes miss the mark by miles.

Let’s take a look why WordPress live up to these requirements:

• Quick to implement a new site – setting up WordPress is a matter of minutes. Get the WordPress files, set up a database and go. For some extra bonus you can add the plugins you need and choose one of 100’s of free well done themes to get the look you want. You can of course also do as I do and get a professional design and just add that on top of an exising theme.
• Easy to maintain – the WordPress control panel is easy to use, and if you dont like it you can change it around with plugins (see below for some such plugins). WordPress and most plugins are continously updated and to install updates is a breeze. All you need – such as static pages, blog posts, tagging, categories, multiple users, comments, spam protection (Akismet) etc is all part of the basic WordPress install.
• Easy to expand and customize – again, the plugins are really great for customization. Also, WordPress have really powerful and usefull template tags that allows you to customize the theme well beyond recognition. See tips and tricks below for more details.
• LAMP – check. All written in PHP and uses a MySQL database perfectly. Even if I at times have hacked the WordPress core files it is not really necessary, but the key thing is that it is possible.

Pages and Custom Fields are your friends
Content in WordPress can be either shown in “posts” or “pages”, where posts are blog posts and pages are static content. Under the surface it is all the same, both posts and pages are stored in the same tables, but they are still treated a bit differently. If you are using WordPress as a CMS then pages are definitly your friends. I have found that pages are a little easier to organise if you are not writing a blog. You can set a page as the front page of your site in the WordPress control panel. Go into settings -> reading and choose what page you want as front page.

Custom Fields are data fields that are not part of the core WordPress installation but that you define yourself. A custom field is attached to a post or a page and can be used to store any extra info that WordPress or plugins dont handle. For restillmexico.se I use it to store the URL or the images for each page, as well as the attribution of the images etc (a trick from WordPress Custom Fields: Adding Images To Posts).

Plugins to turn WordPress into a CMS
Even if a basic WordPress installation works fine as a CMS there are a few plugins that makes your life easier:

• CMS-like admin menu –  all it does is make posts second to pages in the menus, ie puts pages before posts. If all you have on your site is pages then this plugin is a nice touch.
• PageMash – drag and drop interface to order pages. Makes it very easy to change order as well as set parent/child relationship among pages. I especially use this one heavily to organise the hierarchy at restillmexico.se.
• Page Excerpt – adds the excerpt functionality of posts to pages
• Query Child Of – makes it possible to list the children of a page in your theme, great in combination with PageMash mentioned above
• Admin drop down menu – it gives the control panel a drop down menu, which is quicker and easier to use than the standard control panel menu. Not really unique for using WordPress as a CMS, but I really like this plugin.

Tips and tricks
To hack a wordpress theme to work as well as a CMS there are a few tips and tricks. The first tip is to not hack at all, just use the great CMS2 theme. It already has a page focus and most of the organisation needed for a static web site. For the sites I have on WordPress I have either customized this theme or one of the themes that comes with the basic WordPress install.

When customizing a theme there are some WordPress template tags that will save you a lot of time:

• wp_list_pages – allows you to list the pages you have in your site, pefect to create a menu with. You can include or exclude any pages you want.
• query_posts – get the posts you want by using the parameters to this tag. Since pages and posts really are the same thing this tag can be used to list pages when wp_list_pages doesn’t do exactly what you need.
• get_post_meta – get the value of a specific custom field for a page or a post, necessary to be able to get the most out of custom fields.

Summary
Wordpress is a very good option as a CMS, not just for blogs but for static sites as well. With the great choice in plugins and the open source code of WordPress you can get it to do almost anything you want without serious hacking. The huge installbase ensures that you can find help and resources if you need it.

Now when I am writing some of my own web apps I would like to avoid spam to overwhelm me, both via contact forms and comments. Lo and behold, Akismet is available as a web service, and via some ready made libraries it is very easy to use from outside WordPress as well. I am using Elliot Haughin’s CodeIgniter Library, but there are also libraries for PHP, .NET, Ruby on Rails, Drupal etc etc. All you need to do is to get a Akismet API Key from WordPress.com (register, then go to My Account and Edit Profile and you will find the key), download a library (or start writing your own from Akismets API) and start sending all comments to Akismet. The API Key is free for personal use, cost $5/month if you make more than $500/month from your site and cost a bit more for Enterprises. Well worth it I say, it will save you time and frustration all around, and make your website so much cleaner. There is no longer any excuse to suffer comment spam.

Thanks Akismet for one of the best and most usefull web services around!