To do this I needed to have the following code. The main tricks here are to create a second query as well as the main page query using the WP_Query method, and that the parameter for such a query needs an s=… to let it know the phrase being supplied is a search term.

The get_post_meta() method allows extraction from the main page extra parameter list.

<?php

$query_string = get_post_meta($post->ID, ‘organism_class’, true) ;
$search = new WP_Query( "s=$query_string&showposts=5" ) ;
$search_posts = $search->query( "s=$query_string&showposts=5" ) ;

while ($search->have_posts()) : $search->the_post();
?>

<h4><a href="<?php the_permalink() ?>"><?php the_title(); ?></a></h4>
<?php the_content(); ?>

<?php endwhile; ?>

You can include this in WordPress using the following in the header.php file in your template.

<meta name="description" content="<?php the_title() ; ?> " />

<?php
 $newsposts = get_posts('numberposts=2&category=4');
 foreach($newsposts as $newspost_single) :
 setup_postdata($newspost_single);
?>
 <div>
 <h3><?php the_title(); ?></h3>
 <?php the_content(); ?>
 <hr>

 </div>
<?php endforeach; ?>

The fix? To change the $newspost_single variable to $post. Not sure why this is the fix, and I should see if it counts as a bug, but it worked for me.

One client had the requirement of having an English language blog, but with a few words of Russian thrown in for good measure. However, as soon as she tried to save any of her posts, any characters in the Cyrillic script (i.e. the strange Russian ones) were converted into question marks. What was the cause of this? Hunting and scouring initially produced no useful results – all the documentation pointed to WordPress being able to handle such letters and searches based on WordPress and Russian as keywords just produced localisation projects converting the whole WordPress interface into Russian. Or it was stuff in Russian that I didn’t understand. Eventually I stumbled upon a discussion on the WordPress forums that explained it all – the issue was in the database.

The Solution

The issue was that Fantastico scripts used to create the database structure (as opposed to using the wordpress standard install scripts) gave databases in format latin1_swedish_ci (the later gives utf8_general_ci). As the blog hadn’t been used I just recreated it with the standard install and it was fine. A fix requiring preservation of existing data might be to back up the database (Tools->Export) in the admin interface, delete and recreate WordPress with the correct tables and then see what happens!

Just goes to show that the famous WordPress 5-minute install script is the way to go (even if the file upload take more time)!

Want to learn more about WordPress? Browse WordPress Books!