People Add-on Now Available for Event Espresso 4

The Event Espresso People add-on creates an interface for managing staff, instructors, speakers, volunteers, sponsors, or just about any type of role someone might fill within an event and/or organization.

How does it work?

The People add-on creates a new interface within the Event Espresso 4 admin for managing people associated with an organization and/or event. People can be organized by type (eg. as staff (default), volunteer, speaker, sponsor, etc.) and categories.

Views and Post Types

People archive pages are automatically created using WordPress Custom Post Types, and can be easily added to a WordPress menu or customized by a designer/developer.

The default templates use your WordPress theme’s default archive.php file. Theme designers/developers should be able to create custom post type templates using the Event Espresso People Custom Post Types that are made available, once the add-on is installed and people are added to the system.

For example, this is a list of “Founders” (just a custom type I created earlier), that I can view by visiting the “founders” people type archive page (example: http://mywebsite.com/people-type/founders/):

This is a list of “Founders” profiles, as seen on a People archive page.

Screenshots

This shows an individual’s profile, type, and events he is assigned to.

This is the People manager, or People overview.

Multiple staff members can be assigned to a single event, or many different events.

The People display order can also be customized from within the event editor. Drag and drop ordering will be available in a future version.

Events templates automatically display the staff assigned to an event.

Your theme controls the style of the People listings within the event pages.

Dynamically list events a staff member is involved in on staff page. If a staff member is assigned to an event, each event is dynamically listed on their staff page.

Frequently Asked Questions

1. How are people related to WordPress users?
   In the initial iteration there will be no relationships between a person in the people post type and WordPress users. However, nothing we are planning in the initial iteration will prevent integrating a relationship in the future. Here’s some of the things we are considering for later iterations (again VERY early spec talk).
   • have some sort of mapping between people type and WordPress user roles.
   • ability to “link” a person to a wp-user
   • automate the above process or have manual interaction (tbd)
2. Is there a way to customize the relationship between people and events?
   Initially we are going to store role and order in the relationship table as for most use cases that will likely be sufficient.One thing we have built in EE is something called an Extra Meta table. This is basically a universal meta table for adding additional meta information attached to object representations. So we could easily use this to extend the saved meta for a people to event (or eventually people to venue) relationship.
3. What is the relationship between attendees and people?
   When our team first talked about doing a people custom post type early in EE4 development we had considered including attendees (referred to as “contacts” in the UI) as a potential people type. However we decided against this primarily because although much of the same information is shared, there are some unique relationships between not only attendees and events but also attendees and registrations (which in turn relate to transactions), and attendees and system questions (i.e. email, first name, last name) that really complicated things if we wanted the people post type to be really flexible and yet have certain inflexible components to it due to the attendee people type. So in the end we decided that attendees would be their own custom post type that helps to clearly delineate between contact records for attendees and people who function more on the event organization side of things. We recognize that there still will be some overlap. i.e. it’s usually the case where a “speaker” also attends an event. This is why at some point I think we’ll build in some relational connections between the people post type and the attendee post type, at least for an easier way to keep data in sync if necessary. It is our feeling that explicitly separating attendees from more generic people is the better way to go in this case after weighing all the options and nothing we have built yet contradicts that. So to be more specific:
   1. In the initial iteration people will never be tied to attendees.
   2. In the initial iteration attendees (contacts) will never have people records (but we *may* make that possible in later iterations)

Please post your questions below, we are eager to help.