So far I’ve not had many error or bug reports for the Vent system, hopefully that is because it is simple to use rather than people just giving up and uninstalling it. A few questions have come up, however so I thought I would take five minutes to clarify one or two things.
Can a post be both a post and an event?
Once a post is identified as an event it is taken out of the normal blog hierarchy as
it’s status is changed from “post” to “event” and thus isn’t picked up by the
standard WordPress Loop query that is used to populate the blog. So a post can not be
an Event AND a Post at the same time.
Do I need to enter an end date?
You don’t need to enter an end date for the system to work. It is only “really”
required if you want to ensure that the generated hCalendar microformats are correct
for people who are going to export the event to a calendar application. An event
without an end date will still export but will default (depending on the calendar
application) to a 30 minute event.
Why does the system default to being disabled after I’ve activated it?
The Vent system starts in a disabled state for two reasons. Firstly, when it is first activated it doesn’t know what criteria you want to use to identify an event. If it was enabled from the start then it would mark ALL future posts as events from that point onwards.
Secondly, the Vent plugin is designed to also run in WordPress MU as well as the standard WordPress. In WordPress MU ALL plugins are activated by default. So if a user doesn’t want to use the Vent system they can disable it from within the settings page (WordPress MU users don’t have access to the plugins page).
Only when in an enabled state does the Vent system “Hook” into WordPress and start checking posts. So a disabled Vent system should have little to no processing overhead on a blog (or multiple blogs in WordPress MU’s case).
Tags:
development,
vent,
wordpress,
wordpress mu 
