A call for feature requests/ideas

[jaredatch]

In the near future I'm going to working on a large project that will likely use this plugin as a base for the events system and it will be rather extensive.

If you have any feature requests or ideas (well, practical ones) please post them. When I start this project I'm going to try rolling in some new features where possible.

cc @jb510 and anyone else who uses this :)

[joshuadavidnelson]

I'd love to unify the events and recurring events post types. I did a version of this plugin with the When recursion library for some more advanced recurrence options, but it was still based on a separate CPT and the separate edit screen.

It'd be nice to have recurring options as a metabox option for any event, with the option to edit the full series, future events, and only the current event (similar to Google Calendar), using a similar recurrence library to achieve the more advanced recurrence options (and setup rrules for ical).

[cliffordp]

For a project I'm working on, I specifically want all events to NOT be allowed to be recurring... so please make sure it stays able to be disabled.

But I agree the best UX is more along the GCal way of doing it instead of a separate post type. Also note that if you create a recurring event today that recurs every day, then tomorrow you change tomorrow's event, it prompts you, "change all events or just this one". If just the one, then it must do something to disassociate it from the recurring pattern.

Just a heads up is all.

[joshuadavidnelson]

I agree entirely.

I added the ability to remove an event form a series on a recent project (the same one I mentioned above), I've put the functionality into a gist, though I can't recall if I tested that gist separately, so use with caution. The concept is solid, though - I think editing "just this event" would remove it from the series entirely.

The trick is updating all future events in a series from any specific event, and how that changes things. Perhaps recurring events are managed via meta values, with a meta key for 'series_id' that would be regenerated (for that event and regenerated future events) when you choose "update future events".

[billerickson]

Recurring event functionality still needs to be opt-in (currently done with add_theme_support() ). The majority of event calendars I build don't need recurring events. Having the options there will just complicate the interface.

But yes, I'd like to see it all done in a single post type. We could use a meta_key to keep track, or simply set the post_parent of all the events to the first one in the series.

[joshuadavidnelson]

I'm working a project in the near future where I'll be using recurring events, I'll fork and attempt to get a single post type solution (and maintain the add_theme_support for recurring). I'll submit a PR once I have a workable solution.

[joshuadavidnelson]

The last project I used events on I created event detail checks and corresponding admin notices - if the event start/end dates weren't valid, or the recurring options didn't work: it wouldn't save the meta, forced the event to draft status, and provided an admin notice to that let the user know why. Any interest in adding that feature?

[jaredatch]

Definitely, it sounds useful. Other alternative would just be to add jquery validation. @billerickson ?

[joshuadavidnelson]

My thought was this method would work out-of-the-box with any metabox tool, and/or as a fallback to a jQuery validation.