I know, there are a lot of widgets out there, to print related posts, but none of them I tested really suited my needs. First of all I think  a widget shouldn’t have a whole bunch of global settings, rather no global settings at all, I mean, it’s just a widget. But, even if I don’t like a huge settings page, just to run a little widget, there has to be some flexibility to let me adjust every widget-instance to my needs.

The Simply Related Posts Widget

In the case of related posts I couldn’t find a widget that really did what I wanted so I build my own. There are no global settings, but every widget instance has four options:

  1. The title of the widget (default: Related Posts). It is similar to all other widget titles and gets printed before the widget-content.
  2. The taxonomy by which terms the posts are related (default: Tags). A post is related to another post, as soon it they share one or more terms of a taxonomy. This can be the standard taxonomies Tags and Categories, or Custom taxonomies. Here youchoose which taxonomy is the relating one.
  3. How many related posts to show (default 5). Quite simple, put the maximal number of related posts you want to be visible here.
  4. Terms to exclude (default: none). Sometimes there are terms in a taxonomy, which are related to almost every post. The tag wordpress in my blog is such an example. If you have such tags you should exclude them, because they relate basically all posts, which would make the widget quite uselessscreenshot-1

Installing

  1. Download the plugin from the directory: Simply Related Posts
  2. Unpack and upload the simply-related-posts folder to the /wp-content/plugins/directory
  3. Activate the plugin through the ‘Plugins’ menu in WordPress
  4. Go to the ‘Apearance/Widgets’ area, add the ‘Simply Related Posts’ widget to a widget area.
  5. Make your settings

Feedback

Of course I want your feedback: Bugs or feature requests are welcome in the comments of this post or via twitter and I appreciate every review.

For now the code is available via svn from the plugin directory:
http://plugins.svn.wordpress.org/simply-related-posts/

Now, there is even a github repository:
http://github.com/danielauener/wp-simply-related-posts

There are quite a few solutions to relate posts in WordPress. Most of them plugins, adding a post2post table, some using taxonomies or post_metadata. Some days ago, I build a website for one of our clients, who wanted to manually relate posts to each other. The existing plugins didn’t properly match the requirements, so I had to implement related posts without plugin.

My approach was quite simple, I implemented two hooks which are mirroring all published pages in a related-posts-taxonomy, adding a new term for each post that gets published and delete a term when the related post gets removed. First the code to add a related_posts taxonomy, by adding this code to our functions.php:

add_action( 'init', 'register_taxonomy_related_posts' );
function register_taxonomy_related_posts() {
    $labels = array( 
        'name' => _x( 'Related posts', 'related_posts' ),
        'singular_name' => _x( 'Related post', 'related_posts' ),
        'search_items' => _x( 'Search Related posts', 'related_posts' ),
        'popular_items' => _x( 'Popular Related posts', 'related_posts' ),
        'all_items' => _x( 'All Related posts', 'related_posts' ),
        'parent_item' => _x( 'Parent Related post', 'related_posts' ),
        'parent_item_colon' => _x( 'Parent Related post:', 'related_posts' ),
        'edit_item' => _x( 'Edit Related post', 'related_posts' ),
        'update_item' => _x( 'Update Related post', 'related_posts' ),
        'add_new_item' => _x( 'Add New Related post', 'related_posts' ),
        'new_item_name' => _x( 'New Related post', 'related_posts' ),
        'separate_items_with_commas' => _x( 'Separate related posts with commas', 'related_posts' ),
        'add_or_remove_items' => _x( 'Add or remove related posts', 'related_posts' ),
        'choose_from_most_used' => _x( 'Choose from the most used related posts', 'related_posts' ),
        'menu_name' => _x( 'Related posts', 'related_posts' ),
    );

    $args = array( 
        'labels' => $labels,
        'public' => true,
        'show_in_nav_menus' => false,
        'show_ui' => true,
        'show_tagcloud' => false,
        'hierarchical' => true,
        'rewrite' => false,
        'query_var' => true
    );
    register_taxonomy( 'related_posts', array('post'), $args );
}

Now we have to hook into the save-post-action to add a term to our taxonomy, when a post gets published, or to update a term when a posts title gets changed. We use the posts title as name for the term, which is visible to the user in the taxonomy widget. But since the post-title might not be unique, the relation has to be established via the post-id. That’s why we save the post-id as the terms slug. Add the following code to the functions.php.

add_action( 'save_post', 'add_relatable_post' );
function add_relatable_post( $post_id ) {
	if ( get_post($post_id)->post_status == 'publish' ) {
		if (($term = get_term_by('slug', $post_id, 'related_posts'))) {
			wp_update_term($term->term_id, 'related_posts', array(
				'name' => get_the_title( $post_id ),
				'slug' => $post_id
			));
		} else {
			wp_insert_term( get_the_title( $post_id ), 'related_posts', array(
				'slug' => $post_id
			));
		}
	}
}

Finally we have to remove a term if its related post gets deleted. This can be done by hooking into the delete_post action, which is triggered when a post gets deleted (not moved to trash).

add_action('delete_post', 'remove_relatable_post', 10 );
function remove_relatable_post( $post_id ) {
	wp_delete_term( get_term_by('slug', $post_id, 'related_posts')->term_id, 'related_posts');
}

The admin interface is now prepared to relate posts to each other. On every post you see a widget, showing the related_posts taxonomy which should contain a list of all existing posts. Remember, that you have to update existing posts to get them to show up in the taxonomy box. To relate a post to another, you just check the checkbox of the post you want to relate to.

The last thing to do, is to retrieve the related posts in your theme. That is done by a simple taxonomy query in your template files.

if (have_posts()) : while (have_posts()): the_post();
	the_title();
	
	$related_posts = new WP_Query(array(
		'post_type' => 'post',
		'post_status' => 'publish',
		'tax_query' => array(array(
	        'taxonomy' => 'related_posts',
	        'terms' => get_the_ID(),
	        'field' => 'slug'		
		))
	));

	if ($related_posts->have_posts()) : while ($related_posts->have_posts()): $related_posts->the_post();
		// print your related posts
	endwhile; endif;

endwhile; endif; 

When we deployed our new site at Internetavdelningen last week, one of our goals was to get better at measuring conversions. Naturally, one of the main goals of the site is to convince potential clients to get in contact with us. Because our contact form is powered by the (absolutely awesome) Gravity Forms WordPress-plugin, we had to find a way to setup Gravity Forms Analytics Goals.

The easy way – a separate confirmation page

If that suits your page design and structure, it is easiest to just configure your Gravity form with a confirmation page. See the form settings screenshot below. You just have to create a page, which thanks for the submission or something like that and choose this page in the form settings.

Now it’s only left to add the page as goal to your Google Analytics profile. Click on the “Admin” item in the top menu on the right site and than on your profile in the Profiles tab, in your profile, choose the “Goals” tab and add a goal in one of the sets. Name and activate the goal, choose “URL Destination” and copy the permalink of your confirmation site into the “Goal URL” field. Now, after a few hours (or max one day) your conversion statistics should appear under “Conversions” in the “Standard Reporting” section.

How to do it without a confirmation page

As usual the easy way might not be working in your situation. So it was for us, we wanted to use the text confirmation method (see screenshot below) and hadn’t a clue how to implement that with analytics goals.

The solution was the somewhat unintuitive goal-type called “Event”. You select it instead of “URL Destination” in the goal settings.

Fortunately there is a great generator to do almost all the work for you. If you follow all the steps, including the described goal settings, the only task left is to add the generated tracking code to the submit button. That’s quite easily done with the Gform-submit-button-filter, provided by Gravity Forms.

Here is the code snippet that adds the tracking code with an onclick-handler to the submit button of the form with id=1. Add it to your themes functions.php.

EDIT:There seems to be an Gravity Forms upgrade that breaks the original code. That is because there is already an onclick-event on the submit-button in the new version. So we just have to append our tracking code to the onclick-event. Note that onclick is written in all non-capital letters, in the original version of my snippet it was onClick, which confused the HTML-parser. Thanks to @MrPeyler for sending me a note and helping me testing.

add_filter("gform_submit_button_1", "add_conversion_tracking_code", 10, 2);
function add_conversion_tracking_code($button, $form) {
    $dom = new DOMDocument();
    $dom->loadHTML($button);
    $input = $dom->getElementsByTagName('input')->item(0);
    if ($input->hasAttribute('onclick')) {
        $input->setAttribute("onclick","_gaq.push(['_trackEvent', 'Contact', 'Information Request', 'Contact Form',, false]);".$input->getAttribute("onclick"));
    } else {
        $input->setAttribute("onclick","_gaq.push(['_trackEvent', 'Contact', 'Information Request', 'Contact Form',, false]);");
    }
    return $dom->saveHtml();
}

And here the original WordPress filter, which doesn’t work with newer Gravity Forms versions:

add_filter("gform_submit_button_1", "add_conversion_tracking_code", 10, 2);
function add_conversion_tracking_code($button, $form) {
    $dom = new DOMDocument();
    $dom->loadHTML($button);
    $input = $dom->getElementsByTagName('input')->item(0);
    $input->setAttribute("onClick","_gaq.push(['_trackEvent', 'Contact', 'Information Request', 'Contactform',, false]);");
    return $dom->saveHtml();
}

Happy conversion tracking, with your Gravity Forms Analytics Goals!

Building web-apps for some years now, I’ve worked a lot with multiple MVC-frameworks. Most recently with CakePHP, which is great. As WordPress plugin developer I sometimes miss that strictly structured way of coding, a WordPress MVC pattern. While the code of a lot plugins I see, is organised very well generally, I really don’t like the way many developers mixing HTML-output with their plugin functions and classes. Here an examples, from the Hello Dolly plugin.

// This just echoes the chosen line, we'll position it later
function hello_dolly() {
    $chosen = hello_dolly_get_lyric();
    echo "<p id='dolly'>$chosen</p>";
}

Another one from the akismet plugin, included in a standard WordPress installation:

function akismet_stats_display() {
    global $akismet_api_host, $akismet_api_port, $wpcom_api_key;
    $blog = urlencode( get_bloginfo('url') );

    $url = 'http://';
    if ( is_ssl() )
        $url = 'https://';

    $url .= 'akismet.com/web/1.0/user-stats.php';
    $url .= "?blog={$blog}&api_key=" . akismet_get_key();
    ?>
    <div class="wrap">
    <iframe src="<?php echo $url; ?>" width="100%" height="100%" frameborder="0" id="akismet-stats-frame"></iframe>
    </div>
    <?php
}

Even if I don’t think that is a big deal, I see at least a readability issue. That’s why I prefer to store my HTML in separate files, just as you would do in every MVC-framework. It just needs a little view-class and this gets really easy. It has three logical parts: The first one is to locate the file, containing the HTML-view, the second one makes it possible to set variables in the views context and the last one renders the view.

WordPress MVC – The views location

I like to store my views in a folder called views in my plugin directory and I even add the fact that it is a view to the filename. Thus, in my plugins a settings view would be located in plugins/my-plugin/views/settings.view.php. Now, creating an instance of that view in one of my plugin-functions, I don’t want to add the complete path, the relevant part “settings” should do, and the view-class does the rest in the constructor:

public function __construct($view) {
    $path = $plugin_path."/views/".$view.".view.php";
    if (file_exists($path")) {
        $this->view = $path;
    } else {
        wp_die(__("View ".$path." not found"));
    }	
}

WordPress MVC – Setting variables to use in the view

Having the location of the file, we can now add data, that we want to render the view with. Take the Hello Dolly snippet as example, the content of our view file would look like:

<p id="dolly">
    <?php echo $chosen; ?>
</p>

Now we have to set the variable $chosen in the views context. Therefore we use an array called vars containing all data coming in via the set-function of the view-class.

public function set($name,$value) {
    $this->vars[$name] = $value;
}

WordPress MVC – Rendering the view

Finally we need a function to print out the view. It just registers the variables set in the vars-array and uses the output-buffering-functions of php to include and echo the view:

public function render() {
    extract($this->vars,EXTR_SKIP);
    ob_start();
    include $this->view;
    echo ob_get_clean();
}	

WordPress MVC – The view class

Setting all together in a view class (for copy and paste use, see github-link below), enables you to cleanly separate your views from your plugin-code. So, in a plugin, we can instantiate the view, set variables and render it, like this:

include "classes/MyView.class.php";
$view = new My_view("dolly-example");
$view->set("chosen","Lorem ipsum");
$view->render();

$menu = wp_get_nav_menu_items($menu_id,array(
   'posts_per_page' => -1,
   'meta_key' => '_menu_item_object_id',
   'meta_value' => $post->ID // the currently displayed post
));
var_dump($menu[0]->ID);

Current wp_nav_menu item: The snippets story

I needed to retrieve the current wp_nav_menu item connected to the currently requested page/post in WordPress. I found some solutions going through the hole menu-tree, comparing each items object-id with the current post-id. But, since menu items are post-types, you are able to use all the WP-Query-params with wp_get_nav_menu_items, even a meta-query. The code above selects all menu_items which are connected to the current post, from the menu you specify via $menu_id.

The only drawback is that two menu-items, linked to the same post, would both be returned without you knowing which was actually clicked. However thats the same with all the other solutions I found.