jsdalton

I looked into this issue a few months ago, and at the time I recall believing it was not possible. Something might have changed in a recent WP version, because it’s now quite possible.

The order that plugins are loaded (as of WP 2.9.1 at least) is determined by the order of an array stored as “active_plugins” in the WP options table. Whenever a plugin is activated, it is added to this array, the array is sorted alphabetically by plugin name, and the array is saved to the DB.

Fortunately, there is a convenient action hook, “activated_plugins”, that is called after the active plugins array is saved to the DB. This allows you to manipulate the order of the plugins stored in this array after the array is initially saved.

Here for example, is a function I wrote that ensures a given plugin is loaded first:

function this_plugin_first() {
	// ensure path to this file is via main wp plugin path
	$wp_path_to_this_file = preg_replace('/(.*)plugins\/(.*)$/', WP_PLUGIN_DIR."/$2", __FILE__);
	$this_plugin = plugin_basename(trim($wp_path_to_this_file));
	$active_plugins = get_option('active_plugins');
	$this_plugin_key = array_search($this_plugin, $active_plugins);
	if ($this_plugin_key) { // if it's 0 it's the first plugin already, no need to continue
		array_splice($active_plugins, $this_plugin_key, 1);
		array_unshift($active_plugins, $this_plugin);
		update_option('active_plugins', $active_plugins);
	}
}
add_action("activated_plugin", "this_plugin_first");

Place this in the main file for your plugin, and it will load first. Note that you have to activate a plugin (any plugin) for this function to execute.

You can manipulate the active plugin array anyway you like (e.g. if you wished to load a different plugin first as the original poster does) provided you save your changes at the end via update_plugin().

This is probably 10 months too late for you, but I just had the same conundrum. Here’s the solution I came up with.

The easiest way to show a 404 page from an arbitrary point in your script would be to define the following function:

function return_404() {
	status_header(404);
	nocache_headers();
	include( get_404_template() );
	exit;
}

and then just call return_404() from wherever you need to. This should work as long as it is called before the headers are sent (I am personally using it on a template_redirect hook).

I basically copied the above from the same code WordPress uses to display a 404 page when a post is not found. This is as of 2.8, FYI.

This is not a good solution, but it’s a quick and dirty way to do the job, along the lines of some of the code examples from the WP documentation on The Loop.

So first, in the functions.php file in your theme, add this function:

function is_type_page() { // Check if the current post is a page
	global $post;

	if ($post->post_type == 'page') {
		return true;
	} else {
		return false;
	}
}

Next, in your search.php file in your theme (where your search results are displayed, you want to add the following line right after the loop. It should look like this:

<?php while (have_posts()) : the_post(); ?>
<?php if (is_type_page()) continue; ?>

That *will* exclude pages from your search results. (At least it does work for me, on WP 2.5.1.)

The reason I dislike it is that it simply removes the pages from your result set. So let’s say you have WP set to show 20 posts per page, but on a given search result set 7 of the results are pages. The result set displayed to the user will be 13 instead of 20! That’s ugly.

One thing you might consider to also prevent against this would be to give your pages a very early publish date, assuming you don’t use the publish date anywhere. This would ensure that at a minimum they always show up at the end of your result set, which would ameliorate the problems caused by the above.

If I hack together anything better than the above I will post it here.