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.
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.
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.