Does the thought of creating css make you shake? It’s my least favorite part of development. As I brace to get my theme ready for WordPress 2.7, I am not looking forward to styling the new comments.php. Fortunately, Chris has done a lot of the heavy lifting (as well as providing an example) of what classes are used with the modified comments api. Great job!
What do you do when your WordPress theme isn’t supported anymore? As WordPress heads for version 2.7 and an overhaul of the comments loop, the theme I use doesn’t look like it will be updated in anticipation of the new version changes. I hope I’m wrong.
Anyway, I had a feeling this day would come so I have to be prepared to roll up my sleeves and work on comments.php to be able to leverage the new functions. Thanks to Otto’s tutorial, I don’t think the task will be too daunting.
I’ve already done a ton of tweaks and modifications to the theme so it works and presents the way I want it to. I don’t want to lose the ‘look and feel’ as well as the time I’ve invested in making the modifications so changing themes isn’t something I’m looking at right now.
It’s been a while since I added a plugin to my blog but this fits a need. I tweaked the plugin to return only posts from the current calendar year when duration is set to 365. Works better for my self hosted blog.
Alex committed the Event Calendar3 plugin svn to the WordPress plugins directory. A very good thing.
Changes include threaded and paged comments if your theme can support it. Here’s a great ‘how to’ for tweaking your theme to support the new features. Of course, you need to wait for WordPress 2.7 or grab the bleeding edge version from the trunk.
Sometimes commenters really want to leave their email address but don’t realize how easily it can be scraped. I’ve been kicking around implementing antispambot on my blog but thanks to the new shortcode API in WordPress, the folks over at Blueberryware came up with a neat implementation. I think it’s a work in progress but give it a try.
WordPress 2.6.x introduced a new feature I’ll call version history. Every time you edit a post after it’s been published, the previous version is saved and a new ID is generated in the wp-posts table. So if you are a horrible speller or punctuationist (?) like me, every little ‘post-publish’ change you make results in a new table entry. The current core doesn’t seem to have any built in functionality to use version history (at least none that I can find) but it’s ripe for plugins or future releases to exploit. You can see all the revisions way down at the bottom of the write/edit post page. Just don’t prowl around the wp_posts table unless you’ve got a strong stomach. It’s a mess in there.