Although it’s advised you avoid creating tables unless absolutely necessary, it seemed like the correct method to store the data used by this particular plugin.

This method of storage does have it’s downsides, especially when it comes to modifying the table structure. Luckily the dbDelta function comes in really handy in aiding the update process.

There is however one issue that I came across, discovering that is unable to modify a unique key (in this situation a composite index).

After browsing through the source code for the dbDelta function I spotted that something was missing. When including an index in the query, it is not dropped before attempting to recreate it and is therefore ignored when performing an update.

Take for example the following code snippet:

global $wpdb;
$table = $wpdb-prefix.'mytable';
$sql = "CREATE TABLE $table (
	id mediumint(9) NOT NULL AUTO_INCREMENT,
	calendar varchar(255) NOT NULL default 'default',
	year smallint(5) NOT NULL,
	month tinyint(3) NOT NULL,
	day tinyint(3) NOT NULL,
	PRIMARY KEY (id),
	UNIQUE KEY date (year,month,day)
);";
require_once(ABSPATH.'wp-admin/includes/upgrade.php');
dbDelta($sql);

If we make some changes to the SQL statement to add an additional column to the unique index, the index would become something like “UNIQUE KEY date (year,month,day,calendar)“.

This will work if the the table does not already exist, but if it attempts to update the table then the changes to the unique key are ignored.

The short and simple solution is to simply check the table exists and then drop the index manually before calling the dbDelta function.

if ($wpdb->get_var("SHOW TABLES LIKE $table") == $table) {
	$wpdb->query("ALTER TABLE $table DROP INDEX date");
}

I’m not sure if this is actually a bug with the function or whether it wasn’t supposed to allow for updates on indexes in the first place, either way the problem can be quite easily resolved.

The plugin stores a custom post meta entry for any post or page that requires a subtitle, in order to append this field to the search query I required the use of two actions.

• posts_where_request
• posts_join_request

Each of my plugins use a class based format, so the following examples will be provided in that format. This could quite easily be changed to regular functions

The first action is called when the class is instantiated:

class MyPlugin {
	function MyPlugin()
	{
		add_action('posts_where_request', array(&$this, 'search'));
	}
}

The first argument passed to this action is a string containing the where clause for the search query.

When the action is called we have also reached a point where we can check whether we are carrying out a blog search “is_search()“.

function search($where)
{
	if (is_search()) {
		global $wpdb, $wp;
		$where = preg_replace(
			"/\(wp_posts.post_title (LIKE '%{$wp->query_vars['s']}%')\)/i",
			"$0 OR ($wpdb->postmeta.meta_key = '_mymetakey' AND $wpdb->postmeta.meta_value $1)",
			$where
		);
		add_filter('posts_join_request', array(&$this, 'search_join'));
	}
	return $where;
}

All that we do here is include the meta key search by finding the post_title clause and inserting the meta key clause after it, using the preg_replace() function.

(Note: I have used the meta key “_mymetakey”, you will need to replace this with the key matching your custom meta data.)

The where condition is now in place, but we will need to add on the post_meta table, making use of the second action “posts_join_request” included in the function above.

function search_join($join)
{
	global $wpdb;
	return $join .= " LEFT JOIN $wpdb->postmeta ON ($wpdb->posts.ID = $wpdb->postmeta.post_id) ";
}

Putting all the basic functionality together you will have something along the lines of this:

class MyPlugin {
	function MyPlugin()
	{
		add_action('posts_where_request', array(&$this, 'search'));
	}
	function search($where)
	{
		if (is_search()) {
			global $wpdb, $wp;
			$where = preg_replace(
				"/\(wp_posts.post_title (LIKE '%{$wp->query_vars['s']}%')\)/i",
				"$0 OR ($wpdb->postmeta.meta_key = '_{$this->tag}' AND $wpdb->postmeta.meta_value $1)",
				$where
			);
			add_filter('posts_join_request', array(&$this, 'search_join'));
		}
		return $where;
	}
	function search_join($join)
	{
		global $wpdb;
		return $join .= " LEFT JOIN $wpdb->postmeta ON ($wpdb->posts.ID = $wpdb->postmeta.post_id) ";
	}
}

There are however a few possible pitfalls that I have yet to address, the main one being that the meta_value field is not indexed.

I’m not sure whether to try and automatically add an index to the field or add an additional option on my plugin settings page to create the index.

Instead of having to re-create the whole query, you can append a comma separated list of category ID’s  that you want to exclude to the end of the original query and fetch the new data set to be used.

To achieve this, insert a variation of the following into your index or template file specified as the posts page:

<?php if (is_home()) query_posts($query_string.'&cat=-2,-3'); ?>

This should be placed before the loop, therefore ideally just before:

<?php if (have_posts()) : ?>

Adding this line of code will check if the current page is the posts page (is_home) and if so exclude the categories with ID’s 2 and 3. Note here the negation used (-2 and -3), without this the query will include rather than exclude the categories.

If you don’t want to hard code ID values, you could use the get_category_by_slug or get_category_by_path functions to fetch the category ID.

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.

Yesterday saw over 100 downloads as a result of numerous modifications and updates, some of which due to mistakes on my behalf which was mildly irritating. The main reason behind all the updates was to cater for numerous feature requests and bugs reported by users of the plugin.

This plugin – as with Page Meta – was written for a project I have been working on, however there are very few that solve the issue of adding in sub headings / titles and reposition it below the main title (or at least as far as I am aware).

If you have any feedback on this plugin I recommend you post it on the WordPress Plugins forums, otherwise if you’re looking to install this plugin it can be downloaded here.

The plugin quite quickly evolved into a solution that allowed for keywords as well as descriptions to be added, as well as the ability to set a custom page title. If required the page title can even be defined in your page template, allowing for dynamic pages / templates to have specific titles.

Although unsure if anyone would actually be interested in using it, I decided to publish it to the Plugin Directory anyway. If anything it would allow me to manage the versions and easily update the handful of blogs that I have installed it on.

I actually thought that my second plugin, SubHeading would be more popular as there aren’t many existing solutions in the Directory for this. It’s not far behind in downloads, with just over 850 to date.

If you’re looking to create your own plugin and want to get it noticed, it’s recommended that you publish and host it in the directory. Here’s a quick guide to take you through the steps of publishing a plugin on a Windows based system.

1. Download and install Tortoise SVN
2. Request an SVN repository using the Add Your Plugin page (It may take few hours to get your request approved).
3. Once you receive the SVN credentials you will be able to access the repository from http://svn.wp-plugins.org/plugin_name.
4. Checkout the blank repository from your svn account. (This contains three empty folders – branches, tag, trunk). To do this, right click the folder you want to Checkout to and select SVN Checkout.

   

   Enter the URL of your plugin repository and click OK.

   

   Once the process is complete you will see the three folders that have been added.

   

5. Copy the plugin files into the trunk folder and create a readme.txt file if one is not already present.



6. Commit your changes by right clicking the folder and selecting SVN commit.



7. You will be prompted for your authentication details, enter your WordPress.org/bbPress.org username and password (the same one you use on the forums).



8. Now create a tag. Right click on the trunk folder and in the context menu go to TortoiseSVN and choose Branch/Tag. In the dialogue box change the url path from /trunk to /tags/0.1 (or whatever you have stated as the stable tag  in the readme file.



9. Run SVN update on the tags folder (Right click the tags folder and select SVN Update).

Committing a modified plugin / new version

1. Make modifications to the trunk folder.
2. Change the stable tag value in the readme file to the latest stable version, e.g. 0.1.1
3. SVN commit the latest changes in the trunk.
4. Tag the new version (see step 8 above) .
5. SVN update the tags folder.

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.