The [event_embed] shortcode already understands a host of different parameters, but even so it can be useful at times to extend it with new parameters to cover special cases. In this short tutorial we look at the process for doing just that, based on a request by @tballiance to be able to include events that have been hidden from event listings.
Events can be hidden from event listings? Yes they can! In the event editor, the event options meta box provides a couple of options:
While we might sometimes want to force the inclusion of these hidden events, we probably don’t always want to do this. The best way forward, then, is to add a new shortcode parameter to make this optional.
Here’s what I’m envisioning – a new hidden parameter that can be used as follows:
There are essentially two parts to the solution:
- We need to hook into Event Rocket in order to listen out for and set things up when the new hidden parameter is set
- We also need to hook into The Events Calendar to modify the actual query
Luckily, both plugins ship with hooks a plenty:
- The eventrocket_embed_event_args filter hook will allow us to interface with the [event_embed] shortcode
- The tribe_events_pre_get_posts action hook provides a convenient way to change the actual query
Here is some basic code achieving this goal. It can be added to a theme’s functions.php file, as is often done, though a custom plugin or mu-plugin file may be a tidier way to go 🙂
What are we doing here? In the extend_event_embed_hidden_events() function we check to see if hidden=”include” is set. If it is, extend_event_embed_include_hidden() rolls into action.
Under the hood, The Events Calendar excludes the hidden events by setting a post__not_in query var – our second function tests to see if it has been populated and then wipes it if so.
Now, the thoughtful hacker may wonder: what if post__not_in was already set, independently of anything to do with hiding upcoming events? This is indeed a risk in a few (probably uncommon) special cases but it is certainly possible to introduce more logic to handle this sort of scenario (though it goes beyond the scope of this post to cover that).
- A “straightforward usage” in this case means you are not specifying start or end dates and have not specified specific event IDs/slugs
- Note also how we instantly unhook it – this is needed to avoid interfering in subsequent event queries
- Originally this was going to be a 2-part tut where we continued to look at improved handling of the post__not_in parameter, however in the end I think this is something best left to the individual developer so they can tailor things to meet the actual scenario in front of them