Comment

I just released a minor update of WP Mollom with some bugfixes. This is the changelog:

• Fixed: minor issues with the Captcha not being rendered correctly
• Added: mollom_manage_wp_queue() function which adds Mollom support to the default comment administration panel
• Improved: updating from a previous version is now more robust

More info and download on WordPress Extend

These two weren’t the best friends over the past couple of weeks. Since someone notified me they weren’t compatible, it took some time to figure out what was going wrong. My initial suspects was an icky way of dealing with the action hooks. Either by my plugin or WP OpenID. But after extensive testing, I concluded that the order in which the action hooks call the different plugin functions, wasn’t problem.

I identified the problem as the comment data getting lost somewhere along the way. I tested the OpenID plugin and the transition to the Mollom plugin. In the end, I could narrow the problem down to odd behaviour of global variables in WordPress. Let’s take a look at this bit of code:

<br> function dosomething($ds_comment) {<br> global $ds_comment;<br> print_r($ds_comment);<br> return $ds_comment;<br> }<br> add_action('preprocess_comment', 'dosomething');<br>

For brevity’s sake, I ommitted the obligatory WordPress plugin header. But if you add it, put this bit in a seperate file, upload it to your plugins/ folder and activate. Now you can test if yourself. The idea is that the array containing the commentdata is shown in your browser just before putting it in the database (notice that your browser doesn’t redirect to the original page, but that’s not the issue here). In reality, you’ll get a blanco page. Meaning the array $ds_comment is in fact empty. Further on, you’ll just pass empty variables and in the end save an empty record to your database. The comment got lost into cyberoblivion. Not very nice.

Now. Just comment out or remove the global $ds_comment; bit and try again. Now, if you submit a new comment, the data will be output to the browser nicely.

Conclusion: If you make the very same variable that was passed as an argument through the function, global, the data just gets lost. Very odd. Now, if you create a new, empty, global variable within the function and assign the data from $ds_comment to it, there is no problem whatsoever.

I wonder how this could happen…

Ow. Making a lot of variables global, especially those with sensitive data, is not really best practice. There are more gracious ways of passing data around like OO programming design or paying attention to correct function reuse. In a future incarnation, I’ll try to reduce the amount of globals I use. For now, I just want the damn thing to behave like it should. 😉

Today, I had an e-mail discussion with Dries and Benjamin over the use of a moderation queue within the context Mollom provides. I have on implemented in my plugin. The idea is that ‘unsure’ comments that don’t get through the CAPTCHA test, land in a moderation queue… sort of.

Mollom was actually designed to get rid of the queue. Checking if a commenter is human or a spambot happens through the CAPTCHA test. Early on in the process of posting a comment. That makes a queue where an administrator has to do the check after the facts quite unnecessary.

The problem is that the way I designed the plugin forced me use a moderation queue altogether. ‘Unsure’ labelled comments happen to land in the database, before the CAPTCHA check. Two months ago, that seemed the logical way out to me. Dries gave me some more insight in the workings of the Drupal module and was able to convince me to seperate the CAPTCHA check from the moderation queue. (I am not nearly into Drupal as I am into the workings of WordPress!)

So. It’s a bit back to the drawingboard for me as this means some parts of the plugin need to be reviewed.