The project preparation started on the 24th December when I registered the domain name yearblog.co.uk (a little dull, but to the point). Once that and the hosting side of things were ready I installed the latest version of WordPress (2.9) and began coming up with a few ideas for simple theme.

My initial ideas surrounded the fact that it was a year long project, so started developing designs that resembled the look and feel of a calendar. I soon got bored of this when I discovered that it was difficult to find content and navigate around, so opted for a more ‘traditional’ approach instead.

I released the final theme on the site yesterday and started mentioning the idea of YearBlog on twitter and to a few friends, who decided that they may like to get in on the act and join me on this journey – good luck!

Luckily there is a really simple solution for allowing multiple blogs on the same domain (using either sub-domains or sub-directories), in the form of WordPress MU. It didn’t take long until everything was up and running and I was getting ready to start blogging.

Although the project doesn’t actually start until the end of the week, I’ve already written two posts on the subject of preparation. To read more about the project and keep up to date with the progress, head over to my YearBlog.

We all know that WordPress is a powerful and pretty impressive blogging platform, and contains many useful features. The problem is finding the features you need / want. Most of the time they are available – somewhere.

In this case, after a numbers of hours research, I’ve done all the hard work for you when it comes to adding custom rewrite rules. We shall assume we have a page called “directory‘” with the page ID “123” and the parent page of name “business“.

This page (ID: 123) looks for the parameter “business” and if is defined, displays the details for the corresponding company. We also want to add the location of the business in the url, but for simplicity we will not pass them through in this example.

The end goal is to have a list of businesses displayed on “/business/directory/” with links to the business details in the format “/business/directory/york-yo31/mybusinessltd/“.

To achieve this, we will need to make use of three hooks. The first is the “init” hook, which we will use to regenerate the rewrite rules and save them to the database using flush_rules().

function directory_flush_rewrite()
{
  global $wp_rewrite;
  $wp_rewrite->flush_rules();
}
add_action('init', 'directory_flush_rewrite');

The second hook is “query_vars“. This is required to add the string “business” to the list of query variables WordPress understands in order for it to be retrieved on our directory page.

function directory_vars($public_query_vars)
{
    $public_query_vars[] = 'business';
    return $public_query_vars;
}
add_filter('query_vars', 'directory_vars');

The last hook is called “generate_rewrite_rules” and allows us to add the custom rewrite rule/s the list of WordPress rewrite rules. Putting the three code snippets together will result in the following block of code, which should be added to your “functions.php” file.

function directory_flush_rewrite()
{
  global $wp_rewrite;
  $wp_rewrite->flush_rules();
}
add_action('init', 'directory_flush_rewrite');
function directory_vars($public_query_vars)
{
    $public_query_vars[] = 'business';
    return $public_query_vars;
}
add_filter('query_vars', 'directory_vars');
function directory_rewrite_rules($wp_rewrite)
{
	$wp_rewrite->rules = array(
		'business/directory/(?:\w+)-(?:\w+)/(.*)/?' => 'index.php?page_id=123&business='.$wp_rewrite->preg_index(1)
	) + $wp_rewrite->rules;
}
add_action('generate_rewrite_rules', 'directory_rewrite_rules');

The final piece of information you need is how to access the variable passed through form the rewrite rule (“business=mybusinessltd”). This can be done using using the following:

$wp_query->get('business'); // returns 'mybusinessltd' in this example.

The example Reg Exp used could be modified and improved nad the page name could be matched and used instead of using the page id, but should put you on the right track. As mentioned earlier, you could also pass through the the other parameters (town & postcode) and use them alongside business in your lookup query.

The problem with using this plug-in is that the WordPress WYSIWYG Editor (TinyMCE), will remove any tags and attributes that it believes to be invalid according to it’s configuration. As two of the attributes used by this plug-in are custom attributes (escaped/line) they are removed, causing some unexpected output.

One solution to this problem is to add the custom attributes to the list of valid elements by using the ‘tiny_mce_before_init‘ filter and appending them to the ‘extended_valid_elements’ string.

The function below can be added to the functions.php file within your theme directory:

function tinymce_wp_syntax($init) {
	$values = 'pre[lang|escaped=true|line]';
	if (empty($init['extended_valid_elements'])) {
		$init['extended_valid_elements'] = $values;
	} else {
		$init['extended_valid_elements'] .= ','.$values;
	}
	return $init;
}
add_filter('tiny_mce_before_init', 'tinymce_wp_syntax');

Adding this to my blog enables me to continue using the visual editor instead of disabling it and at the same time will allow the other HTML filters to continue as normal .

Note: You may have to force refresh (ctrl + f5) the post / page editing page for the changes to take effect.

EDIT: This solution does not fully solve the problem in WordPress MU installations, as you need to adjust the allowed post tags used by the content filter.

if (!CUSTOM_TAGS) {
	$allowedposttags['pre'] =  array(
		'lang' => array(),
		'escaped' => array('true' => array()),
		'line' => array()
	);
}

Although it wasn’t immediately obvious to me, read more links can be enabled by over-riding the global $more variable and setting it to false, before looping through the result set, for example:

global $more; $more = FALSE;
query_posts('post_type=page');
if ( have_posts() ) : while ( have_posts() ) : the_post();
	the_content('Read More...');
endwhile; endif;

I couldn’t actually discover why this is not the default behaviour when querying pages. There may be a good reason behind it, but in my experience I found it mildly irritating.

Instead I decided to write a very simple function to add a class name to the first paragraph by filtering the content, then setting the styles accordingly in my theme CSS file.

function first_paragraph($content){
	return preg_replace('/<p([^>]+)?>/', '<p$1 class="first">', $content, 1);
}
add_filter('the_content', 'first_paragraph');

By default this will append class=”first” to the first p tag in your post.

If you want to use this function on your own blog, just add it to your (or create a)  functions.php file within your themes folder.

One of the main reasons for for the lack of updates is due to the stack of work I’ve been attempting to get through and my attempts at redesigning the layout of my blog.

I had a couple of different concepts for the redesign, but this is the design I eventually went with.

Other ideas included a post-it note type design, where the notes were randomly placed on the screen with the ability to drag and re-organise.

Although I liked the idea of randomisation, after putting the design into practice it failed to fulfil it’s purpose of a blog theme. Content was difficult to get to and awkward to locate, so for this reason decided to take a different approach.

The second design couldn’t be more different from the first. I decided against proceeding with this design for a number of reasons. Firstly, the length of each page would have been too long and secondly I didn’t really like it.

My third and final attempt was loosely based on the previous, using a single fixed width column with the sidebar below the main content. The colours were reduced to a single primary colour – orange – with white text on a dark background.

I felt this was going in the right direction and so continued through with the development process to create the current theme, which – to be honest – is nothing special but it’s quite clean, simple and is a bit different.

Aside from what has been described as a “very important security fix” there were over 70 additional bug fixes, most of which I hadn’t come across myself although had heard of some troubles encountered by others.

Unlike my previous upgrade this time I just switched the subversion repository and ran the web based update script, shaving off an additional few minutes and therefore upgrading my install in under two minutes from start to finish!

svn switch http://svn.automattic.com/wordpress/tags/2.5.1/

Luckily everything seems to be working fine and I have faith in the WordPress releases, but if you want to be more cautious you should probably backup your database first.

As Paul’s response to my previous upgrade post mentions, any web scripts can be rolled back using svn.

It is highly recommended that you carry out the upgrade as it is said that the vulnerability to 2.5 will be made public shortly.

There is also to introduction of additional security in the form of secret keys, introducing randomness into the cryptographic functions used for cookies.

Simply obtain a secret key and paste the code into your wp-config.php file along with the other defined variables.

Paul went through the upgrade steps on his blog, but thought I would go through them here as I went along.

Unfortunately when I initially installed WordPress I committed it directly to the root directory unlike the more popular location of the subdirectory /blog, but not to worry.

Here are the steps I followed to complete the update:

# Backup the current directory...
cp -Rp http httpBACKUP
# Create a new location for the update...
mkdir httpNEW
# Checkout the latest release from the repository...
svn co http://svn.automattic.com/wordpress/tags/2.5/ httpNEW/
# Copy across any custom changes/themes and config file...
cp -Rp http/wp-con* httpNEW/
# Copy over the .htaccess file..
cp -Rp http/.htaccess httpNEW/
# Delete the old directory...
rm -rf http
# Rename/move the update to the original location...
mv httpNEW/ http
# Switch the SubVersion Repository...
svn switch http://svn.automattic.com/wordpress/tags/2.5/
# Finally, run the browser based update script...
http://yourdomain/wp-admin/upgrade.php

And that’s all there is to it really, now every time I need to update WordPress I can simply copy and paste the above commands.

define: blogger – “The author of a blog”.

Over at Fubra they like to encourage – or nag – all employees to write their own blog and be part of the ever increasing population of online bloggers.

Until now I have been putting off the process of setting up my own blog in the hope that one would just magically appear or allow me to create one with minimum effort.

Thanks to the wonders of Subversion and WordPress I was able to quickly and easily install a blog on my vserver that Fubra have kindly supplied.

It can’t really get much easier than running the following cmd to checkout from the WordPress repository:

svn co http://svn.automattic.com/wordpress/branches/2.3/ .

All that was left was to come up with a quick and simple design to get away from the default template theme.

So there you have it, the kick start to my future in blogging.

Oh, and a quick thank you to my boss Paul for backing me into a corner and pressuring me into this whole blogging malarkey.