Sugar Calendar Pro is unusual among WordPress event plugins: rather than leaning on the post type, it writes events to its own sc_events table, and the Pro ticketing addon stores ticket sales in sc_event_tickets. The native list view is sorted and paginated by event, which is fine for low volume, but the related sold and remaining counts live on different rows entirely.

SleekView reads sc_events as the primary table and joins sc_event_tickets on the event ID so each event row carries its ticket count, capacity utilisation, and revenue inline. Custom event fields stored against the Sugar Calendar event ID join in the same way, and the recurrence pattern in recurrence appears as a column.

The result is the planning view a Sugar Calendar coordinator with paid tickets actually needs: filter to upcoming events with sold tickets, sort by capacity utilisation to spot the events trending toward sold out, edit start times or status inline when a venue changes. Saved views split the work between the event team, the ticketing operator, and finance without anyone learning the underlying table layout.

Sugar Calendar Pro is well-architected for an event plugin that owns its data: sc_events and sc_event_tickets are real tables and the plugin treats them as relational rather than flattening everything into wp_postmeta. The cost of that architecture is that the default admin is built around per-event drilldown, because rendering joins in WP_List_Tables is painful. Once a team is running paid events with capacity to manage, the missing column is always capacity utilisation: sold over capacity is the number that decides whether to push another newsletter, whether to add a session, whether to stop accepting bookings.

That number lives in the join between sc_events and sc_event_tickets, and the work of computing it per event is exactly the work the default admin makes the coordinator do by hand. Treating the join as a first-class view turns capacity into a column, almost-full status into a saved view, and the weekly capacity review into a sort rather than a multi-tab session. The data has always been there; what changes is whether the team has to assemble it themselves every week.