Sometimes plugins don’t get on with each other. If you try running the iPassion-Tell-a-Friend plugin alongside All-in-one-SEO Pack, then you may run into problems. I was recently asked to get these two plugins playing together nicely by a client who was getting a “Headers Already Sent” error message whenever data was submitted through the Tell-a-Friend form.

The problem is that the Tell-a-Friend plugin redirects users to a success page using header("Location: $successPage");. This instruction needs to be sent to the browser before any other code, but by the time Tell-a-Friend sent its redirect instruction All-in-one-SEO Pack had already output some meta tags, hence the error.

Getting Tell-a-Friend to go first, redirecting the user to the success page before All-in-one-SEO does its thing, fixed the conflict.

Both plugins hook into WordPress’s wp_head action using the add_action function. Out of the box, Tell-a-Friend hooks in like this: add_action ('wp_head', 'addTellaFriendSender');

This line of code tells WordPress that when it gets to the wp_head hook, it should call the addTellaFriendSender() function, which is the function that does most of the Tell-a-Friend plugin’s work.

Changing this line to the following resolved the clash between Tell-a-Friend and All-in-one-SEO: add_action ('wp_head', 'addTellaFriendSender', '1');

Every function that’s hooked into wp_head (or any other hook) has a priority between 1 and 15 (the lower the number, the higher the priority). The add_action function’s third parameter, $priority, sets this priority. The parameter is optional, and defaults to 10, so the out of the box add_action call hooks addTellaFriendSender into wp_head with a priority of 10, which is the same as All-in-one-SEO Pack’s priority.

The modified add_action call hooks addTellaFriendSender into wp_head with a priority of 1, moving it to the front of the queue and making sure that its redirection instruction comes before anything else that might cause a conflict.

I’ve just been writing a WordPress plugin that adds various fields to the Manage > Page screen in the dashboard, and then saves the contents to a custom database table when the page is saved. Strangely, I found that everything in the fields added by the plugin was being written to the database twice.

The function that saves the contents of the fields is hooked into the save_post action. The save_post action, it turns out, is called twice when a page is saved.

To prevent duplicate entries when using save_post in this way, you need to make sure that no matter how many times the function hooked into save_post is called, it only runs once. Something like this should do it:

add_action('save_post', 'save_function');

function save_function {
 
global $flag;
  if ($flag == 0) {
    // do stuff
  }
  $flag = 1;
}

Even if you aren’t writing new rows to a database, it’s good to be aware that anything hooked into save_post will be called twice, and probably a good idea to make sure that it only executes in full once.

Just an update on progress on the Alt Link Text plugin that I made available for testing a couple of days ago:

In response to popular demand (well, one user thought it would be a good idea and I agreed), I’ve added an option to change the title attributes of navigation links too.

I plan to launch this soon, so if you have any other feedback then please let me know. Thanks!

New Plugin: Alt Link Text

Many WordPress sites include navigation menus generated using the wp_list_pages() function. By default, wp_list_pages() links to pages using page titles as the link text. Sometimes, though, it’s useful to link to a page using something other than its title. For example, the title of this website’s home page is “Welcome to Technokinetics”, but I’d much rather have it linked to as “Home” in the top navigation menu.

This is a common enough scenario that I thought it would be worth writing a plugin to make it easier to deal with. The result, Alt Link Text, adds an “Alternative Link Text” field to the Write Page and Manage Page screens in the WordPress dashboard. This field can be used to specify alternative link text to be used in place of the page title in page lists generated using wp_list_pages().

The plugin will work with WordPress versions 2.5 and upwards. It will not work with earlier versions of WordPress, as the functions that it uses were only added in version 2.5.

The plugin is currently in Beta, so if you’d like to help with its development then please give it a go and let me know how you get on. Suggestions for extra features are welcome too.

As long as your WordPress theme is widget-ready, you can edit the content of your sidebar through the dashboard. In the Design > Widgets panel you can add widgets to, remove widgets from, and reorder widgets within your sidebar.

The default selection of widgets is pretty good, and there are plenty of plugins out there that will add new widgets for you to use, but what if you can’t find a widget that does what you want? Does that mean that you need to abandon your dynamic sidebar and go back to hard-coding your sidebar.php theme file?

Not at all. Instead, you can create your own sidebar widget. That way, you get the flexibility to put exactly the code that you want in your sidebar, but you can still change what sidebar items go where through the dashboard.

Let’s suppose that we want to create an author info section in our sidebar. The HTML for this might look something like this:

<li id="author-info" class="sidebaritem">
  <h2>Author Name</h2>
  <p><img src="<?php bloginfo('template_directory'); ?>/images/author.jpg" alt="Author Name" /></p>
  <p>A catchy summary of who you are and what make you so special</p>
</li>

To turn this into a widget, we just need to do three things to our functions.php theme file.

First, we need to tell WordPress that when it loads a list of sidebar widgets it should try to load our Author Info widget:

add_action('widgets_init', 'author_info_init');

When WordPress loads a list of widgets, it checks to see whether any functions have been hooked to the widgets_init action. This code hooks the author_info_init function to widgets_init, telling WordPress that when it loads a list of widgets it should call this function.

Next, we need to define the author_info_init function to register our Author Info widget so that it can appear in the list:

function author_info_init() {
  register_sidebar_widget('Author Info', 'author_info');
}

This registers the widget, naming it “Author Info” and associating it with the author_info function. The author_info function will now be called wherever our widget appears on our website.

Finally, we need to create the content of the widget by defining the author_info function so that it outputs the HTML that we want:

function author_info() { ?>
  <li id="author-info" class="sidebaritem">
    <h2>Author Name</h2>
    <p><img src="<?php bloginfo('template_directory'); ?>/images/author.jpg" alt="Author Name" /></p>
    <p>A funky description of who you are and what make you so special</p>
  </li><?php
}

Once we’ve saved and uploaded our new functions.php file, we can go to the Design > Widgets panel in our dashboard, add our Author Info widget to our sidebar, and drag-and-drop it into whatever position we want.

Of course, any code can be turned into a widget in this way, so the lack of a pre-existing widget that gives you the code that you want is never a reason to abandon your dynamic sidebar.