Tag: Weblog Technology

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: http://del.icio.us/rss/steph/ doesn’t seem to update unless I clear the cache on my machine. (Huh?) http://ws.audioscrobbler.com/rdf/history/Steph-Tara, 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 del.icio.us 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 del.icio.us 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 del.icio.us, 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 rss_fetch.inc (the only place I hadn’t touched) — so my cache is now refreshing every half-hour. (Which is a bit too often for del.icio.us, 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!

Musings on a Multiblog WordPress [en]

Thinking about a solution to make WordPress MultiBlog. Comments, criticism and other ideas welcome — please join the fun. In particular, I bump into a hairy PHP include problem.

[fr] Je réfléchis à comment on pourrait donner à WordPress la capacité de gérer plusieurs blogs avec une installation. Je me heurte à un problème concernant les includes PHP. Feedback et autres idées bienvenues!

Update June 2007: Try WordPress Multi-User now.

I’ve used Shelley’s instructions using soft links. I tried Rubén’s proof-of-concept, but got stuck somewhere in the middle.

So I started thinking: how can we go about making WordPress MultiBlog-capable? Here is a rough transcript of my thoughts (I’ve removed some of the dead ends and hesitations) in the hope that they might contribute to the general resolution of the problem. I have to point out my position here: somebody with a dedicated server who’s thinking of setting up a “WordPress weblog-farm” (for my pupils, mainly). So I’m aware that I’m not the “standard user” and that my solution is going to be impractical to many. But hey, let’s see where it leads, all the same. Actually, I think I probably reconstructed most of Rubén’s strategy here — but I’m not sure to what extent what I suggest differs from what he has done.

From a system point of view, we want to have a unique installation of WordPress, and duplication of only the files which are different from one blog to another (index.php, wp-config.php, wp-comments.php, wp-layout.css, to name a few obvious ones). The whole point being that when the isntall needs to be upgraded, it only has to be upgraded in one place. When a plugin is downloaded and installed, it only has to be done once for all weblogs — though it can of course be activated individually for each weblog.

From the point of view of the weblogs themselves, they need to appear to be in different domains/subdomains/folders/whatever. What I’m most interested in is different subdomains, so I’ll stick to that in my thinking. (Then somebody can come and tell me that my “solution” doesn’t work for subfolders, and here’s one that works for subfolders and subdomains, and we’ll all be happy, thankyouverymuch.) So, when I’m working with blog1.example.com all the addresses need to refer to that subdomain (blog1.example.com/wp-admin/, etc); ditto for blog2.example.com, blog3.example.com, blogn.example.com (I used to like maths in High School a lot).

As Rubén puts it, the problem with symbolic links (“soft links”) is called “soft link hell”: think of a great number of rubber bands stretched all over your server. Ugh. So let’s try to go in his direction, for a while. First, map all the subdomains to the same folder on the server. Let’s say blog1.example.com, blog2.example.com (etc.) all point to /home/bunny/www/wordpress/. Neat, huh? Not so. They will all use the same wp-config.php file, and hence all be the same weblog.

This is where Rubén’s idea comes in: include a file at the top of wp-config.php which:

  1. identifies which blog we are working with (in my case, by parsing $HTTP_HOST, for example — there might be a more elegant solution)
  2. “replaces” the files in the master installation directory by the files in a special “blog” directory, if they exist

The second point is the tricky one, of course. We’d probably have a subfolder per blog in wordpress/blogs: wordpress/blogs/blog1, wordpress/blogs/blog2, etc. The included file would match the subdomain string with the equivalent folder, check if the page it’s trying to retrieve exists in the folder, and if it does, include that one and stop processing the initial script after that. Another (maybe more elegant) option would be to do some Apache magic (I’m dreaming, no idea if it’s possible) to systematically check if a file is available in the subdirectory matching the subdomain before using the one in the master directory. Anybody know if this is feasible?

The problem I see is with includes. We have (at least) three types of include calls:

  • include (ABSPATH . 'wp-comments.php');
  • require ('./wp-blog-header.php');
  • require_once(dirname(__FILE__).'/' . '/wp-config.php');

As far as I see it, they’ll all break if the calling include is in /home/bunny/www/wordpress/blogs/blog1 and the file to be called is in /home/bunny/www/wordpress. What is wrong with relative includes? Oh, they would break too. Dammit.

We would need some intelligence to determine if the file to be included or called exists in the subdirectory or not, and magically adapt the include call to point to the “right” file. I suspect this could be done, but would require modifying all (at least, a lot of) the include/requires in WordPress.

Maybe another path to explore would be to create a table in the database to keep track of existing blogs, and of the files that need to be “overridden” for each blog. But again, I suspect that would mean recoding all the includes in WordPress.

Another problem would be .htaccess. Apache would be retrieving the same .htaccess for all subdomains, and that happens before PHP comes into play, if I’m not mistaken.

Any bright ideas to get us out of this fix? Alternate solutions? Comments? Things I missed or got wrong? The comments and trackbacks are yours. Thanks for your attention.

Easier TopicExchange Trackbacks for WordPress [en]

A WordPress hack which makes it quicker to add TopicExchange channels to trackback, and makes them visible (like categories) in the weblog. (Sorry for the duplicate postings, trying to fix it.)

[fr] Ce 'hack' pour WordPress permet d'ajouter facilement des trackbacks vers les canaux de TopicExchange, et liste sur le weblog les canaux concernés pour chaque billet.

Here is a solution to make it a little quicker to trackback TopicExchange channels with WordPress, and make those channels visible in your weblog.

I love TopicExchange. When I asked Suw what they had talked about during BlogWalk, she mentioned trackbacks. I asked if anything had been discussed about trackback etiquette. For example, I’m often tempted to trackback people who have written posts related to mine, but which I haven’t linked to. Well, the consensus is that this is not what trackback is for. Trackback is really for making a “backlink”. TopicExchange is the answer to the “related posts” issue.

I’ve been using TopicExchange a lot during the last weeks, but nobody has noticed it, apart from those people who already use TopicExchange as a source of information. As Seb Paquet notes, TopicExchange needs to be made more viral. It needs visibility. What follows is my interpretation of “making ITE easier to use, and more visible.”

This WordPress hack creates an extra field in the posting form where ITE channel ID’s (e.g. “wordpress”, “multilingual_blogging”) can be entered (I was tired of typing the whole trackback URL’s all the time). It then stores these channel ID’s as post meta data (in the postmeta table), so that it can retrieve them and display links to the corresponding channels along with the post, just as is usually done with categories.

First of all, add the following code to my-hacks.php. Then, edit post.php (in your wp-admin directory) and add this code where indicated (the comment at the top of the file explains where to insert the code).

Also in post.php, after the line add_meta($post_ID);, insert the following code:

// add topic exchange channels
	if(isset($_POST['ite-topic']))
	{
		$_POST['metakeyselect'] = 'ite_topic';
		foreach($topics as $topic)
		{
    		$_POST['metavalue'] = $topic;
    		add_meta($post_ID);
    	}
    }

In edit-form.php, add this code to create an extra input field for ITE trackbacks:

$form_ite = '<p><label for="ite-topic"><strong>Trackback</strong> TopicExchange:</label>
(Separate multiple channel ID's with spaces.)<br />
<input type="text" name="ite-topic" style="width: 360px" id="ite-topic"
tabindex="8" /></p>';
	$form_trackback.=$form_ite;

It goes near the top of the file, after the line which defines $form_trackback (do a search for that and you’ll find it).

Finally, in your index.php template, you can use <?php the_ite_channels(); ?> to display a paragraph containing a comma-separated list of channels trackbacked for each post. If you want to change the formatting, play around with the function definition in my-hacks.php.

If, like me, you have old posts with trackbacks to TopicExchange, and you would also like these to appear on your posts, use this patch from inside wp-admin. The patch will tell you what meta data it is adding — just load it once in your browser and check the result in your weblog. (Don’t load it twice — it’s supposed to be able to check the existing channels in the database to avoid duplicate entries, but I haven’t got it to work. Read instructions and debug notes at the top of the patch file.)

In future, it will also be possible to use the TopicExchange API to return the “nice title” for the channels listed — so we sould have “Multilingual blogging” instead of “multilingual_blogging”. (I’ve asked, it will behas been added to the API.)

Good luck with this if you try it, and as always, comments most welcome!

Note: as far as I have tested, the code seems to work now.

Converting MySQL Database Contents to UTF-8 [en]

I finally managed to convert my WordPress database content to UTF-8. It’s easy to do, but it wasn’t easy to figure out.

[fr] Voici comment j'ai converti le contenu de ma base de données WordPress en UTF-8. C'est assez simple en soi, mais ça m'a pris longtemps pour comprendre comment le faire!

A few weeks ago, I discovered (to my horror) that my site was not UTF-8, as I thought it was. Checking my pages in the validator produced this error:

The character encoding specified in the HTTP header (iso-8859-1) is different from the value in the XML declaration (utf-8). I will use the value from the HTTP header (iso-8859-1).

In all likeliness, my server adds a default header (iso-8859-1) to the pages it serves. When I switched to WordPress, I was careful to save all my import files as UTF-8, and I honestly thought that everything I had imported into the database was UTF-8. Somewhere in the process, it got switched back to iso-8859-1 (latin-1).

The solution to make sure the pages served are indeed UTF-8, as specified in the meta tags of my HTML pages, is to add the following line to .htaccess:

AddDefaultCharset OFF

(If one wanted to force UTF-8, AddDefaultCharset UTF-8 would do it, but actually, it’s better to leave the possibility to serve pages with different encodings, isn’t it?)

Now, when I did that, of course, all the accented characters in my site went beserk — proof if it was needed that my database content was not UTF-8. Here is the story of what I went through (and it took many days to find the solution, believe me, although it takes only 2 minutes to do once everything is ready) to convert my database content from ISO-8859-1 to UTF-8. Thanks a lot to all those who helped me through this — and they are many!

First thing, dump the database. I always forget the command for dumps, so here it is:

mysqldump --opt -u root -p wordpress > wordpress.sql

As we’re going to be doing stuff, it might be wise to make a copy of the working wordpress database. I did that by creating a new database in PhpMyAdmin, and importing my freshly dumped database into it:

mysql -u root -p wordpress-backup < wordpress.sql

Then, conversion. I tried a PHP script, I tried BBEdit, and they seemed to mess up. (Though as I had other issues elsewhere, they may well have worked but I mistakenly thought the problem was coming from there.) Anyway, command-line conversion with iconv is much easier to do:

iconv -f iso-8859-15 -t utf8 wordpress.sql > wordpress-iconv.sql

Then, import into the database. I first imported it into another database, edited wp-config.php to point to the new database, and checked that everything was ok:

mysql -u root -p wordpress-utf8 < wordpress-iconv.sql

Once I was happy that it was working, I imported my converted dump into the WordPress production database:

mysql -u root -p wordpress < wordpress-iconv.sql

On the way there, I had some trouble with MySQL. The MySQL dump more or less put the content of all my weblog posts on one line. For some reason, it didn’t cause any problems when importing the dump before conversion, to create the backup database, but it didn’t play nice after conversion.

I got this error when trying to import:

ERROR 1153 at line 378: Got a packet bigger than 'max_allowed_packet'

Line 378 contained half my weblog posts… and was obviously bigger than the 1Mb limit for max_allowed_packet (the whole dump is around 2Mb).

I had to edit my.cnf (/etc/mysql/my.cnf on my system) and change the value for max_allowed_packet in the section titled [mysqld]. I set it to 8Mb. Then, I had to stop mysql and restart it: mysqladmin -u root -p shutdown to stop it, and mysqld_safe & to start it again (as root).

This is not necessarily the best way to do it, and it might not work like that on your system, but it’s what I did and the site is now back up again. Comments welcome, and hope this can be useful to others!

Batch Categories 0.9 [en]

Batch Categories for WordPress has been fixed and enhanced. If you have major category jobs to do, it can probably help you. Feedback and testers welcome.

[fr] Batch Categories pour WordPress a été corrigé et fonctionne à  présent. Le compagnon idéal si vous desirez changer les catégories de nombreux billets en même temps.

Batch Categories 0.9 is out! It’s the ideal companion for large-scale post-import messy category work. List all posts belonging to a category or matching a keyword, and edit their categories, easily visible at a glace with a collection of sexy drop-down lists. What’s new since the the first draft?

  • It now works, and does not “eat” categories without a warning. (Pretty nice of it, huh?)
  • It tells you what it did — which categories it added to which posts, and which ones it removed.
  • Add a whole bunch of posts to a category with one click.
  • Remove a whole bunch of posts from a category with one click.
  • Ensures that all the categories for a post are always listed, whatever the setting for the limit number of drop-down lists.
  • This is what it can look like.

You can still access it as a plugin or edit the Edit navigation menu, as described in my post introducing Batch Categories. If you’re in a hurry, just drop the PHP file into your wp-admin directory and send your browser straight on it.

Next steps?

  • Gather feedback from courageous testers (please don’t blame me if you haven’t backed up your post2cat table and things go wrong) for chasing the last bugs, improving interface and functionality.
  • Redo the code which generates the drop-down lists to take advantage of the category cache, and avoid flooding the database with useless queries.
  • Allow more subtle selection of posts: combinations of categories (AND/OR/NOT), categories without their subcategories…
  • Anything else you would want…?

Update 24.07.04: BB made me notice that “All” and “None” didn’t make much sense in the drop-down which allows one to select the categories to display. Replaced them in v. 0.91 by “Any category”.

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>
</fieldset>

(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
	if(isset($_POST['language']))
	{
	$_POST['metakeyselect'] = 'language';
        $_POST['metavalue'] = $_POST['language'];
        add_meta($post_ID);
        }

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:

div.post:lang(fr) h2.post-title:before {
  content: " [fr] ";
  font-weight: normal;
}

div.post:lang(en) h2.post-title:before {
  content: " [en] ";
  font-weight: normal;
}

div.post:lang(fr)
{
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:

<!-- BEGIN BUNNY HACK -->
<fieldset style="clear:both">
<legend><a href="http://wordpress.org/docs/reference/post/#excerpt"
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>

<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>

<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>
</fieldset>
<!-- I moved around some tabindex values too -->
<!-- END BUNNY HACK -->

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
	if(isset($_POST['keywords']))
	{
	$_POST['metakeyselect'] = 'keywords';
        $_POST['metavalue'] = $_POST['keywords'];
        add_meta($post_ID);
        }

   // add other excerpt
	if(isset($_POST['other-excerpt']))
	{
	$_POST['metakeyselect'] = 'other-excerpt';
        $_POST['metavalue'] = $_POST['other-excerpt'];
        add_meta($post_ID);
        }

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

<?php
$post_other_excerpt=get_post_custom_values("other-excerpt");
$the_other_excerpt=$post_other_excerpt['0'];

if($the_other_excerpt!="")
{
	if($the_language=="fr")
	{
	$the_other_language="en";
	}

	if($the_language=="en")
	{
	$the_other_language="fr";
	}
?>

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

  <?php
  }
  ?>

accompanied by the following CSS:

div.other-excerpt:lang(fr)
{
background-color: #FAECE7;
}

div.other-excerpt:lang(en)
{
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!

EPFL Offers Blogs to All Its Students [en]

A major engineering school in French-speaking Switzerland (Lausanne) has opened a blogging platform for all students and staff.

[via Hannes, Roberto]

The EPFL (Ecole Polytechnique Fédérale de Lausanne) has set up a blogging platform for all students and staff.

The platform is home-cooked, Java-based, and still in early stages. Trackback and external comments have not been implemented at this stage because of potential spam problems. Their archiving system is in my opinion a little basic, but the blogs all have RSS feeds, so I think there is definitely hope for the future.

I blogged about this in French yesterday, but I think it’s significant news enough for me to mention it again in English. (Plus, I’m thinking very hard about the implication of being a multilingual blog with monolingual readers…)

WordPress get_nested_categories() Bug [en]

Some code I produced while trying to fix and already fixed Wordpress bug (in get_nested_categories()).

I bumped into my first really annoying WordPress bug today. The function get_nested_categories(), which is used to display the different categories available in the admin screens, wrongly assumes in 1.2 that people create their parent categories before their children (and that the latter have a higher ID than the former).

This has been fixed in the CVS. However, as there have been changes since 1.2 in CVS, you need to copy the code provided on the bug report page. Take the first function from the “Additional Information” part, and the second one from the “Bug Notes” section.

As I didn’t know about the web-based CVS, I started trying to fix the bug myself. It’s almost finished but doesn’t work yet (just a little bug to track down), and it only uses one MySQL query, whereas the fix presented above can end up using lots, if you have a complicated hierarchical category structure like mine. You’re welcome to have a go at my code — let me know if you find the problem!

Next time I meet a bug, I’ll check in CVS first to make sure it isn’t already half dead.

Déferlement de blogs sur la Romandie [fr]

L’EPFL offre des blogs à  ses étudiants!

[via Hannes, Roberto]

L’EPFL offre des weblogs à  ses étudiants! C’est assez notable pour que j’outrepasse la limite de un billet par jour que je me suis fixée post-BlogTalk afin de préserver mes mains. Dire qu’on s’étonnait lundi quand je répondais qu’il n’existait pas de fournisseur de solution de blogging suisse! Il y en a désormais au moins un, même s’il s’adresse à  un public limité.

Fils RSS et catégories pour tous les weblogs, c’est bien. Permaliens pour les articles qui n’incluent pas le nom du weblog (http://blogs.epfl.ch/article/xxxx), moins bien.

Commentaires, bien — pas de trackback, moins bien.

Mais franchement, chapeau! Je suis épatée. Très très bel effort. Qui est à  l’origine de cette initiative? Qui a développé la plateforme? Je serais vraiment ravie de rentrer en contact avec ces personnes.

Mise à  jour 19h30: il s’agit du KIS de l’EPFL.

Pour les étudiants de l’EPFL qui se trouverait à  lire cet article, je suggère deux ressources que j’ai mises à  disposition:

  • C’est quoi, un weblog?, un article écrit en juillet 2002 et qui présente les weblogs aux néophytes;
  • Swissblogs.com, un annuaire des weblogs suisses, dans lequel vous pouvez ajouter le vôtre.

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.