Less code more database…

Most websites follow a common convention where each view of the site is divided into sections. Some sections like the header, footer, and sidebars will carry consistent content across all locations, and others (namely the content section) will show information that is unique for each individual view. Having elements such as navigation, site name, and contact information in the same place and expressed in the same place in every location gives the site visitor a consistent paradigm to follow when moving through the site, and having these sections uniform in content allows for a single file to be included in the various site templates – meaning when that content changes it only needs to be edited in a single location for those changes to be seen throughout the entire site.

Most WordPress themes include templates for the following views:






In traditional PHP based WordPress themes most issues of layout and styling are defined in code and the controls allowed via the WordPress interface are limited to the main content and widget regions. Widget regions can be placed within the header and footer, navigation can be edited via the menu module and extra controls can be made available to expand the customizer, but at the end of the day the look, feel and layout of a site is determined by the theme selection.

Child themes have always given us the ability to modify a theme without having to overwrite it completely. The child theme only contains the files needed for the specific desired changes while still relying on the parent for most of the structure and functionality. This system works extremely well, but it does require an appreciation for theme file structure, PHP markup and CSS styling.

Before Gutenberg and block-based editing WordPress used the tinyMCE editor which was largely modeled on the Microsoft Word experience. The editor allowed for both a “code” and “visual” display on the back end, had a suite of editing tools which facilitated the insertion of media content and the ability to overwrite the default settings for font size, font color and some HTML tag control. For standard pages and posts these controls were sufficient, but for complex layouts tinyMCE was very limited. Similarly, the traditional WordPress widget controls were limited to a finite set of elements with few options for presentation control.

The introduction of the Gutenberg liberated the editing experience from the word processing paradigm providing improved ability to accomplish complicated layouts via the “design” blocks (group, columns, row, stack) and using a more modular approach to content that better replicates what is really going on in the HTML markup of the page. Block-based editing provides for quicker and more efficient movement of components within a section and finer overall control since each block type contains a suite of tools that can modify how that block looks and behaves. Widget regions are also now block-based which makes those areas no different to edit than a standard piece of content. With full site editing those same controls exist for the header, footer, and other “included” segments of the site.

This works by the fact that all of this information (markup, content, media, meta-data) is being stored in the database and is being dynamically displayed on the front-end when the post data is called. In terms of database function, the definition of post data and post types goes further than you may expect as under the wp_post table you will find post types for block patterns (wp_block), navigation (wp_navigation), templates (wp_template), template parts (wp_template_part) and more. When you change the composition of a post, a pattern, or a template, or any other block-based component – that change is stored in the database.

What that means for the site editor is that everything can now be left exposed to their control – what that means for WordPress developers is a complete shift in theming conventions.