Comments working again

So in my zeal to get our new theme launched, I failed to remember to update some code on the comments page that is in place to keep us spam free.  The end result of this was that Yawasp, our anti-spam plugin, was identifying every comment as spam and rejecting them outright. Anyone that tried to post a comment over the last few days, I apologize profusely and encourage you to come back and post it now.

Special thanks to Ivo Jansch for taking the time to contact us and report the problem!

Posted in: Announcements

Cause of the WordPress bug identified

Previously, we discussed a WordPress bug and our temporary workaround for it. I am glad to say that we have identified the root of the problem and have been able to come up with a better solution. Apparently WordPress’ auto-save function is not a fan of a character set of anything other than UTF-8. We had changed it through the administration interface via Settings -> Reading to be ISO-8859-1. When we changed it back, it seems that posting works happily again without the truncating issue that was happening before.

This would seem like a fairly large problem and I am very surprised that it hasn’t been identified and resolved before now. After we tracked down the cause of the problem, I ran a quick search and was able to turn up this topic covering the same problem on an older version of WordPress. Seeing that this problem existed in at least version 2.3.2, I can’t fathom why it didn’t make the cut for things to fix for the 2.5 release.

At any rate, I sincerely hope that this is something that is addressed in the very near future so that we can switch back to the ISO character set.

Posted in: Rants

A workaround to the WordPress 2.5.1 bug

Recently we upgraded our blog to WordPress 2.5.1 and have been battling a horrible bug ever since. When we save or edit a post most of our content is sometimes lost. Unfortunately, it isn’t occurring with enough frequency for us to track down the specific cause of the problem and we have enough projects lined up over here to keep us from digging through the WordPress code ourselves to solve it in any reasonable time. So we’ve opened up a ticket in WordPress’ bug tracker that outlines the problem in more detail and continue to wait for a response from someone on the dev team to let us know what might be the culprit.

In the meantime, the fear of not knowing if your post would be lost when saved forced us to saving the content to notepad before publishing. This is a less than useful solution to the problem because even doing this it seems that once a post starts truncating itself upon saving, it continues to do it every time. The only solution is to delete it and start anew. [We're noticing the problem crops up most often when another user edits an entry not their own. It truncates the post arbitrarily and then proceeds to reject contributions to that post past the truncated length. Needless to say, the frequency and creativity of expletives uttered in the office has spiked dramatically.—Ed]

So today, I took some time to hunt down remote posting solutions that allowed us to save our posts without needing to log in to WordPress directly. ScribeFire was the first solution I tried and has turned out to be an incredibly useful tool. ScribeFire is a FireFox extension that allows us to create posts directly in FireFox and saves them to our blog via the WordPress API.

There is still some functionality lacking: the ability to change post author, adding excerpts and making use of some of the plugins that modified our post entry page to name a few. But we see their release schedule to be rather efficient and hope to request some features that make it into the next release (or until WordPress identifies the problem that forced us to this solution in the first place). [It should also be noted that the extension on the whole is rather impressive considering that it's blog-engine agnostic and works for many different providers.Ed]

Posted in: Rants