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.
WordPress core only requires PHP 5.2 to run properly. This is great for compatibility with older hosts but this version of PHP was also released in 2006. Using a newer version of PHP provides more security, access to better development tools, and most of all: speed!
For this reason BigBox sets a minimum PHP version of 7.0 — which should be readily available on any reputable hosting company. Below is a quick snippet that blocks a theme from activating if it does not meet the defined PHP version and reverts the website back to the default theme.
WordPress theme structure has largely stayed the same for the last 15 years. There are many great thing about the build in templating system in WordPress, such as the extensive and flexible hierarchy loading system, helpful conditional tags, and more.
However as themes become more complex the forced expectations of where template files are located can become frustrating. Looking at a theme’s root directory and finding a mix of stylesheets, template files, configuration files, project documentation, shell scripts, and more can be overwhelming.