Version 3.6 of amr-events is available for download.
It should be used with the free listing part: amr-ical-events-list version 4.30. Several improvements have been made in the way that event meta data, taxonomies etc were being retrieved. This has reduced the database queries made when producing an event list from events in wordpress.
If you have a fairly recent version, and your access to the automated updates from icalevents is still current, then it should appear in the normal wordpress plugin updates.
From version 3.3 on wards, amr-events now has three optional additional roles:
If you wish to keep your event creation separate from your post creation, these may be useful. If you are updating the plugin, you may find that you need to force an update of the various roles (even existing admin may need capabilties manually added). So while one hopes not, just in case: use a role manager like https://wordpress.org/plugins/members/
Are you you getting the browser messages when saving a new custom post type draft?
Firefox: “This page is asking you to confirm that you want to leave – data you have entered may not be saved.”
Internet Explorer: “Are you sure you want to leave this page”
Chrome: “The changes you have made will be lost if you navigate away from this page”
“Leave page or Stay on page” when you click save draft on a new custom post type?
You opt to leave and the post was still saved but the custom fields etc do not save. BUT then you CAN edit the post and then add in the custom fields / meta box without any further problem (what the?)
And of course admin’s have no problem!
If you are allowing your custom post type to be assigned categories and tag taxonomies like normal posts, then ANY role that is required to be able to create the custom post type while default taxonomies are supported, must also have ‘edit_posts’ capability. (Unless you have code to change the default taxonomies, but then you will be messing with the standard posts capabilities)
Arguably the wordpress default capability ‘assign_terms’ should not be mapped by default to ‘edit_posts’ as this is what is making life complicated. Possibly a contributor should have ‘assign_terms’ capability directly? Or one might say that it’s the sharing of taxonomies that is causing the complication.
I wanted a role that could create events but NOT also create posts. Similarly with editors.
Custom roles can be setup to manage custom post types (in this case events) and one can isolate these capabilities. However when one adds taxonomies (default and custom) into the mix, things get more interesting.
Default taxonomy capabilities for categories and tags
While one could overwrite these capabilities with say ‘assign_terms’=>’assign_terms’, then one would not be able to assign categories and tags to standard post types without also ensuring that the default roles were assigned the capability ‘assign_terms’. All achievable, it just seems wrong to have to mess with standard wp and risk breaking other plugins.
Registering custom taxonomy means that in this case ‘edit_events’ capability is enough to be able to assign this custom taxonomy to this single custom post type
'capabilities' => array (
'assign_terms' => 'edit_events' // strictly speaking need one for each new posttype ?
TIP: while you are testing this all out, a role manager plugin like Justin Tadlock’s members plugin is very helpful. Roles and their capabilities are saved in the database and unless you ‘remove’ the role and add it again, the capabilties will not update as you might want them to.
I was actually trying to create a custom role that can assign categories, tags and custom taxonomies to your custom post type. If you give these roles ‘manage_categories’, they’ll be able to add new categories BUT still not assign a post to existing categories. They have to have ‘edit_posts’ or obe has to override the default wp setup.
See the pluggable files in each plugin folder. Use the function there as a base for your new function. Add your function to your custom themes function.php or to your own site specific snippets plugin.
Events can be grouped by date formats or by categories, tags or custom taxonomies.
Events can be grouped by days, weeks, months and some funkier options that no one will probably ever use, but I liked the challenge! Actually I imagined one could do some seasonal styling perhaps? each grouping has it’s own css classes, and date/time format
Grouping also allows one to do timetables (grouped by day), weekly schedules, or monthly, quarterly or seasonal event views.
Some folks have been using the free version of this plugin for several years. Some of them have recurring events with modified instances. Sometimes the frequency of modifications is high. In the last few months this has caused a fair bit of extra support required as anomalies crop up. Sometimes bugs are flushed out and sometimes almost unanswerable questions are raised as to what the plugin should do if it gets weird data.
The point of this post is to highlight some of the complexities that may develop and urge you to keep your ics files as clean as possible or use amr-events where it is possible to delete old events (hard to delete volumes of old events in google calendar).
An example is modifications to recurring rules or rdates and modifications to instances of those recurring rules (themselves already a modification.)
For example:Assume we have a recurring event. It starts with a SEQUENCE: 0
This generates an infinite set of mondays, including the following
Now, one of the instances gets modified. (This could be just the description or the actual date.) A RECURRENCE-ID VEVENT is created for each instance modification and the SEQUENCE NO is updated. The recurrence-id matches the date in the recurring rule that it applies to. The combination of UID, RECURRENCE-ID and SEQUENCE helps us identify the instance that is being updated.
For a given pair of "UID" and "SEQUENCE" property values,
the "RECURRENCE-ID" value for a recurrence instance is fixed.
DTSTART;VALUE=DATE:20140721 (ie no date change in this example)
Now assume the original RRULE is modified too, perhaps just the description or shock horror, the recurring date definition? It’s sequence-no is updated too BUT now what should happen to the RECURRENCE-ID instance? Should it be updated to indicate it is still valid? IE we now have:
generated date 21 July 2014 with UID and SEQUENCE = 3 and
RECURRENCE-ID;VALUE=DATE:20140721 with matching UID and SEQUENCE = 3
It appears that perhaps SEQUENCE numbers can increment separately, so one could conceivably receive a file with a RRULE with an equal to or greater sequence number than a RECURRENCE-ID. From this discussion, it is really not clear what the supplying calendar application will do:
Once UID 1/SEQUENCE 0 hits UID 1/SEQUENCE 1 (which would
mean something significant about the set of instances
has changed) all bets are off in regards to RECURRENCE-ID
values that previously existed.
If the UID/RECURRENCE-ID/SEQUENCE matches a generated date from the rrule with same SEQUENCE (ie both have been modified), then what? One cannot just use eg: LAST-MODIFIED:20140620T200327Z. Who is to say that a mod of the RRULE was intended to overwrite the RECURRENCE instance? Quite possibly not.
What does the plugin do:
For now (until further authoritative input to the contrary), the plugin will assume that a recurring instance (RECURRENCE-ID) in the file is intended to be still there. It will include the highest sequence number of the recurrence (even if the originating rrule is not there -an error in supplying application). Similarly it will include the recurrence even if the rrule does not have a matching date.
It will also assume that the recurrence instance overwrites the RRULE definition even if the RRULE has a later SEQUENCE number. The Plugin does not have to worry about the complications of syncing for now.
If you are ever struggling to figure out what the plugin has done. Create a test list and include the RECURRENCE-ID and SEQUENCE fields. You can reference the test lits by adding ?listtype=x to your events page url.
Some lengthy related discussions here and in other parts of the thread:
Complications that urge one to keep events as simple as possible:
Searching the web seems to indicate some folks believe RECURRENCE-IDS should not change. So should we assume that if the RECURRENCE-ID vevent is still in the file then it is still valid and should be included. (What does this mean for syncing and deletions? IE How does one ‘delete’ an existing event. Or should one always delete events from an ics file and reload ONLY what’s in the ics file?)
There are a number of date and time options for you to choose when displaying your events. The main ones you should be using are created by the plugin and will be formatted by the date and time settings you have specified in the plugin settings (and applying any localisation that may be available in your wordpress setup). You can specify these by listtype, so say a widget could have a very compact date format and a full list may be more detailed.
Event date fields formatted by your date settings:
EventDate: Mon, June 23, 2014
EndDate: Mon, June 30, 2014 (only if event greater than one day)
Event time fields formatted by your time settings:
StartTime: 9:00 am
EndTime: 10:00 am
Note there may be situations where there is no end time or no end date (eg: if there is no duration or the end date is the same as the start date. If a field has not been populated, it will not be displayed and neither will any ‘before’ or ‘after’ text.
Field from the ics specification that may be useful.
Formatted using human language function
DURATION:1 week , 1 hour
Other date fields in the ‘edit events’ admin screen
The ‘last’ date shown in the edit events admin screen shows the last recurrence date of an event. It is used to select events within a date range (ie exclude events whose recurrences are in the past, without having to rebuild the recurrence logic). It is also used to sort events in the admin screen by this last recurrence. It is therefore formatted yyyymmdd for the sorting. It is not intended to be displayed elsewhere.
These are direct from the ics specification formatted by the DateTime settings in the plugin settings. Note the DTEND has a special definition in the ics specification for all day events (it will have the next day as the end date) and may be confusing to normal users. Some ics generators get the DTEND logic wrong, so this plugin tries to work with duration just in case.
DTEND: Mon, June 30, 2014 10:00 am
DTSTART: Mon, June 23, 2014 9:00 am
As these are very technical, precise fields, they are by default not formatted but left as found.
the date and time that the instance of the iCalendar object was created.
the date and time last modified – works with the sequence number to determine the latest modification to an event instance.
Some theme language files can be found at http://i18n.svn.wordpress.org/ . You may have to click down various paths as sometimes somelanguages are stored differently.
Danish example: http://i18n.svn.wordpress.org/da_DK/trunk/messages/twentythirteen/
Updated plugin language files
Some folks have kindly provided translations. You can see the latest available here. These are not always up to date. See translation tools below. If you need to update your language files, please send me the update and I’ll upload it.
If you do NOT send an update, your version may be overwritten in a plugin update unless you move it.
Custom Language File Location
For these two plugins, you can store your custom .mo and .po files in your WP-CONTENT languages subfolder.
Do not use the subfolder /plugins as wordpresss may one day be auto loading translations to that folder.
Simple ‘flat’ events can be imported from a csv file. This is possible with a third party csv import plugins. The amr-events plugin attempts to use the wordpress meta data as simply as possible to facilitate this kind of easy integration with other plugins.
Events can be complicated: they can recur, be in different timezones, have exceptions to their recurring definition, have alterations to some instances etc. These ‘complications’ cannot so easily be imported.
From a brief review of the csv import plugins out there, starting with the self named “ultimate csv importer” and backing away in disappointment, I read reviews of a few others and decided to try the really simple importer. It worked so nicely and cleanly that I stopped there!
What a pleasure to see a plugin that
inserts itself sensibly into wordpress, adding itself under tools > import just where it should be
imports the data with limited fuss, very sensibly using the column headings, making sensible defaults for missing fields instead of insisting that they are mandatory data. eg: choose to include a post_status, or let it default to draft and ‘publish’ it later.
handles custom fields and custom post types as easily as they should be handled – why should there be a ‘fuss’
So how to import events?
I suggest you create yourself a test event or two that are similar to the event data that you wish to import. This is so that you can see the meta data that is created. The amr events plugin tries to stay close to the ICS RFC spec formats for the data, but is sophisticated enough to cope with a reasonable set of date formats and will work with minimal event data input. Sample files provided below. The plugin needs
some of the standard wordpress post data, as little as your chosen csv importer will cope with.
post_type = event (or whatever you have in your settings, or load as post and change afterwards if your csv importer is a bit ‘dumb’.)
a minimal set of event meta data (see example file for variations):
_DTSTART in RFC format eg: 20140402T090000 or 20140402
_DTEND (to define any timed events or events of greater than 1 day. NOTE RFC 5545 says _DTEND ends on NEXT day for one day events – be careful what you define and test it!)
_timezone (if timezone differs from UTC or your website timezone – careful testing with your setup)
_allday (timed or allday)
see your sample events post-meta in phpmyadmin for more possibilities.
It is probably not practical to try CSV importing recurring _RRULE data or detailed duration data (use DTEND rather)
If you experience any problems, please consider carefully whether it is a problem with your chosen CSV importer and if so, log your support query there.
If some data goes in a bit wonky – maybe you set it up a bit wrong, the amr-events plugin does try to correct things – update the post and save.