I’ve been using EventCalendar3 for a couple of years. It’s a great plugin and version 3.1.4 still plays nice with WordPress 2.9.x. However, I was rolling out a new website with WordPress as CMS with a requirement for a Big Calendar. A couple of EC3 users had built big calendar capability into the development branch. The last beta version (EC3.2 beta 2) had big calendar functionality built in so I installed it. After I made the move to WordPress 2.9, everything seemed to be working fine until I realized my comments feed was returning a 404 all of a sudden. Comments on posts were feeding properly as were category based feeds and the site feed. So, I went through all the usual troubleshooting (check the wordpress.org forums and deactivate plugins). Turns out EC3.2 beta 2 was the culprit. When I deactivated it, my comments feed started working again.
I’ve spent a fair share of time going through the EC3 code over the past couple of years and couldn’t figure out what EC3 and comments had to do with each other. EC3 does highjack some feeds and futz with canonical redirects but everything I saw in the code seemed benign. I commented out some of the redirect functions with no luck. On my other blog with E3.1.4, my comments feed was fine and the plugin is still solid despite its apparent abandonment. Odd. After a couple of hours of troubleshooting, I packed it in.
Fortunately, I hit gold on my first stop through the WordPress plugin repository with Kieran’s excellent calendar plugin. It’s a no nonsense big calendar with two useful template tags to generate lists of events. While similar to EC3 in that it uses a separate table to store event data, it differs in that you add the events using a backend form rather than the posting method EC3 uses. You can link the event on the calendar to a blog posting (or any other url) which is a nice touch as well. Kieran’s plugin also seems pretty bulletproof as WordPress evolves.
It’s sad when a plugin withers away but plugin authors are very special people who give without compensation (for the most part) and are swamped with support requests from all kinds of folks who should have RTFM. When or if EC3.1.4 finally breaks, there’s an alternative.
The WordPress 2.7 core has a setting to close comments for posts which exceed a user specified aging. Unfortunately, the core doesn’t differentiate between posts and pages. Since I need additional control, I use this wonderful plugin.
Given a choice, I would prefer if the plugin would filter the comment_status page when the post is called and change its value based on aging. This functionality would prevent having to send scheduled update queries to the posts table. I believe the core functionality works this way.
Update Feb 24, 2009 – I decided to have a go at making a theme function that would mimic the core’s behavior of closing the old posts on the fly without additional queries while preserving comments on pages. It was pretty simple. You have to remove the filter (‘the_posts’, ‘_close_comments_for_old_posts’ ), copy the
function _close_comments_for_old_posts from /wp-includes/comment.php, modify it to do an is_page() check, rename your new function and then add the new filter (‘the_posts,’your_function_name’) after you’ve defined it.
Ajay’s plugin will still allow you to keep specific posts open so there’s more functionality than what I need so my solution isn’t a replacement.
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.
via WordPress Plugin: Most Comments (+ Widget) | BRAND INFECTION
Alex committed the Event Calendar3 plugin svn to the WordPress plugins directory. A very good thing.
WordPress › Event Calendar 3 « WordPress Plugins
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.
Email Spam Protection » Blueberryware.
Despite my best intents, I wrote a 600 word post today. I rarely go that long so I clipped it with the more tag. Well, it’s obviously been a while because the next thing I saw was the horror of the entire feed showing up on a BuzzBoosted web site page. Come to find out that since WP 2.5, feeds don’t respect the more tag any longer.
As always with all things usability, Ozh to the rescue with his Better Feed plugin. Now when I tried some of the fancy footnoting and stuff in the plugin, BuzzBoost (Feedburner feature) demolished the CSS on the rest of the page. Turned the web page into an eye chart so I’m just using it to cut the feed off.
WordPress Plugin : Better Feed « planetOzh.
Quite a bit of the hits I get here have to do with the EventCalendar3 plugin and getting it to work with WordPress 2.5. It’s really not that tough to make the small changes. I go over to the EC3 mailing list to see what kinds of problems people have with the plugin. Many folks are looking for functionality the plugin just doesn’t have. More people have problems that I don’t experience with my installation so I usually check out their blog to see if I can help.
I am always amazed how many people are running outdated versions of the plugin. Yesterday, I read a couple of support requests. They were running WordPress 2.3.x or 2.5 and EC3 version 3.1.0! I’m surprised EC3 ran at all.
The current version of the plugin is 3.1.1. RC3. Even though the it’s a ‘release candidate’, it works very well with pre-WordPress 2.5 installations. So if you find your way here looking for help with EventCalendar 3, take these simple steps:
- Make sure you are running the most recent version of the plugin.
- Go to the SourceForge bug/patch directory for EC3 and grab what you need to make it work with WordPress 2.5.