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.
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.
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.
Gutenberg has brought many improvements to WordPress development and build processes — which is great. One of my favorite parts of this is the publishing of 20+ node packages to help aid in and help modularize development. There are two that I’ve been enjoying using lately.
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 →
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.
“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.
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.