WordPress avoids this problem with a handy class called Snoopy, which uses sockets to make a request to remote servers and avoid the problem. Here’s a quick rundown on using Snoopy for some simple tasks.

/* First, we need to make an instance of the class */
$snoopy = new Snoopy();
/* Now we can fetch a url from the web */
$result = $snoopy->fetch(‘http://weeklytips.wordpress.com’);
/* Check to make sure that it was fetched successfully*/
if($result) {
/* Now the variable $snoopy->results contains the information you just fetched, for now we will just echo it out */
echo $snoopy->results;
} else {
echo ‘We were not able to complete your request’;
}

The power of Snoopy goes way beyond simple fetching of URLs, but for now this is all I will cover here. There are tons of good resources and tutorials for Snoopy on the web, so if you need to learn more, you can check those out for now. At some later date, I may also publish the portion of the book on some of Snoopy’s more advanced features, and how they relate with the rest of WordPress.

To avoid function collision and pollution, many people have wanted to resort to building plugins with classes and methods instead of prefixed functions for their plugins. WordPress has the capability out of the box to support these sorts of plugins, but unfortunately the documentation around them is lacking.

Adapting Procedural Plugins

To show the differences between procedural and object oriented plugins, we’re going to first adapt the simple plugin from our first example to show the basic differences. If you don’t already know how to write in PHP style object oriented syntax, it may be in your best interest to read a bit of the php.net documentation (4, 5) on the subject first. Our original procedural plugin for profanity filtering looked like this:

function prefix_filter_profanity($content = ”) {
$profane_things = array(‘water’, ‘cold’, ‘fast’, ‘cheese’);
$clean_things = array(‘wine’, ‘hot’, ‘slow’, ‘pasta’);
$filtered_text = str_replace($profane_things, $clean_things, $unfiltered_text);
return $filtered_text;
}
add_filter(‘the_content’, ‘prefix_filter_profanity’);
add_filter(‘comment_text’, ‘prefix_filter_profanity’);

Adapting the plugin is incredibly simple.

class Profanity_Filter() {
/* This is for PHP5, which uses a new magical function as the constructor */
function __construct() {
$this->Profanity_Filter();
}
function Profanity_Filter() {
add_filter(‘the_content’, array(&$this, ‘filter’));
add_filter(‘comment_text’, array(&$this, ‘filter’));
}
function filter() {
$profane_things = array(‘water’, ‘cold’, ‘fast’, ‘cheese’);
$clean_things = array(‘wine’, ‘hot’, ‘slow’, ‘pasta’);
$filtered_text = str_replace($profane_things, $clean_things, $unfiltered_text);
return $filtered_text;
}
}
$profanity_filter = new Profanity_Filter;

The first look at this class may be a little overwhelming. The code has gotten considerably longer, but this is an exception rather than the rule, as longer plugins will often have their size cut down.

Let’s step through bit by bit.

function __construct() {
$this->Profanity_Filter();
}
function Profanity_Filter() {
add_filter(‘the_content’, array(&$this, ‘filter’));
add_filter(‘comment_text’, array(&$this, ‘filter’));
}

The first function, __construct, is for PHP5 and future versions. It basically ensures that the old style constructor, the method that matches the class’s name, is run when the class is created. The function Profanity_Filter is the old style constructor for PHP4. This function registers the actions for filtering on the content and comment text. This is similar to the old code, except the second argument, the callback function. Instead of passing in a function name as a string, you pass in an array, which corresponds to the PHP callback type. The callback type tells PHP how to find the function or method that its looking for. The first item in the array is a reference to $this, which is a reserved variable pointing to the current instance of the class. The second argument is the string name of the method inside the function that should be run as the filter, just like before.

This code can also be written in a second way, if your goal is solely to avoid name collisions.

class Profanity_Filter() {
function Profanity_Filter() {
add_filter(‘the_content’, array(&$this, ‘filter’));
add_filter(‘comment_text’, array(&$this, ‘filter’));
}
function filter() {
$profane_things = array(‘water’, ‘cold’, ‘fast’, ‘cheese’);
$clean_things = array(‘wine’, ‘hot’, ‘slow’, ‘pasta’);
$filtered_text = str_replace($profane_things, $clean_things, $unfiltered_text);
return $filtered_text;
}
}
/* ClassName::Method and array(‘ClassName’, ‘Method’) are both valid static callback types */
add_filter(‘the_content’, ‘Profanity_Filter::filter’);
add_filter(‘comment_text’, array(‘Profanity_Filter’, ‘filter’));

This method uses static calling of methods instead of requiring that you create an instance of a class. The best idea is to choose which method you use based on what your plugin needs to do. If you have code that would normally be written as object oriented code with multiple objects, the former method is the way for you, while the latter example is just for avoiding function name collisions.

$menu[10] = array(__(‘Manage’), ‘edit_posts’, ‘edit.php’);
…
$submenu['edit.php'][20] = array(__(‘Comments’), ‘edit_posts’, ‘edit-comments.php’);

Each item in the $menu array represents a top-level menu item, while each item in the $submenu array represents one of the submenu pages. So how can we remove the menus? unset() of course.

function prefix_remove_menu() {
global $submenu;
unset($submenu['edit.php'][20]);
}
add_action(‘admin_header’, ‘prefix_remove_menu’);

If you really wanted, you could change that to something like this, and remove top menu items instead.

function prefix_remove_menu() {
global $menu;
unset($menu[10]);
}
add_action(‘admin_header’, ‘prefix_remove_menu’);

A problem that many plugin developers face is having plugins that provide template tags that will gracefully fail when their plugin is removed. A majority of current plugins simply have a function that you call, similar to all of the other template tags, to place the output in your themes. The problem is that if a user uninstalls the plugin, they are now faced with a fatal PHP error in their theme because your function can no longer be found.

The solution to this problem is simple, but rarely used, probably because not many people outside of the mailing lists have seen the trick before. The solution? Hooks. Instead of telling a user to place a function call in their templates, you could tell them instead to copy and paste a little code snippet like this:

do_action(‘my_plugin_action’);

Alone, this call to do_action does nothing, and is similar to what you would find scattered about the WordPress code and themes that provide the standard set of hooks. But try adding a line in your plugin like this:

add_action(‘my_plugin_action’, ‘my_template_tag’);

Together, you’ve created a template tag to be copied and pasted into themes, that no longer kills sites when your plugin is deactivated. With this new template tag, you open up the doors for easy, clean integration with themes. Instead of trying to explain how to wrap your template tags in if(function_exists()) to the template designer who doesn’t understand PHP, they can once again copy and paste tiny snippets of code, providing a better user experience for everyone.

And as always, remember to prefix your functions and hook names with something unique, so that you don’t collide with other plugins.