K-Squared Ramblings

Working on a Twitter Tools Filter for #fb Tags

Since the normal Twitter/Facebook link stopped working, I’ve switched to Selective Twitter Status. Instead of importing all your Twitter status updates to Facebook, it only pulls in the ones that end with the hashtag #fb. I’ve thrown together a plugin that hooks into Twitter Tools and filters out that tag when building a daily or weekly digest. (It was complicated by the fact that the README didn’t provide any real detail for the relevant API hook.) I tested the function outside of WordPress, then set it up to run on Thursday evening.

Good: It worked! Every instance of the #fb tag was removed, and everything else stayed.
Bad: Twitter Tools posted four copies of the digest.

Well, Twitter Tools does that sometimes. I’ll frequently see it post 2 or even 3 copies, and while I’ve determined it’s not related to WP Super-Cache, I haven’t gotten around to seriously debugging it. So I don’t know if it has anything to do with my plugin. Actually, it probably doesn’t, since it runs within the digest-building code.

For what it’s worth, Friday posted only two copies of the digest. I only found one item worth saving, though. (Well, two, but I expanded the other one into this post.)

I guess it still needs some testing. When I’m sure it’s working properly, I’ll post the code.

WordPress Mobile Validating Patch

I’ve been using Alex King’s WordPress Mobile Edition for a while to provide a mobile-friendly version of this blog, but haven’t really paid much attention to it since my last few phones were extremely limited in web browsing ability. Since I got the G1, I’ve been paying more attention to mobile access, including setting up WPTouch for a high-functioning iPhone– & Android–friendly version of the site. Last week I finally got around to testing the two plugins in combination, and determined that they do seem to work together with the right priorities.

I also ran the main page through the mobile-readiness evaluator at ready.mobi, and noticed that most of the issues it cited with the mobile edition of the site were really simple changes. Some were basics like fixing unbalanced HTML, and others were recommended practices like including a DOCTYPE and making sure that headings were nested properly. So I whipped together a patch for WordPress Mobile Edition 2.1a. (It’s labeled as 2.1.1 in the readme, but it shows up as 2.1a in the list of plugins.)

Changes:

• Add XHTML Mobile 1.2 Doctype.
• Fix unbalanced <small> tag.
• Fix mising <ul> tags around list of recent posts.
• Avoid empty class attribute on comments.
• Add type attribute to style element.
• Change non-standard value attribute on <meta> tag to content attribute.
• Reassign headings so that h1, h2, h3 appear in order.

Download:

wp-mobile-validation.patch

The patch should be applied to the wp-mobile folder that you place in your themes folder.

Update: This has been completely superseded by more recent versions of the plug-in, which use Carrington Mobile instead.

Bunny’s Technorati Tags and WordPress 2.0

Solved! To make Bunny’s Technorati Tags fully compatible with WordPress 2.0 you need to change two lines in the add_tags_textinput() function.

Just replace this:

function add_tags_textinput() {
	global $postdata;
	$tags = get_post_meta($postdata->ID, 'tags', true);

with this:

function add_tags_textinput() {
	global $post_ID;
	$tags = get_post_meta($post_ID, 'tags', true);

The problem is that it will show existing tags, or let you add a new tag, but it will lose tags when you edit a post. It’s not able to retrieve the tags to fill in the form field, apparently because $postdata isn’t returning the ID it expects.

I’ve submitted the fix to wp-plugins.org, so if the author is keeping track of tickets there, the fix should show up in the next version of the plugin.

Update Jan. 3: The plugin author has released version 0.5 with a slightly different fix (plus a few other improvements), and it’s now compatible with WordPress 2.0.

Accidental Blogspam

I just got a complaint about the latest comment on Another One Bites the Dust. Apparently the previous commenter (who checked the “Subscribe to comments” box) either entered someone else’s email address or forgot visiting the site. It’s a name123@example.com-style address, so it could easily have been a typo.

Either way, the new comment notice went out, and the recipient sent me a spam complaint. I apologized and removed him from the update list, but it moves “accidental spam” from a theoretical risk to an observed problem. I’ve disabled the subscription plugin until I have a chance to figure this out.

The good news is that Subscribe to Comments 2.0 is out now, so I should be able to upgrade when I get a chance. The bad news is that it doesn’t seem to have added a confirmation step, meaning it’s still (effectively) opt-out. Sure, you have to opt-in to get it in the first place…but the fact is that anyone can opt you in just by giving your email address instead of their own.

Open Letter to WordPress Plugin Authors

Please, when developing your plugins, be sure to always use the full opening tag for PHP:

<?php code goes here ?>

On some servers—maybe even your own—you can shorten this to just the opening <?. The following line in php.ini will disable this “feature,” and many web server administrators do so to simplify things like generating XML with PHP:

short_open_tag = Off

When this option is set, PHP will ignore <? and assume it’s simply part of the template… along with all the code following it. If you’re lucky, it means a bunch of PHP code gets sent to the web browser. If you’re not lucky, it results in invalid syntax, and PHP grinds to a halt, spitting out a blank page and a PHP Parse Error.

So please make sure you always use the full opening tag so that your plugin will be compatible with everyone’s system. If you run your own server, set that option in php.ini so that if you miss one, you can catch it before you post it.