What’s New in BigBox 2.3.0

BigBox 2.3.0 continues accessibility improvements of the theme, the developer experience, and deepens 3rd party plugin integrations.

New Features

Full Changelog

[2.3.1] – 2018-01-08

  • Ensure header allows dropdown facet types.

[2.3.0] – 2018-01-08

  • Further :focus accessibility improvements.
  • Fallback to default shop sidebar on dynamic shop page mobile filters.
  • Avoid Javascript error when focus element on horizontal nav bar does not exist.
  • Avoid PHP syntax error.

[2.2.0] – 2018-12-27

  • Accessibility improvements:
    • Better tabbing order for shop filters and results.
    • “Skip to content” and “Skip to result” skip links.
    • Ensure all focus outlines are visible.
  • Upgrade developer experience:
    • Use more @wordpress npm packages (eslintbrowserslist)
    • Update JS coding standards.
    • Update PHP coding standards.
    • Update CSS coding standards.
  • Request a Google Fonts API key when generating font list.
  • Allow integrations to define helper files to be autoloaded.
  • Avoid error if offcanvas drawer source or target does not exist.

What’s New in BigBox 2.1.0

BigBox 2.x brings the first breaking changes to the theme’s development. While the changes are minor, they are not backwards compatible.

Breaking Changes


add_action( 'wp_enqueue_scripts', 'bigbox_enqueue_styles', 10 );


add_action( 'wp_enqueue_scripts', 'bigbox_enqueue_styles', 20 );


This allows for integrations, child themes, plugins, etc to filter the inline CSS on the default priority before the parent theme outputs it.


The parent theme’s uncompiled stylesheet was named style.scss


The parent theme’s uncompiled stylesheet is named app.scss


Naming consistency.

New Features

  • WordPress 5.0.1, Gutenberg 4.7.1 compatibility, WooCommerce 3.5.2 compatibility. 
  • Keyboard accessibility improvements.

Bug Fixes/Improvements

  • Default grid to be 80% page width at extra large device size.
  • More precise em to px conversions for better font smoothing.
  • Only output inline CSS for colors that have been customized.
  • Move/modularize integration styles to their respective directories.
  • Alignment of icons in menu items.
  • Ensure no purchase button shows for external products.
  • Continuous coding standard improvements.
  • Remove fitvids in favor of Gutenberg responsive embeds.

Full Changelog

[2.1.0] – 2018-12-18

  • WordPress 5.x compatibility.
  • Gutenberg 4.x compatibility.
  • WooCommerce 3.5.x compatibility.
  • Ensure button color is accurately reflected.
  • Coding standad updates.

[2.0.0] – 2018-11-06

  • Base stylesheet enqueued with wp_enqueue_script priority 20 (was 10).
  • Base stylesheet renamed to app.scss (was style.scss) — child themes referencing this need to update.
  • Gutenberg 4.2 compatibility.
  • WooCommerce 3.5.1 compatibility.
  • WooCommerce Bookings custom styles support.
  • Keyboard accessibility improvements for desktop and mobile menus.
  • Do not output inline CSS for values that have not been customized.
  • Stripe gateway checkout styles.
  • More precise em to px conversions for better font smoothing.
  • Icon menu alignment for icons of all sizes.
  • WooCommerce message button alignment.
  • Ensure external WooCommerce products are purchaseable.
  • Ensure blockUI library uses accurate background color.
  • Default grid to be 80% page width at extra large device size.
  • Better separation of integration CSS.
  • Move integration views to main views directory.
  • Remove fitvids in favor of Gutenberg responsive embeds.
  • Remove offcanvas drawer cache for better dynamic content support.
  • More consistent dynamic widget area names (“Page Name Sidebar (Left)”)
  • Adjust shop sidebar widths to be smaller.
  • Grouped product purchase form appearance.

What’s New in BigBox 1.15.0

Gutenberg 4.0 Compatibility

Continued improvements to the ever-changing Gutenberg plugin editor experience. As Gutenberg inches towards a final merge proposal in to WordPress core, theme integration/extendability is finally beginning to stabilize. The latest changes to BigBox ensure performant admin editor styles and continued tweaks to conform to the recommended theme support.


Custom Color Palette for Customize Color Control

WordPress offers a built in way to create a color picker in the WordPress customizer. This is often used by themes to allow users to create unique color schemes for their site.

Default Control

The default color picker includes a built in list of predefined colors to allow users to easily set a base color. This is very helpful as the picker with nearly unlimited options can be a bit daunting. However, these colors are set by WordPress and don’t always relate to the theme being used.


What’s New in BigBox 1.7.0

BigBox 1.7.0 includes a few great enhancements to further push the performance of the theme.

Lately I have been following the WP Rig project which aims to create a modern build process and and implement progressive enhancements for many web standards. From the theme I found the lazy loading of images an interesting concept to implement and borrowed some code (🎉 GPL!) to implement in BigBox. You can see the images lazy loading in the BigBox demo →


Automatically Apply Custom Page Templates

A lot of WordPress themes include custom page templates. These can be used to create a different layout than the standard page.php file. Originally this was used (and is still a valid use-case) to provide just a marginally different layout such as removing the page’s sidebar.

As the WordPress ecosystem grew so did the use cases for custom page layouts. Separately styled pages for eCommerce cart & checkout pages, account pages, contact pages, and more became very common. The developer documentation for page templates suggests that these one-time use templates should not be given the traditional PHP comment header to avoid having them appear in the “Page Attributes” meta box.


The State of Gutenberg and WordPress Themes


“A Realistic Look at Using 3rd Party Gutenberg Blocks in Your Theme”


“Keep Your Plugin Blocks Out of My Theme”


“Shortcodes All Over Again”


“The Never Ending Battle to Style a Button Consistently”


“We Still Have a Long Way to Go”

I would like to preface this article by saying that these thoughts and opinions are in no way meant to diminish the amazing work that the Gutenberg team has done (and continues to do). I love writing in Gutenberg. I follow the GitHub repository closely, often reading 100+ notifications each day. I have been testing since early versions. I have left feedback. Things have gotten much better. However this article is meant to take a realistic and somewhat critical look at how Gutenberg is being presented on a grander scale vs. some of the realities that come in to play when implementing these ideas.


Use Customizer Color Settings to Create a Gutenberg Color Palette

Most WordPress themes within the past few years have included helpful options in the WordPress customizer to help users quickly and easily modify how their theme behaves and looks. In fact, it is a requirement to list your theme on WordPress.org to only use the Customize API and not the Settings API.

With the new Gutenberg editor (soon to take over the role of just “the editor”) a new use-case for these custom colors has risen. Gutenberg offers the ability to define a custom color palette that can be used wherever blocks allow colors to be chosen. By default this includes paragraph text and background colors.