As you know, over the last couple of months we’ve been working on and beta testing the Storefront 2.0 release. Today I’m happy to say that version 2.0 has been approved on .org and is available for download now! Let’s review The key changes in this version.

Major structural refactor

In Storefront 1.x all the code was structured in a rather messy procedural format. 2.0 introduces a more object oriented approach by wrapping related functions/methods in php classes. There are new classes for;

  • The Customizer implementation
  • The welcome screen
  • The WooCommerce integration
  • The Jetpack integration

Many methods in these classes have been refactored to make it easier for extensions and child themes to work with the Storefront codebase rather than around it.

We’ve also separated functions, template functions and hooks into their own files, making everything more predictable and easier to understand. WooCommerce core has actually been used as the model for many of these changes so if you’ve worked with WooCommerce core directly, working with Storefront should now feel a lot more familiar / intuitive.

Customizer settings are now applied to a single theme_mod.

Storefront utilises the Customizer quite extensively by adding a lot of settings as well as a couple of custom controls. That utilisation goes even further when you add some extensions and a child theme in to the mix. To improve performance, Storefront now saves the current Customizer configuration (for Storefront settings) to just two theme_mods. This means that it only has to ever make two queries per page load instead of 15+.

How does it work? The Storefront_Customizer class includes various methods to achieve this;

  • get_storefront_theme_mods() returns a filterable array of all the theme_mods in the Customizer that Storefront itself adds or uses.
  • get_css() returns a filterable array of CSS selectors and properties which Storefront uses to adjust the frontend display, based on settings the user has specified in the Customizer. It uses the aforementioned get_storefront_theme_mods() method to grab the settings.
  • get_woocommerce_css() does the same as get_css() but for the WooCommerce styles. (There are separate methods to account for the fact that not everyone uses WooCommerce with Storefront).
  • set_storefront_style_theme_mods() sets two theme mods; storefront_styles and storefront_woocommerce_styles which are populated by executing get_css() and get_woocommerce_css() respectively. This method runs on after_switch_theme and customize_save_after. These are the theme_mods that are called on each page load. So you can see that we now only need to reference two theme mods to add the inline styles rather than every single one.

There are however two exceptions where Storefront will use the heftier get_css() and get_woocommerce_css() directly;

  1. When previewing (IE when using the Customizer)
  2. If WP_DEBUG is set to true.

This ensures that when you’re customizing Storefront in the Customizer you’re always seeing the correct settings. Those settings are then applied via set_storefront_style_theme_mods() on customize_save_after.

Customizer defaults now added via filter

In Storefront 1.x, on every instance of get_theme_mod() we supplied a filterable $default argument, which is generally the recommended procedure. Child themes and extensions could then filter this to change the default. However, they also then had to filter the default argument for each instance of add_setting() used in customize_register() . They also had to consider whether to use the core Storefront filter when referencing get_theme_mod() themselves, or whether to create a custom filter – it got complicated. It makes more sense to add complex logic to Storefront core and let child themes leverage that. Let’s keep child themes simple!

As of 2.0, Storefront no longer supplies a $default argument on any instance of get_theme_mod(). Instead, on init we now check if a setting exists and if it doesn’t then we add one. To do this, we define the desired defaults via get_storefront_default_setting_values() – a method which returns a filterable array. The default_theme_mod_values() method (run on init) then filters each theme_mod supplied in get_storefront_default_setting_values() , checks if a value is set, and if not uses the supplied default.

By and by, this means that child themes and extensions now only need to use a single filter (storefront_setting_default_values) to adjust Customizer defaults in Storefront. That filter can also be used to easily add new defaults as well. This is useful if your extension or child theme is adding it’s own settings/controls. It means you can just use Storefront core functionality rather than re-inventing the wheel!

The handheld footer bar

One of my favourite enhancements we’ve made in Storefront 2.0 is the inclusion of the handheld footer bar feature. This feature has allowed us to completely redesign the header section of Storefront when viewed on handheld devices – making it much smaller and giving the page content the focus it deserves.

This feature however may not be for everyone. Perhaps your store simply doesn’t need it? Removing the feature is very easy. The storefront_handheld_footer_bar()  function is brand new and hooked in to the storefront_footer action (with a priority of 999). So to remove it, just use something like;

add_action( 'init', 'jk_remove_storefront_handheld_footer_bar' );

function jk_remove_storefront_handheld_footer_bar() {

remove_action( 'storefront_footer', 'storefront_handheld_footer_bar', 999 );


It it also possible to easily adjust the links present using the storefront_handheld_footer_bar_links filter. Read more about that in the Storefront docs.


As you may know, Storefront applies the header image option in the Customizer as a background image on the header. Previously the logic for this was added directly to the header.php template file. We’ve replaced that logic with a new function.

storefront_header_styles() returns a filterable array of styles applied to the .site-header. This provides a convenient way to customise the site header without using any stylesheets, in case you ever need to.

Assets organisation

In Storefront 1.x, assets were a bit all over the place. In 2.0 we’ve consolidated all assets into a single assets dir in the theme root. This makes everything much easier to find. I’d like to take a look at our Sass organisation which can be a little unintuitive to navigate in 2.1.

All template functions now pluggable

A few template functions in Storefront 1.x were not pluggable. We’ve addressed this in 2.0 ensuring that all of our template functions can easily be redefined and customized in your child themes / plugins. Generally, I still recommend using the provided hooks/filters wherever possible though.

Deprecated functions

Finally, a few functions have been deprecated;

  • storefront_categorized_blog() is a hangover from Underscores and simply not used.
  • storefront_sanitize_hex_color() is no longer necessary thanks to how we set theme mods.
  • storefront_sanitize_layout() is no longer required. storefront_sanitize_choices covers this setting.

That’s all folks

As you can see, quite some work has gone in to 2.0. We hope it all makes the theme better, not only from a design / performance perspective, but also to work with as a developer.

We look forward to seeing what you do with Storefront 2.0!