Organizers: Use Custom Post Type to be future proof.

[Menrath]

• The user-role could and maybe should still exist in the future.
• And creating a "linked" Organizer from a WordPress user should be possible (other links might also come, e.g. Other Fediverse Actors).
• An Event may have multiple organizers.

[carstingaxion]

I would also use a post_type over a regular taxonomy for that, but add support for gatherpress-shadow-source, so an editor may select an organizer directly on the event. I’m planning to do it like that for a custom Theater Ensemble post_type.

While this is what I would do, I suggested another way for how GatherPress should do that in #872 (comment)

I thought about this kind of relation a user can have with an event very intens lately and have read the related issues here probably 10 times. (#3, #445, GatherPress/gatherpress-wp-org-integration#5)

I’d could be helpful to step back a little bit, to broaden the perspective from technical-only to technical-and-philosophical.

For the migration from the custom RSVP DB table to the comments table, we concluded that in WordPress an interaction of a human being with any data is called „comment“. We translated the human-readable „I take part in an event as attendee“ into a new comment with the comment_type of RSVP and assigned the „attending“ term to that comment.

Now let’s do the same (or similar) for speakers, organizers and maybe even sponsors.

If someone speaks, organizes or sponsors an event, it’ll be a comment on that event by the explicit user.

This makes sure:

• one user can have multiple roles per event
• one user can have different roles per each event
• A site owner can could open a „call for speakers“ with a simple (little modified) comment form (block)
• A request to speak/organize/sponsor (via the comment API internally) will be queued and can be approved automatically or manually (like comments)
• GatherPress can re-use most of the built-in stuff without reinventing new wheels, like numerous comment-blocks, spam-protection, template tags and endless hooks.

While this only touched the technical implementation, the UI for such a thing could be like described by @patriciabt with a user-select for each role.

User that are selected as site-wide organizers in the GatherPress settings, could/should be automatically assigned on event creation, means they will get an comment created in their name.

This is not meant to replace the need for explicit Roles & capabilities, but could be its foundation. Someone could earn the permission to edit an event, if this exact user has made a comment (with comment_type rsvp and term organizing), which got approved. Going this way would allow GatherPress to assign all or some of the special capabilities @javiercasares described in #445, without having to use explicit WordPress roles or custom capabilities, that a site owner might need to assign to somebody in the first hand. Those caps could be assigned dynamically based on the comment, using user_has_cap .

All of this should be nicely wrapped in a sense-making API, but under the hood, it’s just comments

[carstingaxion]

While working on #1114 in gatherpress-export-import:

The ONLY successful (means all relevant data) imports (so far) where made from TEC, which do also uses a post_type for their organizers.

[carstingaxion]

Gifted with GatherPress' great post type supports, I created a plugin to connect people to events — with individual roles & individual departments per relation.

Like suggested by @Menrath , this implementation uses a post type for the Organizer and gatherpress’ own shadow-source support to relate them to events.

GatherPress Relations registers a gatherpress_person post type and a relationship system that lets you assign people to any supporting post type with a specific role. A person can be a Speaker at one meetup, a Host at another, and a Moderator at a third — each connection carries its own role and department.

All functionality is gated behind two post_type_supports strings — nothing is hard-bound to any post type slug:

• gatherpress-relations-from — declares a consumer (the post type that carries _gatherpress_relations meta and tags itself with shadow terms).
• gatherpress-relations-to — declares a connectable source (the post type whose shadow taxonomy gets wired onto consumers).

https://github.com/carstingaxion/gatherpress-relations