Minor Plugin Updates

I just tagged new versions of the http-authentication and ical-events plugins:

The releases include updated readme files for the really slick WordPress plugin directory that was released today.

The ical-events plugin also contains a minor fix for to avoid a case where a repeat was added after the RRULE end time.


Comment from Jeff Hopkins on

Hi Daniel!

Love your iCal events plugin.

I’m trying to get it to update multiple times daily…but can’t find the `ICAL_EVENTS_CACHE_LIFETIME` line in the plugin.

Could you tell me where it is…and maybe tell me how I might re-write it to check every few hours instead of once a day? Thanks!


Comment from dwc on


My apologies – I renamed the constant used to determine how long to cache but forgot to update the readme. The line you’re looking for is:

define('ICAL_EVENTS_CACHE_TTL', 24 * 60 * 60); // 1 day

To have it update every 4 hours, change it to:

define('ICAL_EVENTS_CACHE_TTL', 4 * 60 * 60);

I’ve updated the readme and released a new version to correct this. Thanks!

Comment from Jeff Hopkins on

Hey Daniel…sorry to bug you again.

My site is: http://www.jeff-hopkins.com. I’m using the plugin, and I’ve got a bunch of lines that look like this:
Unsupported iCal BYMONTHDAY value “BYMONTHDAY=1”
Unsupported iCal BYMONTHDAY value “BYMONTHDAY=22”
Unsupported iCal BYMONTHDAY value “BYMONTHDAY=4”

Before I see some events that seem to be posted the right way.

Ever seen anything like that? Looks like something in my iCal is weird…but I don’t know what.

Thanks in advance, I’m digging the plugin.


Comment from dwc on


Certain types of events are not supported by the plugin at this time. The parser doesn’t handle all recurrence rules (e.g. BYMONTHDAY), and I haven’t had a chance to add them.

For now, you can download 1.12 to hide those error messages from:


Be sure to grab all four files and replace the current ones you have.

Comment from Jeff Hopkins on

Thanks, that fixed it!

Really appreciate all the help.


Comment from Sam on

I am using http-authentication 1.7.

I have apache authentication protecting the whole site, so when a user sees any page, they have definitely authenticated against apache.

When a user first goes to my WordPress site, if they try to add a comment to an existing post, they get presented with the “Name / Mail / Website” fields above the comment. So at this point it does not seem that they are “logged in.”

If the user attempts to create a completely new post, when they get to the post creation screen they ARE automatically logged in. If they then go back at some point to put comments on any post, it now shows them as logged in.

So it seems like the users need to go somewhere in wp-admin to “trigger” being logged in, then they are fine throughout the site.

What can I do to get the user to be “logged in” to wordpress in the first place?

Is that clear?

Comment from Sam on

Just as a follow up to my last comment, I went and turned on the WordPress option:

Users must be registered and logged in to comment

Now when a user tries to add a comment (if they have not yet been into wp-admin) they get:

You must be logged in to post a comment.

If they click “logged in” in that message, it does log them in automatically.

I would prefer if the users were just automatically logged in in the first place and never saw that message.

Comment from dwc on


Give the Angsuman’s Authenticated plugin a try. It requires people to be logged in to see your blog. When used in conjunction with the http-authentication plugin, this should be transparent to users once they’re logged in to the external authentication mechanism.

There are a few other restriction plugins available in case you’re looking for more fine-grained control.

Comment from Sam on

That did the trick, thanks.