Evolution of WordPress Themes


  • Theme files define layout, queries, and styling.
  • Header, footer, and widget regions are primarily defined in theme files.
  • Widget area content can be modified by the editor.
  • Some limited modification options provided via the customizer section.
  • Each page or post has defined fields that can be called in templates and queries.
  • Editor control is primarily in the main content region of the page or post.
  • Landing pages benefit from core taxonomy queries.
  • Ability to define alternative templates in theme files which can be selected by the site editor.

The WordPress theming system has always been straight forward and logical and lends itself to easy modification for those with some knowledge of PHP, CSS and JavaScript. Child theming allows for the selection of a baseline “parent” where the “child” files define modifications without requiring a whole new theme.

Each page and post consists of multiple fields (title, date, author, content, excerpt, featured image, taxonomy terms) that are shown in the order and manner defined by the theme’s template files.

Landing pages often include queries defined by taxonomy terms and these displays often include some combination of relevant post fields (such as title, featured image, and excerpt).


  • Custom fields added to facilitate more advanced queries and template layouts.
  • Additional controls added to the customizer and/or supplemental admin panels.
  • Page and template building capabilities which in some cases supersede core WordPress controls.
  • Inclusion of custom post types and taxonomies.

More sophisticated and complex layouts were often impossible to accomplish in the traditional WordPress editor – the inclusion of supplemental and custom fields allowed the site editor the ability to put together such layouts via pre-configured theme templates.

By default, the controls in the customizer are limited, however these options can be expanded to include many supplemental controls.

There are several commercial themes and page builder plugins (such as Visual Composer, Elementor, Divi, Beaver Builder, Brizy) which includes expanded controls that work outside of WordPress core.


  • Incorporation of Gutenberg block capability into the main content area.
  • Incorporation of the block editor into widget region controls.
  • Incorporation of template part controls which utilize the block editor into universal regions such as the header & footer.
  • Inclusion of block patterns into site composition.

This type of theme selectively incorporates the innovations of Full Site Editing on top of a traditional coding structure. The use of the block editor can be expanded to include template parts and block patterns.


  • Baseline configuration is still made in the theme files, but all regions can be modified via the site editor.
  • Many template files are written in standard HTML rather than PHP.
  • New Templates, Template Parts, and Patterns can be created via the site editor.
  • Universal and block specific styling can be modified and edited via the style editor.

FSE is a major break from the traditional way of theme composition, PHP coding is at a minimum, the file structure has evolved to include patterns, templates, and template parts, and practically every aspect of the site can be modified via the site editor. Template and pattern modifications are stored in the database and can be exported as JSON files. Presentation controls which we are used to seeing in the style.css file are now largely found in the theme.json file which also contains calls for defined template parts and custom templates.

With FSE there is diminished need for creating custom fields and virtually no justification for using any kind of page builder. With a FSE theme an informed editor has the ability to modify existing templates, create new templates, update and author template parts to be used as headers, footers and sidebar region all within WordPress core.

When the Gutenberg editor was first introduced a lot of attention was paid to the creation of custom blocks and/or plugins that augmented the set or core blocks. Currently there are approximately one hundred core blocks which cover most forms of content, and there are new blocks being added into core all of the time – meaning that there are few legitimate needs for new and truly custom blocks. Several blocks are intended to be used for layout purposes (columns, group, row, stack) and other blocks can be nested within them to create a kind of mini-template or block pattern. Block patterns can be “synced” where each instance of the pattern is the same and when the “model” is edited those changes will be reflected universally. Conversely an “un-synced” pattern is intended to be used as a template for layout and design where each instance of the “un-synced” pattern is unique and subject to individual editing. Block patterns can facilitate efficient and uniform page and post composition with a level of ease and customization that did not exist before the introduction of block editing.