Custom 'meta' on occurrences

[Andrew Shankie]

Hi Stephen and EO fans (of which I am of course one),

I’ve got a problem that’s going to make our collective heads spin. I think I’ve got a solution, but I just want to run it by you to see if it makes sense.

The Requirement

My client, a night club, wants to use EO as the single tool to manage all their ticket sales – including sales not made through EO (i.e. through third-party event promoters). The client needs to be able to add one or many promoters to a particular event and track Tickets Available and Tickets Sold for each of those events.

The Partial Solution

For single events, I’ve come up with a tidy solution. I’ve used ACF to add a repeater field called ‘promoter’ that allows the client, for each event, to select a promoter (who is a WP user), the tickets allocated to that promoter and their tickets sold.

I’ve then built a ‘sales’ report that shows a view of all ticket sales for events in a given month where the Tickets Sold field updates the ACF post meta on an event via an AJAX call. Promoters, as users, can also log in and just see only their events (and update the sold counts like admins).

The Complication

Above, you’ll spot in yellow the problem with this solution. The client has recurring club nights, so the sales report correctly lists individual occurrences, but tracks sales against their parent event (which contains the post meta that I’ve added). Occurrences in EO aren’t posts, so I can’t add post meta to them (as I’ve done using ACF). D’oh!

The Proposed Solution

Because EO occurrences aren’t posts, I can’t really figure out a way to use normal WP post meta against an occurrence (if anyone can though, please feel free to post here).

What I’m proposing doing is setting up the Outlet and Tickets Available using the post meta on Event (as per above).

Then, I’ll create a new post type called something like occurrence_sales. I’ll hook into eventorganiser_save_event to create a new post of occurrence_sales for each occurrence created on eventorganiser_save_event (though feel free to tell me if there’s a better hook – I haven’t tested this yet). This post type will have custom meta, including the occurrence_id as well as ACF repeater that has Outlet and Ticket Sales.

Then, when I run my sales report, I can query the occurrence_sales post type for all posts that match the occurrence ID in the current line. That of course means a lot of DB queries, but performance here isn’t paramount as it’s an admin system.

Can anyone (probably Stephen!) think of a better solution? Or any major pitfalls with this one?

[Andrew Shankie]

The other option that @theheat suggested to me was, rather than creating a separate post type, to just create a bit of meta on the parent event for each event-occurrence combination.

For instance, if we had an event with two occurrences (occurrence IDs 7, 8) and two promoters (WP users, IDs 34 and 35), we would end up with post meta something like:

array( // Not actually an array, but useful just for us to understand,
       // where the last _1 is the first row in the repeater
 eventoccurrencepromoterid_7_1 => 34,
 eventoccurrenceavailable_7_1 => 500,
 eventoccurrencesales_7_1 => 300,
 eventoccurrencepromoterid_7_2 => 35,
 eventoccurrenceavailable_7_2 => 100,
 eventoccurrencesales_7_2 => 80,
 eventoccurrencepromoterid_8_2 => 35,
 eventoccurrenceavailable_8_2 => 100,
 eventoccurrencesales_8_2 => 80,
 eventoccurrencepromoterid_8_2 => 35,
 eventoccurrenceavailable_8_2 => 100,
 eventoccurrencesales_8_2 => 80,
);

Looks a bit clunky, but in a way, could be tidier.

Thoughts on which of the two options is better? Or do something altogether different?

[Stephen Harris]

Hi Andrew,

I think the second suggestion is just as tidy as the first, and avoids superfluous records in the wp_posts table.

I can’t see your screenshots (Google 403 error) so I’m not sure how you’re handling the UI for multiple dates (or indeed linking a promoter to an occurrence).

One thing to be cautious of is when an event date is added/removed – as that will delete/add dates. If you’re editing an event to move a date, the occurrence ID will change, and the link to the post meta would be broken. (When you save an event Event Organiser compares dates in the database with the ones intended for the event and delete/add occurrences form the database as appropriate).

One way to get round this is to enable dragging of occurrences in the admin calendar, as then you can move an occurrence while retaining its ID by simply dragging it to the new date / time.

I think eventorganiser_save_event is probably the correct hook to use. Though if you’re saving data from the event admin screen you might want to first verify that the appropriate data should be there. The hook is fired when an event is updated/created – not necessarily when it is updated/created from the event admin screen (e.g. events created from the admin calendar).

[Andrew Shankie]

Hi Stephen,

Thanks!

Not sure why Google all of a sudden decided to 403 those images. Here they are:

ACF repeater on event:

Sales report:

Thanks as always, Stephen, for your really helpful advice. It does sound like the second approach will be the one. I don’t think that my client will be adding/deleting occurrences often – and I can instruct them to either drag occurrences (as you suggest) or completely remove the event and create a new one.

To double-check my understanding of your last paragraph re: using eventorganiser_save_event – you’re saying that the hook is fired both on saving/updating the event using the event admin screen (good) but also when creating/updating using the admin calendar (possibly bad). So I’ll just need to train the client not to use the admin calendar to create/edit events (or make sure that my action detects where the request is coming from and acts appropriately).

[Stephen Harris]

My comment regarding eventorganiser_save_event was just that it’s not tied to the admin screen context. So if what you want to do is tied to a particular context (in this case the event admin screen) then you should check that you are in that context before doing anything. I think the most foolproof way is inspecting $_POST – if the data you expect/want to be there isn’t, just ignore it and do nothing.

[Andrew Shankie]

That makes sense!

Perfect, thanks. I’ll get coding it up next week and let you know how I get on. I’ll give you a preview of the work then it’s done – I think there might be the basis of an add-in for ‘external sales channels’ or something.

[Stephen Harris]

Please do, sounds interesting!

[Author]

Posts