Improved performance in amr-events 3.6

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.

Event Roles and Capabilities

From version 3.3 on wards, amr-events now has three optional additional roles:

  • Event Contributor
  • Event Editor
  • Event Manager

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

Event Capabilities as seen in the members role plugin
Event Capabilities as seen in the members role plugin

Custom post types, taxonomies , capabilities, roles

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?
What happens when you do not have the right capability
What happens when you do not have the right capability
Leave or Stay message in chrome
Leave or Stay message in chrome

What happens?

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!


This appears to be because we have said that the custom post type supports the default taxonomies and possibly wordpress is trying to do something with javascript (maybe assign a default category to the custom post type) but the user is not allowed to.  However it also happens when the custom post type has tags but not categories?  But it does not happen if it just has the custom taxonomy (with the assign_terms or assign_terms=>edit_events capability).    The behaviour only occurs with default taxonomies.

Key finding:

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

$default_caps = array(
 'manage_terms' => 'manage_categories',
 'edit_terms'   => 'manage_categories',
 'delete_terms' => 'manage_categories',
 'assign_terms' => 'edit_posts',

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 (
 'manage_terms'=> 'manage_categories',
 'edit_terms'=> 'manage_categories',
 'delete_terms'=> 'manage_categories',
 '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.