Build a Multi-Region Storefront with BigCommerce for WordPress 3.1.0+
Earlier this month, we released version 3.1.0 of BigCommerce for WordPress, but unless you’re looking closely, you might have missed some new functionality that’s a pretty big deal.
Version 3.1.0 introduced support for the ability to create and manage channel views within a single instance of WordPress and BigCommerce, which lays the foundation for developers to build multi-region, multi-experience ecommerce sites. In our latest release, version 3.2.0, we’ve added enhancements that streamline the process of working with products across multiple channels.
Multi is not an entirely new concept for BigCommerce for WordPress. In previous versions of the plugin, you could link a single BigCommerce store to multiple WordPress instances. In that configuration, each WordPress site represents a different channel. You could list different products and show a different front end experience on each channel site connected to the plugin.
The new multi-channel functionality takes that concept a step further.
Now, you don’t need to spin up a new WordPress instance for each channel — you can utilize multiple channels from within a single WordPress site. We’ve made it possible to manage which products are listed per channel in BigCommerce and the catalog variations between those channels from the WordPress admin, and we’ve built a lot of flexibility into the model in order to support a wide range of use cases.
In this post, we’ll demo some of the new plugin capabilities and provide an example to illustrate how you can set up a multi-region storefront with minimal code.
This is also a representation of what is possible with our public APIs today. If you are looking to implement your own custom storefront and it needs to support more than one region, you can apply the concepts here too.
Our Approach to Serving Multiple Regions
One of the key characteristics of a multi-channel architecture is that multiple user-facing experiences share a single backend. With BigCommerce for WordPress, and with other channel integrations built on BigCommerce, that single backend is BigCommerce, which is the source of truth for the catalog, orders, and customers.
A single product might be listed on several channels, and across those channels, the product details may vary. For example, a pair of sneakers that’s sold on a site serving the US region might have a different price and description than the pair that is sold on the French site. But despite those variations, there is a single product record for the pair of sneakers which is managed from the BigCommerce control panel. Similarly, orders placed on different channels all flow into a single admin view within BigCommerce, and each order is attributed back to its channel source. This allows you to maintain a central source of truth for managing your orders, while tracking sales performance across various channels. No need to jump around into different accounts!
Primary Use Cases
Let’s begin with a common multi-site use cases: multi-region. Businesses with a global footprint have the need to tailor product merchandising to the regions where they do business, which means translating product details into the local language and showing prices in the proper currency.
While you could serve multiple regions with separate sites, there are advantages to orchestrating multiple experience from a single site. Lower overhead and a streamlined workflow for managing site admin are a few major considerations. The BigCommerce for WordPress plugin consolidates multiple channels into a single product view, giving you the ability to filter products by channel and edit product details on a channel-specific basis.
That being said, the BigCommerce for WordPress multi-store functionality isn’t tied only to multi-region. You could potentially build multi-store experiences around a range of broader use cases including B2B scenarios like separate wholesale and retail sites or “vendor portals”, featuring a product catalog specific to each vendor.
The reason for this versatility is that multi-channel is controlled within the plugin using two hooks: one that activates the multi-channel functionality within the plugin and another that wraps the logic for changing channels. The important distinction is that we allow developers to define that logic themselves, which means that the trigger for changing channel views can be anything — the shopper’s geo IP, a customer attribute — any condition that you can detect.
Multi-region Implementation Examples
In this section we’ll dive into enabling multi-region storefronts. These two different examples are based on simple child plugins I put together, which trigger the channel view when a user’s region is France. The French channel includes product details that have been translated into the appropriate language and also switches the currency code and symbol to Euro.
Note: Both examples have a sample child plugin you can download as a starter at the bottom of this post.
First, Enable multi-channel
For both examples, the BigCommerce for WordPress multi-channel mode is enabled using this filter:
add_filter( ‘bigcommerce/channels/enable-multi-channel’, ‘__return_true’ );With the enable-multi-channel functionality activated, we can supply logic to change the channel view based on a condition that we define — like the user’s location. This filter also activates changes within the admin interface that allow users to manage channel listings.
A simple way to get the term id for a channel, which you’ll need later, is to hover over one of the ‘rename’, ‘make primary’ or ‘disconnect’ actions here to see the term id in the url.
Triggering a region via Geo IP lookup
A common requirement for multi-region implementations is automatically selecting the right region based on the shopper’s geo location. We’ll unlock this with help from the free GeoIP Detection plugin to detect the user’s location based on geo IP. By default, the plugin reaches out to an API for geolocation data, but you can also specify a database to pull location data from instead. I used the GeoLite2 City database, which you can enable during the GeoIP plugin setup.
The GeoIP Detection plugin supplies this function, which does a lookup of geo-location data for the current user:
geoip_detect2_get_info_from_current_ip()The child plugin I built uses this function to check the user’s location against the country code ‘FR’ if the GeoIP detect plugin is also installed (so there isn’t an error when the child plugin calls the function above).
The logic looks like this:
$userInfo = geoip_detect2_get_info_from_current_ip();if (function_exists('geoip_detect2_get_info_from_current_ip')) {
if ($userInfo->country->isoCode == 'FR') {
// Switch from primary channel (US in the demo) to FR channel
}
} else {
// Echo out warning that GeoIP detect plugin is not act
}
Change the channel view
Here’s where the multi magic happens. If the shopper’s location matches France, we trigger three changes:
1) we set the current channel to the one containing French product listings
2) change the currency code to ‘EUR’, and
3) switch the currency symbol to ‘€’.
Within the code these changes are done with the following WordPress filters:
add_filter('bigcommerce/channel/current', function($channel) {
return get_term(41, \BigCommerce\Taxonomies\Channel\Channel::NAME);
}, 10, 1);add_filter('pre_option_' . 'bigcommerce_currency_code', function() {
return 'EUR';
}, 10, 0);
If you have the php-intl extension on your server, the currency formatting will automatically work out at this point. If you don’t, there are additional filters to use that are explicit:
add_filter('pre_option_bigcommerce_currency_symbol', function() {
return '€';
}, 10, 0);add_filter('pre_option_bigcommerce_currency_symbol_position', function() {
return 'left';
}, 10, 0);add_filter('pre_option_bigcommerce_decimal_units', function() {
return 2;
}, 10, 0);add_filter('pre_option_bigcommerce_integer_units', function() {
return 16;
}, 10, 0);
Added up into something runnable, the code looks like:
Testing GeoIP Triggering
You can test the French channel on the storefront using a VPN or a cloud-based geo tester like LocaBrowser to appear as if you are in a French location.
Triggering a region via Query String
Another common implementation is using the url as a trigger for a specific locale. Using much of the same logic but replacing the GeoIP check with a query string check, I produced another child plugin example in a matter of minutes.
From a high level, the code is now:
if ( $_GET[ 'region' ] !== 'en' && ($_GET[ 'region' ] === 'fr' || strpos($_SERVER['HTTP_REFERER'], 'region=fr') !== false) ) { // Same channel filters as the GeoIP example}
Adding a Region Selector
To allow the user to switch back and forth between the US and French regions on the storefront, I added a simple menu, based on a Code Pen published by Axel Köhler.
Here’s the PHP code for the region selector:
And some CSS to style it:
I also added this to mask the ‘flash’ of the pricing loading for a specific channel:
.bc-product__pricing--cached { visibility: hidden !important; }In the child plugin for this example, the PHP template and CSS for the menu are included. This means you don’t have to modify your theme files to accomplish this UX, which is a nice perk.
The end result is this region selection UX:
Example Child Plugin Downloads
Jump start your development with one of these child plugins, based on the examples above:
- By GeoIP: http://bit.ly/bc4wp-geoip-region-activation
- By Query String: http://bit.ly/bc4wp-query-string-activation
Conclusion
While a production-ready multi-region site would be more complex than what we’ve covered here, the purpose of this demo is to illustrate how BigCommerce for WordPress gives developers the tools to unlock multi-region capabilities with relatively little code.
More documentation on the BigCommerce for WordPress multi-channel mode will be coming soon, and be sure to keep tabs on our BC4WP releases in GitHub for the latest additions to the plugin.
Also, note that since BC4WP is using public BigCommerce APIs to make all this happen, all these concepts can apply to any headless commerce implementation.
We’re excited to see where the community takes this, and we’d also love your feedback. Let us know what you’re building in the comments below and join the conversation by tweeting @BigCommerceDevs.
