Call to WordPress Plugin Developers [en]

Call for help to WordPress plugin developers. I have a bunch of hacks and modifications I’d like to turn into plugins, but I am unfortunately as plugin-challenged as ever.

[fr] Un descriptif des plugins que j'écrirais pour WordPress si je ne faisais pas un vilain blocage sur le sujet. Ne vous gênez pas si vous voulez contribuer!

If I was fluent in WordPress plugin coding, here are the plugins I’d write. If you feel like coding one of them yourself, or helping me get it done, you’re most welcome. Carthik has already pointed me to Plunge into Plugins, which I will have a close look at once I’ve finished writing this post.

Of course, if you know of a plugin which does precisely what I’m describing here, leave a link to it in the comments!

Keywords plugin

This would be a pretty straightforward one:

  • add a “keywords” text input to post.php
  • save the value of that text input to a custom field called “keywords”
  • add those keywords as an HTML meta tag on the individual post pages.
Excerpt plugin

This one would also be pretty straightforward, as all it would do is add the “excerpt” field to the “simple” post.php layout.

Customize post.php plugin

This would be more complex, but allow for more flexibility than the previous plugin. I don’t yet have a clear idea of how to make it work, but the basic principle would be to allow the user to select which fields should appear on the post.php page. Instead of having “simple” and “advanced” controls, this would add the option to have “custom” controls and define them.

TopicExchange plugin

As far as functionality is concerned, this plugin would do what my TopicExchange hack did:

  • add a “trackback TopicExchange channels” text input to post.php
  • store the space-separated list of keywords in a meta value named (e.g.) ite_topic (one record for each value)
  • for each value, trackback the appropriate TopicExchange channel
  • display the trackbacked channels (with link) on each post.
Bilingual plugin

This would be a clean version of my language hacks:

  • add a small “language” text input to post.php (with a default value)
  • add an “other language excerpt” textarea, which posts to the corresponding custom value
  • display the “other language excerpt” at the top of each post
  • provide a function to return the post language, and the other-excerpt language (so it can be declared in a lang attribute, allowing the use of language-dependant CSS formatting, in addition to being semantically correct)
  • if this is not already possible with the date function in the WordPress core, provide an alternative date function which will format the date correctly corresponding on the language of the post
  • optional: figure out a way to adapt text like “comments”, “categories” etc. to the post language; make the plugin usable with more than two languages.
Smart Linkroll plugin

I love the way ViaBloga manages blogrolls and would love to see a plugin for WordPress that does the same thing. In ViaBloga, you simply enter the URL of the site you want to add to your links. ViaBloga then retrieves the title, description, RSS feed address, and even (yes!) a screenshot for the site. No need to fill in fields manually anymore…

Wiki-Keywords plugin

I haven’t through this through yet completely, but it seems to me that a plugin which would add wiki-like capability to WordPress, like ViaBloga does with keywords, could be an interesting idea to explore.

Technorati plugin

This is really a simple one: add a function which will allow easy display of the Technorati cosmos of each post, like I have done manually for this weblog.

On the subject of multilingual blogging, Kevin Marks has some interesting markup suggestions I need to look at more closely.

Similar Posts:

Fixing Newline Abuse in WordPress [en]

Newlines had crept into some of my old posts and corrupted the formatting. Quick and dirty script I used to solve the problem.

[fr] Des retours à  la ligne excédentaires se sont glissés dans mes anciens posts à  un moment donné, cassant des liens et le formattage en général. J'ai utilisé un petit script pour supprimer tous les retours à  la ligne de ces posts.

I only realised right now how badly broken about 500 of my old posts where. Somewhere in the process, newlines got added at the end of each line, and not just at the end of each paragraph. As WordPress kindly and intelligently adds the necessary HTML markup for paragraph and line breaks in posts, this meant that lots of my posts had broken links (when the newline occurred in the middle of a link) and uneven lines.

Victims: about 500 posts.

Solution: luckily, all the concerned posts had complete HTML formatting in them. Purely and simply removing all the newlines with a short PHP script was the way to go.

Thanks to all those who helped. You probably won’t be able to use the script as is, but if you have a similar problem at some point, it might help. The script pulls out the posts from the WordPress database, removes the newlines, and puts the post back into the table.

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.

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( );

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

This assumes that my WordPress install image was located in /home/edublogs/wp-farm/image/ and that the weblog addresses were of the form

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

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:

Requirements for a WordPress Installer Script [en]

To install 30+ WordPress blogs on a server, it would be nice to have an automatic installation script. Here is a list of what this script should do for me.

[fr] Pour installer plus de trente weblogs WordPress sur mon serveur, il serait utile d'avoir un script d'installation en PHP. Quelqu'un a offert d'en écrire un pour moi. Ce billet récapitule ce que devrait faire un tel script, de mon point de vue (installation et configuration de WordPress en fonction d'un nom d'utilisateur).

As you may know, I’m shortly going to install 30+ WordPress blogs on my server. Noderat on #wordpress kindly offered to have a go at writing a PHP script to automate WP installs. I sent him this list of what the ideal script should be able to do for me, but on second thoughts, I’m posting it here so that everybody may see it. Of course, if you know of an existing script which already does this, let me know!

  • take $username + $password as input
  • install wordpress in a subdir named “$username”, using table prefix “$username_” and with an extra user (on top of admin) named “$username” (password=”$password”), user level 3
  • mysql user should be “$username” too (password “$password” also), with grants only on the tables belonging to this weblog
  • set permalink scheme to
    /archives/%year%/%monthnum%/%day%/%postname%/ for monthlies and /categories for categories
  • generate .htaccess in directory, based on this template, with “blog” replaced by “$username” everywhere
  • in wp-config: define (‘WPLANG’, ‘fr’) and edit appropriate lines
  • wp-includes/languages and wp-content/plugins should be symlinked to directories I can specify in the script
  • blog admin password should be reset to something I can specify in the script

I should be able to edit the script config file to provide mysql root user + pass, wordpress database name.

It would also be interesting if the script was built in such a way that it could be further modified/developed to allow installation of blogs on separate subdomains rather than subfolders. From the point of view of the filesystem the blogs live in, this wouldn’t change much — but some extra WordPress options would need editing (e.g. blog address), as well as the Apache and Bind config files necessary to set up the subdomain. This is not mandatory, but could be useful at some point (if we’re thinking in the line of WordPress-farming).

Similar Posts:

MagpieRSS Caching Problem [en]

I have a caching problem using the PHP MagpieRSS library to parse feeds. Any help welcome.

[fr] J'ai un problème de cache utilisant la librarie PHP MagpieRSS. Toute aide bienvenue!

I’ve been stuck on a problem with MagpieRSS for weeks. This is a desperate call for help.

At the top of my sidebar, I have two lists of links which are generated by parsing RSS feeds: Delicious Linkball and Recently Playing. They don’t update.

If I delete the cache files, the script creates them all right. If I keep an eye on the cache files, I see their timestamp is updated every hour, but not the contents. I’ve uploaded the PHP code which parses the feeds.

Any suggestions welcome. I’m not far from giving up and setting cron jobs to regularly delete the cache files. Thanks in advance.

Update 13:00: The Recently Playing list updates once an hour (when the cache is “force-refreshed”), it seems — but not the Delicious Links one.

14:00: Some progress: doesn’t seem to update unless I clear the cache on my machine. (Huh?), on the other hand, is — but why does the cache update only once an hour, and not each time the feed is modified?

15:00: crschmidt just pointed out that the last-modified date on my RSS feed was horribly wrong. Might be something that was done at the time when my caching problems were causing me to nastily abuse the poor server. I’ve sent a mail to Joshua to see if indeed this could be the problem.

15:50: Still thanks to the excellent crschmidt, I’ve finally understood how this caching is supposed to work. (Yes, I know, we’re starting to have lots of edits on this post.) There is a setting which determines how old the cache must be to become “stale”. As long as the cache is not stale, any requests made will use the cache directly, without pulling the feed in question. If the cache is stale, a request is sent to the server hosting the feed to check if it has changed since it was last accessed. If it has changed (i.e., if Last-Modified is more recent than the cache), it gets a fresh version of the feed. Otherwise, nothing happens (the cache age is just “reset”).

Now, for a LinkLog service like, setting the cache age to a couple of hours is more than enough as far as I’m concerned. However, for a list of recently played songs, every few minutes should be better. MagpieRSS seems to allow this to be set on a per-call basis by defining MAGPIE_CACHE_AGE, but it doesn’t seem to be working for me. Another variable is set on a per-installation basis: var $MAX_AGE = 1800; — but changing that won’t really help, as I want different values for Recently Playing and Delicious Links. Suggestions on this secondary problem welcome too!

16:40: After exchanging a few e-mails with Joshua, it seems that there was indeed a problem with the Last-Modified date on my feed. Not quite sure how it came about (somebody requesting the feed when I hadn’t posted in some time?), but it should be fixed now. I’ve cleared my cache files to see if my 30-minute “stale time” is working or not.

17:30: (See how I’m updating every 50 minutes? Freaky.) So, the not-so-nice things about PHP constants is that they are constant and (?) local to the function in which they are defined. (Not sure I go that bit right, but.) Important thing here is to note that MAGPIE_CACHE_AGE can’t be used to set different “stale cache” ages for different feeds. The stale cache age needs to be set at the bottom of (the only place I hadn’t touched) — so my cache is now refreshing every half-hour. (Which is a bit too often for, and not often enough for Audioscrobblers.) oqp says he can write a wrapper to get around this limitation — I’m waiting impatiently for him to do it!

Similar Posts:

Life and Trials of a Multilingual Weblog [en]

Here is an explanation of how I set up WordPress to manage my bilingual weblog. I give all the code I used to do it, and announce some of the things I’d like to implement. A “Multilingual blogging” TopicExchange channel is now open.

[fr] J'explique ici quelles sont les modifications que j'ai faites à WordPress pour gérer le bilinguisme de mon weblog -- code php et css à l'appui. Je mentionne également quelques innovations que j'ai en tête pour rendre ce weblog plus sympathique à mes lecteurs monolingues (ce résumé en est une!) Un canal pour le weblogging multilingue a été ouvert sur TopicExchange, et vous y trouverez peut-être d'autres écrits sur le même sujet. Utilisez-le (en envoyant un trackback) si vous écrivez des billets sur le multinguisme dans les weblogs!

My weblog is bilingual, and has been since November 2000. Already then, I knew that I wouldn’t be capable of producing a site which duplicates every entry in two languages.

I think this would defeat the whole idea of weblogging: lowering the “publication barrier”. I feel like writing something, I quickly type it out, press “Publish”, and there we are. Imposing upon myself to translate everything just pushes it back up again. I have seen people try this, but I have never seen somebody keep it up for anything nearing four years (this weblog is turning four on July 13).

This weblog is therefore happily bilingual, as I am — sometimes in English, sometimes in French. This post is about how I have adapted the blogging tools I use to my bilingualism, and more importantly, how I can accommodate my monolingual readers so that they also feel comfortable here.

First thing to note: although weblogging tools are now ready to be used by people speaking a variety of languages (thanks to a process named “localization”), they remain monolingual. Language is determined at weblog-level.

With Movable Type, I used categories to emulate post-level language awareness. This wasn’t satisfying at all: I ended up with to monstrous categories, Français and English, which didn’t help keep rebuild times down.

With WordPress, the solution is far more satisfying: I store the language information as Post Meta, or “custom field”. No more category exploitation for something they shouldn’t be used for.

Before I really got started doing the exciting stuff, I made a quick change to the WordPress admin interface. If I was going to be adding a “language” custom field to each and every post of mine, I didn’t want to be doing it with the (imho) rather clumsy “Custom Fields” form.

In edit.php, just after the categorydiv fieldset, I inserted the following:

<fieldset id="languagediv">
      <legend>< ?php _e('Language') ?></legend>
	  <div><input type="text" name="language" size="7"
                     tabindex="2" value="en" id="language" /></div>

(You’ll probably have to move around your tabindex values so that the tabbing order makes sense to you.)

I also tweaked the wp-admin.css file a bit to keep it looking reasonably pretty, adding the rule below:

#languagediv {
	height: 3.5em;
	width: 5em;

and adding #languagediv everywhere I could see #poststatusdiv, so that they obeyed the same rules.

In this way, I have a small text field to edit to set the language. I pre-set it to “en”, and have just to change it to “fr” if I am writing in French.

We just need to add a little piece of code in the form processing script, post.php, just after the line that says add_meta($post_ID):

 // add language
	$_POST['metakeyselect'] = 'language';
        $_POST['metavalue'] = $_POST['language'];

The first thing I do with this language information is styling posts differently depending on the language. I do this by adding a lang attribute to my post <div>:

<div class="post" lang="<?php $post_language=get_post_custom_values("language"); $the_language=$post_language['0']; print($the_language); ?>">

In the CSS, I add these rules: {
  content: " [fr] ";
  font-weight: normal;
} {
  content: " [en] ";
  font-weight: normal;
background-color: #FAECE7;

I also make sure the language of the date matches the language of the post. For this, I added a new function, the_time_lg(), to my-hacks.php. I then use the following code to print the date: <?php the_time_lg($the_language); ?>.

Can more be done? Yes! I know I have readers who are not bilingual in the two languages I use. I know that at times I write a lot in one language and less in another, and my “monolingual” readers can get frustrated about this. During a between-session conversation at BlogTalk, I suddenly had an idea: I would provide an “other language” excerpt for each of my posts.

I’ve been writing excerpts for each of my posts for the last six months now, and it’s not something that raises the publishing barrier for me. Quickly writing a sentence or two about my post in the “other language” is something I can easily do, and it will at least give my readers an indication about what is said in the posts they can’t understand. This is the first post I’m trying this with.

So, as I did for language above, I added another “custom field” to my admin interface (in edit-form.php). Actually, I didn’t stop there. I also added the field for the excerpt to the “simple controls” posting page that I use (set that in Options > Writing), and another field for keywords, which I also store for each post as meta data. Use at your convenience:

<fieldset style="clear:both">
<legend><a href=""
title="<?php _e('Help with excerpts') ?>"><?php _e('Excerpt') ?></a></legend>
<div><textarea rows="1" cols="40" name="excerpt" tabindex="5" id="excerpt">
<?php echo $excerpt ?></textarea></div>
<fieldset style="clear:both">
<legend><?php _e('Other Language Excerpt') ?></legend>
<div><textarea rows="1" cols="40" name="other-excerpt"
tabindex="6" id="other-excerpt"></textarea></div>
<fieldset style="clear:both">
<legend><?php _e('Keywords') ?></legend>
<div><textarea rows="1" cols="40" name="keywords" tabindex="7" id="keywords">
<?php echo $keywords ?></textarea></div>
<!-- I moved around some tabindex values too -->

I inserted these fields just below the “content” fieldset, and styled the #keywords and #other-excerpt textarea fields in exactly the same way as #excerpt. Practical translation: open wp-admin.css, search for “excerpt”, and modify the rules so that they look like this:

#excerpt, #keywords, #other-excerpt {
	height: 1.8em;
	width: 98%;

instead of simply this:

#excerpt {
	height: 1.8em;
	width: 98%;

I’m sure by now you’re curious about what my posting screen looks like!

To make sure the data in these fields is processed, we need to add the following code to post.php (as we did for the “language” field above):

// add keywords
	$_POST['metakeyselect'] = 'keywords';
        $_POST['metavalue'] = $_POST['keywords'];
   // add other excerpt
	$_POST['metakeyselect'] = 'other-excerpt';
        $_POST['metavalue'] = $_POST['other-excerpt'];

Displaying the “other language excerpt” is done in this simple-but-not-too-elegant way:


    <div class="other-excerpt" lang="<?php print($the_other_language); ?>">
    <?php print($the_other_excerpt); ?>

accompanied by the following CSS:

background-color: #FAECE7;
background-color: #FFF;
div.other-excerpt:before {
  content: " [" attr(lang) "] ";
  font-weight: normal;

Now that we’ve got the basics covered, what else can be done? Well, I’ve got some ideas. Mainly, I’d like visitors to be able to add “en” or “fr” at the end of any url to my weblog, and that would automatically filter out all the content which is not in that language — maybe using the trick Daniel describes? In addition to that, it would also change the language of what I call the “page furniture” — titles, footer, and even (let’s by ambitious) category names. Adding language sensitivity to trackbacks and comments could also be interesting.

A last thing I’ll mention in the multilingual department for this weblog is my styling of outgoing links if they are written in a language which is not my post language, using the hreflang attribute. It’s easy, and you should do it too!

Suw (who has just resumed blogging in Welsh) and I have just set up a “Multilingual blogging” channel on TopicExchange — please trackback it if you write about blogging in more than one language!

Similar Posts:

Batch Category Editing For WordPress [en]

I put together an admin screen for WordPress today which allows changing multiple categories of multiple posts at the same time. Code available, no guarantees.

[fr] J'ai codé une extension à  WordPress qui permet d'éditer les catégories de nombreux billets en un coup. L'écran liste par exemple tous les billets d'une catégorie, accompagnés d'un certain nombre de selects. On effectue les modifications que l'on désire et on soumet le formulaire entier en une fois.

Update 13.07: A more recent version is out!

I had planned to give you a write-up of the beginning of my WordPress experience today. Unfortunately, I decided to clean up my categories somewhat before I did that, and I managed to badly mess things up.

The result is that I spent most of my day writing a Batch Categories admin screen to help me clean things up. It was something I had planned to do, and I suppose it will also be useful to other people.

If you want to play around: copy the code above into a file named batch-categories.php in your wp-admin directory. I highly recommend that you back up your wp_post2cat table before you get going. This script works for me, but hasn’t been tested much, and comes with no guarantees. It is not optimised either, so depending on how many posts and categories you list, the screen can very well take over half a minute to load!

There are still a few functionalities I want to add, in particular: assigning all listed posts to a category in one go (or removing them).

If you want pretty integration with the other screens of the Edit menu, you’ll have to tweak the navigation bar in edit.php, edit-comments.php, and moderation.php.

Update 24.06.04: I’ve uploaded a screenshot of the admin screen so you can see what it could look like.

Update II 24.06.04: Instead of hacking the Edit menu bars, you can also access the Batch Categories screen from the Plugins page: create a file called batch-access.php (e.g.) in your plugins directory. (Beware not to leave any whitespace after the ?>, though, or you’ll get errors. Promised, zips and more detailed documentation will follow.

Update 04.07.04: I tried using the script this morning, and it seems nastily broken (removed all categories for some posts). Use with caution, and get back to me if ever you hack it or modify it, I’m interested! I’ll look into this once I get back home from Vienna.

Update 12.07.04: The script now works as it should! Thanks to Ben and MooKitty for helping me nail the big nasty bug which was driving me bonkers! Two improvements I’m working on right now: making the code more efficient by using the category cache, and adding a “add all listed posts to category X” option.

Similar Posts:

Validation and Errors [en]

Although neither do validate, we should not judge a valid page with errors as harshly as a page of tag soup.

For some time now, I have been meaning to clarify the distinction I make between markup which is valid with errors and that which is outright invalid. Yes, I know, in both cases it does not validate.

Take a page which would normally validate as xhtml strict, and insert some are errors into it, like an unclosed tag, an unescaped ampersand and maybe even (oh horror!) a couple of target="_blank" attributes. It does not validate.

Take tag soup. It does not validate either.

But there is a difference between the two, you’ll have to admit. Which is why I suggest calling one of them valid with errors and the other one outright invalid (or just plain invalid). This would also encourage us standards evangelists to be a bit more appreciative of the efforts of those who have gone through the trouble of cleaning up their markup and bringing it nearer to validation, compared to those who just don’t give a damn. As seen on various mailing lists and forums, they are often both greeted quite bluntly with the same “your page doesn’t validate!”

For me, the difference is the same as the one between a well structured text with correct grammar but a few spelling mistakes (it can happen to anybody, even to English teachers!) and a clumsy story with no plot or ending, filled with spelling mistakes, and approximate grammar which makes certain sentences unintelligible.

That might also help us respond to “anti-standards” people who go around sticking our pages in the validator and then say “Hah! it doesn’t validate, look, 50 errors, they’re as bad as we are!”

I’ll say it again: validation (with zero errors) is important. Your PHP or XML parser doesn’t care if there is one or 100 mistakes in your page: it can’t parse it. But we are human beings, and should give credit where credit is due. A “valid page with errors” is not as big a crime as tag soup.

Similar Posts: