Integrating with MultiSite Global Tables Mode
We’re continuing our series of tutorials for our custom add-on called “Styles” by taking a few more steps to make sure it is fully integrated with the MultiSite Global Tables mode in Events Manager. We had previously added a custom conditional placeholder for styles.
MultiSite allows WordPress administrators to create separate blogs within their WP installation. MultiSite Global Tables Mode (we’ll call it global tables for the rest of this tutorial) is a special Events Manager feature which allows you to publish events on different blogs in that network, but display and search them on other blogs.
In many cases, your implementation will automatically work with this mode, however in our tutorial there’s a few extra steps we need to take, and we’ll take the opportunity to highlight the nuances you should be aware of when creating an add-on that you’d like to work with global tables.
Current status of our add-on
Up until this point, our add-on would ‘sort of’ work on global tables mode. Our ‘style’ shortcode attribute would be registered properly, it’d add the right conditions to search our database tables as well as adding the search form field on every blog.
The main issue would be with how styles are stored. Currently, styles are stored on a per-blog basis, meaning you could create a set of styles on your main blog, and another blog admin could add a whole different set of styles on your other blogs. The problem here is that if you’re trying to do something like this:
[events_list blog=”1,2,3,4″ style=”1″]
The style ID 1 will represent different styles on each blog, so your search results will be incorrect. What we want to do here, is make sure that styles are controlled from a central location, so that ‘Super Style’ with ID 1 will be the same on all blogs of the network.
Creating global options
Since we’re storing our styles in the wp_options table (which we wouldn’t recommend doing for an add-on like this, we’re just demonstrating the possibilities), every blog has its own options table and therefore grabs style information from there. What we want to do is make sure that option name is stored somewhere that all blogs will access, and this is pretty easily achieved by adding the following snippet of code:
add_filter('em_ms_globals', 'my_em_styles_ms_globals', 10, 1);
function my_em_styles_ms_globals( $globals ){
if( EM_MS_GLOBAL ) $globals[] = 'my_em_styles';
return $globals;
}
What happens here is we’re hooking into the filter, which allows us to declare certain fields usually stored in the wp_options table on the wp_sitemeta table instead, which is essentially an options table for your network when running multisite. Events Manager does this for various options when in multisite mode that are shared at a network level, such as email settings, and allows you to add your own.
On line 3, we check if we’re in global tables mode by checking the EM_MS_GLOBAL constant which will either be true or false, and if so, we add our my_em_styles option. We do this since we only want styles to be available globally with global tables enabled, and not just multisite in general.
Note that if in multisite but not in global tables mode, EM_MS_GLOBAL will be false as well, you can check if multisite is enabled with the WP is_multisite() function, or test for multisite without global tables like so:
if( is_multisite() && !EM_MS_GLOBAL )
Restricting admin menus to main blog
The second thing we’ll want to do is restrict the styles admin menu to just the main blog. In our first step of this tutorial, we created admin pages to add/edit styles we could then assign to events. At this point, if an admin edits a style on one blog, it’ll be edited on all blogs. Since many multisite setups usually have different admins for different blogs, we’ll limit the ability to add styles only to the main blog, by tweaking the code we originally added so it becomes:
function my_em_styles_submenu () {
if( !EM_MS_GLOBAL || is_main_site() ) {
$plugin_page = add_submenu_page('edit.php?post_type='.EM_POST_TYPE_EVENT, 'Event Styles', 'Styles', 'edit_events', "events-manager-styles", 'my_em_admin_styles_page');
}
}
add_action('admin_menu','my_em_styles_submenu', 20);
What we did here is wrap the function that adds our submenu page in an if statement that will run that function if either we’re not in global tables mode, or we’re on the main site of the network. By doing this only the main blog admin can add or edit styles, and admins of other blogs can add those styles to their events.
Further considerations
Whilst we’ve mentioned about how inefficient storing styles in the wp_options table, it has allowed us to demonstrate how you can declare global options that are shared across a network.
A more ‘elegant’ approach would have been to store this data in the wp_em_meta table. By doing this and using the EM_META_TABLE php constant to refer to that table (which we recommend in any situation), all data would have been stored on the global table automatically. Any custom EM data you’d want to be persistent across your network can be stored there, and then you wouldn’t have had to worry about global options in that case when accessing that data.
You would, however, have had to decide about whether to restrict your styles admin page to the main blog.
Next Steps…
We now have a fully functional, multisite-ready, add-on! We’re entering the final chapter of our styles tutorial which will create some special pages based off our events page which will allow us to display a list of styles and a page for each style showing all of its associated events.
