Ridding WordPress Plugins of Template Tags [en]

[fr] Cet article décrit une méthode permettant de se défaire des "template tags" qu'utilisent certains plugins. Plutôt que de copier le fameux template tag à 3 endroits différents dans son thème (comme c'était le cas auparavant pour Basic Bilingual), il est possible de modifier à peu de frais un plugin pour qu'il injecte automatiquement son contenu dans le blog.

If you’re like me and use a bunch of plugins to liven up your WordPress blog, you’ve probably noticed that adding template tags in your favourite (or favourite-of-the-week) theme files can quickly become a royal pain in the neck.

One of the things I wanted to do with [Basic Bilingual, and which I did with the last release](http://climbtothestars.org/archives/2007/11/30/basic-bilingual-03-for-multilingual-blogging/), was make the plugin inject the text for the “other excerpt” (the French text you can see at the top of this post) automatically into the templates and feeds.

Once I’d figured out how to do that, I realised I could modify other plugins, too. And I’m going to tell you how you can do it, too. This method should work for any plugin which generates a template tag, as long as you want the content generated by the plugin to go immediately after or before the post content. (I’m still working on advanced rules for cases where you want to make modifications elsewhere in the template.)

[Christine](http://www.neato.co.nz/)’s [Inline Tag Thing](http://www.neato.co.nz/wordpress-things/inline-tag-thing) put me on the track (thanks!), as it does just that. Here’s the trick:

1. create a function which concatenates (= “adds”) the plugin output to the content
2. add an action hook to the plugin to apply that function to “the_content”.

Fear not, I’ll explain all. You don’t need to really know much PHP to do this, as long as you’re comfortable wading through a bit of code and copy-pasting stuff and making a few small modifications.

Let’s take an example: [the Similar Posts plugin](http://rmarsh.com/plugins/similar-posts/), which I’m now using to point out posts related to the current one (normally, in a box at the top of the post if you’re on the website, and as a list at the end of the post if you’re reading [the feed](http://feeds.feedburner.com/ctts)).

Similar Posts provides a template tag, <?php similar_posts(); ?>, which you can paste in your template where you like the related posts to appear. Personally, I want them to appear on the main blog page, on the individual archive pages, and on the monthly, category, and taggy archive pages. This means I need to paste the tag into at least 3-4 different template files. And if I decide that I want the tag at the top of the post rather than the bottom, or I decide to remove it, there I go again. Not optimal.

So, here’s how I made it “better” (for me):

A. First, I looked at the plugin code to figure out where the template tag function was; in this case, quite easy, it’s the function called similar_posts(), logically. Here are the last two lines of this function, which do the actual data output:

print $result;
if (defined(‘POC_CACHE’)) print $cache_time;

I changed them to:

return $result;
if (defined(‘POC_CACHE’)) return $cache_time;

So that they didn’t print directly (ie, output text), but just return the value of the data we want to insert.

Then, I created the following function:

function sp_embed_similar_posts($content) {
$content = similar_posts() . $content;
return $content;

This function takes one parameter ($content), and sticks the output of similar_posts() in front of it. Now you see why we needed to change the other function so that it didn’t print. We’re just modifying the value of the $content string. This new function returns the modified value for the content (in our case, imagine it as being the content of your post with the code for the similar posts listing stuck in front.

Now all that is left to do is to tell WordPress to actually *use* that function at some point (plugins are usually a collection of functions, followed by a series of “hooks” which actually execute the functions at certain chosen moments). Here’s the action we’ll use:

add_action(‘the_content’, ‘sp_embed_similar_posts’);

Try it!

This will also add the list of similar posts to the feed.

So, in summary, here is what we have done:

– modified the template tag function so that it *returns* a value instead of *printing* it (in some plugins, you’ll find a function that already does that!)
– created a function to stick that value on the beginning or end of a parameter, $content
– add an action hook on the_content to execute the function.

Happy hacking!

Similar Posts:

Scripts for a WordPress Weblog Farm [en]

A first step to WordPress-farming: a shell script and a PHP script which allow you to easily install a whole lot of WordPress weblogs in only a few minutes (I installed over 30 in less than 5 minutes). Scripts require adapting to your environment, of course.

Update 03.11.06: Batiste made me realise I should point the many people landing here in the search of multi-user WordPress to WordPress MU. All that I describe in this post is very pretty, but nowadays completely obsolete.

Here is the best solution I’ve managed to come up with in half a day to finally install over 30 WordPress weblogs in under 5 minutes (once the preparation work was done).

A shell script copies the image of a WordPress install to multiple directories and installs them. A PHP script then changes a certain number of options and settings in each weblog. It can be used later to run as a “patch” on all installed weblog if a setting needs modifying globally.

Here are the details of what I did.

I first downloaded and unzipped WordPress into a directory.

wget http://wordpress.org/latest.tar.gz
tar -xzvf latest.tar.gz
mv wordpress wp-farm-image

I cleaned up the install (removing wp-comments-popup.php and the import*.php files, for example), added a language directory (as I’m wp-farming in French) and modified index.php to my liking; in particular, I edited the import statement for the stylesheet so that it looked like this:

@import url( http://edublogs.net/styles/toni/style.css );

The styles directory is a directory in which I place a bunch of WordPress styles. I don’t need the style switcher capability, but I do need to styles. Later, users will be able to change styles simply by editing that line in their index.php (or I can do it for them).

Another very important thing I did was rename wp-config-sample.php to config-sample and fill in the database and language information. I replaced wp_ by xxx_ so that I had $table_prefix = 'xxx_';.

To make it easier to install plugins for everyone, correct the language files, and edit whatever may be in wp-images, I moved these three directories out of the image install and replaced them with symbolic links, taking inspiration from Shelley’s method for installing multiple WordPress weblogs.

mv image/wp-content common
mv image/wp-images common
mv image/wp-includes/languages common
ln -s common/wp-content image/wp-content
ln -s common/wp-images image/wp-images
ln -s common/languages image/wp-includes/languages

I also added an .htaccess file (after some painful tweaking on a test install).

Once my image was ready, I compiled a list of all the users I had to open weblogs for (one username per line) in a file named names.txt, which I placed in the root directory all the weblog subfolders were going to go in.

I then ran this shell script (many thanks to all those of you who helped me with it — you saved my life):

for x in `cat names.txt`
cp -rv /home/edublogs/wp-farm/image/ $x
cat $x/wp-config.php | sed "s/xxx/${x}/" > config.tmp
mv config.tmp $x/wp-config.php
wget http://st-prex.edublogs.net/$x/wp-admin/install.php?step=1
wget http://st-prex.edublogs.net/$x/wp-admin/install.php?step=2
wget http://st-prex.edublogs.net/$x/wp-admin/install.php?step=3

This assumes that my WordPress install image was located in /home/edublogs/wp-farm/image/ and that the weblog addresses were of the form http://st-prex.edublogs.net/username/.

This script copies the image to a directory named after the user, edits wp-config to set the table prefix to the username, and then successively wgets the install URLs to save me from loading them all in my browser.

After this step, I had a bunch of installed but badly configured weblogs (amongst other things, as I short-circuited the form before the third install step, they all think their siteurl is example.com).

Entered the PHP patch which tweaks settings directly in the database. I spent some time with a test install and PHPMyAdmin to figure out which fields I wanted to change and which values I wanted to give them, but overall it wasn’t too complicated to do. You’ll certainly need to heavily edit this file before using it if you try and duplicate what I did, but the basic structure and queries should remain the same.

I edited the user list at the top of the file, loaded it in my browser, and within less than a few seconds all my weblogs were correctly configured. I’ll use modified versions of this script later on when I need to change settings for all the weblogs in one go (for example, if I want to quickly install a plugin for everyone).

In summary:

  1. compile list of users
  2. prepare image install
  3. run shell script
  4. run PHP script

If you try to do this, I suggest you start by putting only two users in your user list, and checking thoroughly that everything installs and works correctly before doing it for 30 users. I had to tweak the PHP script quite a bit until I had all my settings correctly configured.

Hope this can be useful to some!

Update 29.09.2005: WARNING! Hacking WordPress installs to build a farm like this one is neat, but it gets much less neat when your weblog farm is spammed with animal porn comments. You then realise (oh, horror!) that none of the anti-spam plugins work on your beautiful construction, so you weed them out by hand as you can, armed with many a MySQL query. And then the journalist steps in — because, frankly, “sex with dogs” on a school website is just too good to be true. And then you can spend half a day writing an angry reaction to the shitty badly-researched article.

My apologies for the bad language. Think of how you’re going to deal with spam beforehand when you’re setting up a school blog project.

Similar Posts: