In the days leading up to the Christmas break I was involved in creating a WPMU-powered WordPress blog for one of our clients. This was the first time we (iStudio) or I had used this product, so as you might expect there were a few growing pains that were encountered along the way. Since I spent so much time trying to fix them, I thought it would be a good idea to document a couple of the more annoying ones.

WPML and Kubrick – a story of hate

My common practice when creating a WordPress theme is to take the default one – Kubrick – and customize it to suit the requirements of the project it is for. All went well until I installed the multilingual plugin of choice, WPML. Not only did the language switching fail, but the page would go all 404 on me unless I inserted a trailing slash (‘/’) at the end of the URL. Hardly ideal.

The solution – and please don’t ask how I came to this because its not good memory – was to delete everything (except the junk about widgets at the top) in the function.php file. Once I did that, everything magically worked. I say magically becuase I really have no clue what was causing the error to occur within the functions.php file. As long as it works, that’s good enough for me.

Customize plugin, save, and….uh, it’s gone!

This issue occurred with two or three plugins that I had to use for this project. The problem happened when making any customization to the plugin via the dashboard. For example, WP-Polls has a number of options that can be configured from the WordPress dashboard. However, when I went to save my changes, the form would kick me back to the main ‘parent’ blog of WPMU, and not the ‘child’ blog that I had been configuring the plugin on. This was actually an easy one to fix, but because of my bleary-eyed and brain-dead state it frustrated me over the course of a weekend (and no, I didn’t spend an entire weekend trying to fix it – just a few minutes at a time before I would quit and mutter a few ‘cheerful’ words).

I solved this problem by just changing the target URL of the form’s action attribute. In the cases where the plugin was failing, it was always due to the URL pointing to the main wp-admin folder, and not the actual wp-admin folder for the blog being customized. I updated the target and we had ourselves a winner.