Using vanilla WordPress as a pre-release collaboration medium is great practice to encourage your teams content-driven mindset and ensure smooth onboarding and training at the backend side. The progress of layout and content changes may be observed in revision control mode for learning purposes by future content managers.

Augmented by a necessary minimum of plugins, the official themes are a sufficient tool for low profile project starts. Happening alongside with content placement and maintenance, the individualisation process should be organized in a hierarchical way. This requires the dissection of each design tweak into its comprising parts and translating those into abstractions of a corresponding layer in order to implement the changes in a most reversible and least invasive way.

Theme customisation

Alongs with basic variables the native theme customisation parameters include menus and widgets. This elements are mostly reusable across different themes and can be edited via Appearance > Themes > Customize or via Customize button in the Admin Bar. Further appearance changes indroduced by Twentig plugin are available in the same menu. Bearing several additional features and optional layout presets, it is a good place for a start: after chosing one you can proceed to bootstraping pages with Gutenberg blocks.

Gutenberg Blocks

Also extendable by plugins, WordPress Blocks are the go to solution for decoupling content layout from the theme. Unlike TinyMCE, blocks work thru nested encapsulation in standard abstractions with an option of saving those as own reusable content blocks. Common calls to action, contact and FAQ sections are now editable from one place, much like widgets.

Oftentimes I start by creating those, proceeding with customisation of standard headline an banner blocks. Enriched with font, padding and other parameters, those are saved as custom ones and help to deliver a distinctive and consistent look quickly. Afterwards dedicated category pages can be assembled, eliminating the default archive template look.

Custom CSS

A lot of design requirements can be met by recombining nested blocks. This game can be refined by extending the stylesheets with custom classes and introducing those back into blocks thru the “Additional CSS Class(es)” field.

Overriding the existing CSS structure is the next tier of frontend parametrisation. Oftentimes a simple patch will do the job, especially as long as final layout is not agreed upon. Be careful with making content invisible – display:none; is the fastest way to hide something like metadata, but make sure to delete the unnecessary elements permanently afterwards by means of a child theme.

Child themes

Changing PHP files is the lowest level of theme editing. Commenting out and altering the sources is a powerful tool for look and functionality customisation, which comes at a cost: direct PHP edits break theme’s ability to update and should be avoided at all costs. The best practice is to outsource those into child themes. This relatively time consuming operation may even require brain activation and is considered the last option in defining your WordPress frontend.

Further reading