I plan to keep banging this drum — WordPress 5.0 is coming this year, a lot will change, and the big change will be the introduction of a new default editor codenamed “Gutenberg.”
Elsewhere I’ve (hastily) sketched out some things WordPress users should do to prepare for 5.0, here I’m addressing WordPress developers.
Blocks of content entered into a post (keep in mind that everything is a post) via Gutenberg get tagged with a block-specific CSS class, like
.wp-block-cover-image. Default styles for core-blocks are loaded (for now, While we use a plugin) from
somedomain.com/wp-content/plugins/gutenberg/build/core-blocks/style.css, and are loaded before the theme stylesheets. The Gutenberg developers have written well-formed CSS so a theme’s stylesheet overrides the default styles without problems like over-specified selectors or
Much of my work is building custom WordPress themes and the custom themes I make almost always start from Automattic’s Underscores starter-theme. Underscores provides modularized CSS using SASS. Anticipating WordPress 5.0, and for the sites (like this one) that currently use the plugin, I’ve created a collection of SASS files copying the default styles for Gutenberg core blocks, organized according to where the block sits in the editor’s selection dropdown. The files are available on Github.
A developer can incorporate this collection to a theme’s SASS folder for quick availability of the necessary selectors for styling blocks, providing a head-start in matching block styles to the theme.
In addition to the theme styles, there is also a collection of editor-styles in the GitHub project. I don’t want to blab about it here, but with careful development of editor-styles, a theme can come very close to displaying the editor contents just as they will appear on the live site, approaching the What You See Is What You Get promise that no one has ever quite delivered.
WordPress 5.0 is expected to be released in August. It’s a big change that will break some sites that aren’t prepared.
Here’s my take on what ought to be done when a release date is announced:
suspend any automatic upgrades;
make sure a backup program is in place;
install 5.0 and test on a staging/development site before upgrading a live site;
install, activate, and test a "Classic Editor" plugin.
The big change in WordPress 5.0 is the vastly improved editor (called “Gutenberg”) and it won’t work on existing themes without revising them. The necessary revisions aren’t predictable so we can’t estimate even a ballpark cost for the necessary revisions.
Kitchen-sink themes like Divi and Avada will probably take it upon themselves to replace Gutenberg with their own page-builder, but they might be sacrificing some medium-term benefits — Automattic has big plans for WordPress and much of it is centered around maximum use of the new editor.
It’s a good time to start planning to re-do older sites, looking at completion in early 2019 when WordPress 5.x has stabilized a little.
The theme used on this site, “SwingYourPartner” (that’s what popped into my head) was built to maximize page performance. The screen-shot shows the current score on Page Speed Insights. The two Font Awesome files mentioned as things to improve are served by the CDN without expiration directives in the header, and although I could work around that by serving local copies, the advantages of the CDN outweigh the Page Speed Insights ‘score’, to my mind, because the site is fast, loading in about 2 seconds.(read more )
The low initial cost of commercial WordPress themes compared to the relatively high cost of developing a custom theme can be a huge benefit regardless of the purpose of your site. But, depending on how your future needs shake out, you might pay a high price later for that initial convenience.(read more )
I was recently asked to add a button in the header of an Avada child-theme and was surprised when a search turned up no advice. It’s not hard but takes a little digging so I’m posting this in case it might help someone in the same situation.
Avada has six header layout options, selectable from the WordPress Dashboard via “Avada > Theme Options > Header > Header Content”:
These options map to files at “/wp-content/themes/Avada/templates”. You can override the Avada templates by creating your own in a “templates” sub-directory of your child-theme folder and copying a code block containing the action hook from “/wp-content/themes/Avada/templates/header.php” to your child-theme’s “functions.php”.
The local (child-theme) function will be called first at action-time, so the default Avada function will never be called and the local template will be loaded rather than the one in the Avada folder.
There’s a more detailed Gist at GitHub