http://benderydt.com

If you have an old WordPress blog like me, you’ll notice all kinds of problems with accented letters in late WordPress’ versions. The trouble is that WordPress was once young and foolish and created its MySQL database in the default latin-1 character set. Which was all fine and dandy, except the fact that WordPress dumped UTF-8 encoded unicode data into this database.

MySQL didn’t mind and PHP didn’t know anything about Unicode, so no harm done. The trouble began when WordPress actually started requesting UTF-8 data from MySQL. MySQL notices that the data in the tables is in latin-1 format and converts the latin-1 data to UTF-8.

That means that your data is double-encoded. één becomes één and so on. One possible way to solve this problem is to leave the communication between WordPress and MySQL in latin-1. (DB_charset = 'latin1'). The best solution, however, is to fix the database: mark all fields, tables, and the database charset as UTF-8. Trouble is, whenever you do this in for instance phpMyAdmin, MySQL converts the actual data to UTF-8, thus double-encoding the data once and for good.

The solution for this new problem is an intermediate step: mark all latin-1 fields as blobs (binary data) and then change them back again to UTF-8 encoded text fields. This solution works because MySQL doesn’t convert anything from latin-1 to blob, nor from blob to UTF-8. But is is quite labourous and you have to delete and recreate all indexes.

So here’s my solution: More »

Nu mijn oude server weer bij de pinken is, wou ik een versie van deze site lokaal zetten om er in alle rust aan te kunnen prutsen. Valt tegen: respons-tijden van 10 tot 20 seconden per pagina en Apache gebruikt meer dan 50% CPU. OK, het is maar een Pentium II, maar toch…

Na een paar serieuze programmeersessies staan er eindelijk films op de website van mijn school, FiViKASKA.be. Allen daarheen dus.

‘t Heeft wel wat zweet gekost en ik ben ook niet zo zeker meer of de volgende iteratie van benderydt.com nog wel op WordPress zal draaien, maar dat zijn zorgen voor later. Als Django nu eens op shared webhosts zou draaien…

Kort gesteld ben ik de volgende vervelende zaken tegengekomen:

1. Het is veel te moeilijk om WordPress’ admin scherm uit te breiden om een nieuw gegevenstype aan te maken. Ondanks alle hooks en filters kan je bijna niets veranderen aan wordpress/wp-admin/post.php, de plaats waar je nieuwe berichten ingeeft. Ik heb bijna de hele post.php-interface moeten dupliceren om daar een hoop dingen aan te kunnen toevoegen.
2. Niets nieuws onder de zon, maar PHP is af en toe echt wel braindead. Kijk bijvoorbeeld naar deze tabel en probeer eens op één, twee, drie te bedenken hoe je test of er iets in een stringvariabele zit. if ($string)? Nope, dit faalt wanneer de string de waarde "0" bevat. if (isset($string))? Nee, want een lege string geeft ook TRUE bij isset. if (! empty($string))? Zelfde verhaal als bij if ($string), "0" geeft een vals negatief. De oplossing is if (strlen($string)) of if ($string !== ''). Intuïtief, nietwaar?
3. WordPress heeft de abjecte en bijna misdadige gewoonte om bij aanvang van een request alle POST en GET variabelen te quoten zodat ze veilig in de databank kunnen weggeschreven worden. Abject omdat je telkens je iets met die variabelen wil doen ze moet ont-quoten om ze daarna terug te quoten. Bijna misdadig omdat core WordPress-functies als wp_insert_post niet meer checken of de input nog ge-quote-d moet worden, maar blindelings alles in de database dumpen, zelfs zonder foutboodschappen te checken (#6227). Dit wil zeggen dat eender welke plugin die deze functie(s) gebruikt zonder de input te quoten, een rechtstreekse input naar de database geeft. Denk aan input als hallo '; DROP DATABASE; en je database is weg. (WordPress core is OK omdat ze alles quoten.)

Daar staat tegenover dat, als het werkt, de admin-schermen van WordPress ook voor een leek bruikbaar zijn, en daar was het tenslotte allemaal om begonnen.

While developing a WordPress plugin I stumbled upon the following annoying problem:

My plugin consists of several interlinked pages with forms on them, like a wizzard. They’re integrated into the WordPress admin environment by means of the handy add_menu_page and add_submenu_page-functions. I want to check the result of the forms and advance the user to the next page using wp_redirect whenever I have sufficient input. Pretty easy for a standalone php webpage: check the $_POST-array, do whatever you have to do and redirect the browser to the next page when you’re satisfied before outputting any html (not even a space or carriage return).

However, my pages are never called directly. They exist inside WordPress’ admin.php page, and admin.php outputs the top part of the page before my code is even called. This means that the HTTP-redirect will always fail. You simply cannot send HTTP-Headers somewhere in the middle of the HTTP-body (i.e. the actual html).

Thinking about it, I thought I had two options:

1. hook into WordPress’ init or send_headers hooks. These are called before any html-output.
2. call my php-files directly in the forms action and replicate all admin.php-code inside them.

I didn’t like the first option ’cause init or send_headers are called for every pageview, and I’d have to find out whether the request originated from one of my forms. Plus I’d have to seperate all application logic in one central place, away from the actual pages. I didn’t like the second option ’cause I’d have to track the WordPress core pretty tightly to make sure none of my replicated code contained any newfound WordPress bugs. However, upon inspecting admin.php, I found a third option.

admin.php won’t output anything if you call your plugin page with an optional &noheader GET argument, but it will setup the whole WordPress environment for you. I’m quite happy: all I have to do is change my forms action from this

<form method="post" action="admin.php?page=your_plugin_page.php">

to this

<form method="post" action="admin.php?page=your_plugin_page.php&noheader">

and I can redirect to my hearts content. You can make it draw the menu with this bit of code:

/* this strange thing makes WordPress output the admin header whenever we need it
   we turn the header off with "&noheader" so we can redirect with WP_Redirect
*/
if (isset($_GET['noheader']))
	require_once(ABSPATH . 'wp-admin/admin-header.php');

after you’ve done your validation and possible redirection.

A story of tags and categories:

WordPress 2.3 brought tags to WordPress. At first this seemed quite unnecessary as WordPress already had categories to organize blogposts. I recently discovered categories can be quite handy to make a broad division between different kind of posts, say a news snippet versus an essay, while tags provide a quick way to mark posts. WordPress even has a handy wp_tag_cloud()-function to show the tags you use in a fashionable way.

There’s only one problem: the tagcloud is based on all posts. Fine and dandy on the frontpage of your blog, but a lot less usefull on category pages. There is no easy way to generate a tagcloud for all posts belonging to a specific category. I personaly need something like this for FiviKASKA.be, since I want a clear distinction between news and movies on that site. So I started tinkering.
More »

Eindelijk min- of meer online: FiviKASKA.be, de nieuwe website van mijn school.

Er staat nu nog niet veel op, maar ik hoop wel dat de site in de toekomst wat meer leven uitstraalt dan de officiële schoolsite (en ook wat beter navigeerbaar wordt…)

Het is natuurlijk nog wachten op de films die erop komen, daarvoor heb ik nog wat meer programmeerwerk. Ik weet nu in ieder geval al veel meer over WordPress dan voorheen: volledig nieuwe theme gemaakt (in tegenstelling tot deze blog die een vrij slaafse aanpassing van het default-theme is), een stuk of 2 adminstratieve plugins geschreven en nog 1 herschreven. Normaal werkt alles in Internet Explorer, en ik hoop dat dat zo blijft. Browsershots is natuurlijk niet de ideale manier om een site te checken op compabiliteit…

Het grote werk dat nog wacht is op een elegante manier de films die op school gemaakt worden erop krijgen. Probleem 1 daarbij is die oude getrouwe HTTP-POST beperkingen wat grote bestanden betreft. Ik moet mensen films laten uploaden via ftp en dat dan linken aan een bericht zonder dat ze elkaars films zitten overschrijven. Probleem 2 is om gestructureerde content in WordPress te krijgen, daar is het eigenlijk niet voor gemaakt. Als die visual editor nu eens tables ondersteunde, dat zou mijn werk al heel wat simpeler maken.

Het is in ieder geval een taai beestje, die WordPress. Ik denk dat ik alle pagina’s van deze site in WordPress ga omzetten, dan worden die film- en techpagina’s hopelijk eens wat sneller aangepast. Sometime, somewhere, somehow.