This next post in this series is about getting your hands dirty and actually making a site using the WordPress Site Editor. There are plenty of tutorials on how to use the individual features of the Editor itself—for example, the resources in Carolina Nymark’s free online course for Theme Developers—so this post will explain how I approach building a common site using the Site Editor.
I offer technical, training, programming and conceptual support for partner agencies and freelancers through my agency Say Hello: either on-site or via email, Slack or video call. Get in touch if you’d like to discuss what options I provide. I am fluent in English, German and Swiss German, and my daily rate is means-adjusted for international work.
If you’ve read my previous posts, then you’ll know about the emphasis on reusability and simplicity. This is the best way to get a successful website up-and-running and it’s is always the first step on the path. By applying the same principles at each stage, you’ll find it easier to work in a modular way; approaching each part of the process and focusing on it instead of trying to get your head around the whole project in one go.
Our project details
Let’s say I want to build a site for a local company. Before I start on the technical side of things, I will have decided with the client what they want on their website, and I’ll have either received the content or I’ll have created some fake content with which to start working. I’ll have a site map containing a list of pages and their hierarchy, as well as a design to work from. An example of this kind of website is the German-language website for the milling company Mühle Rytz here in Switzerland.
Font sizing, colours and units
The first step is to add my padding and margin units, font sizes and colour palette to theme.json, as I’ll be using these throughout the site. For projects where I have done the concept work and design, I’ll ensure that there is a consistent set of pre-defined sizes and colours, so that the design is harmonious and maintainable.
Using page templates
Using the Block Editor means that I can use Blocks freely. This means that from a technical point-of-view, there are no “templates” as there used to be in PHP, because I want to have the flexibility of any content structure on any page. In this context, the “templates” connect to the type of content: single.html for a single post, page.html for a single page, and index.html for the overview page of posts.
Before I get into the predefined combinations of blocks which will form the page or post content, I define the structure of each view. In our project for Mühle Rytz I’ll use only the three templates mentioned above, and create a header and footer which will be the same on every page. The remainder of the content will be loaded by using the Post Content block.
I add the necessary files (mentioned above) to the templates folder in my theme. These can be completely empty: I’ll add the Blocks using the Site Editor. The files index.html, page.html and single.html are regular templates, so WordPress will recognise them in the Site Editor automatically. (If I add custom templates, then I need to define them in the theme.json file.)
I then switch to the Site Editor and add a header and footer as Template Parts, with the Post Content block between them. I usually wrap the main content in a main tag and although I put this layout together visually in the editor, this is the resultant HTML which the editor generates for the single post and single page views.
<!-- wp:template-part {"slug":"header","tagName":"header"} /-->
<!-- wp:group {"tagName":"main","layout":{"type":"constrained"}} -->
<main class="wp-block-group">
<!-- wp:post-content {"align":"full","layout":{"inherit":true}} /-->
</main>
<!-- /wp:group -->
<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->The index.html view, which contains a list of current posts, is a little more complex and beyond the scope of this post. Basically, I add a Query Loop Block and use inner blocks within it to decide how the list will look.
Template Parts
Although the naming convention used by WordPress seems to change more often than necessary, the principle of Template Parts is that you can define a collection of Blocks which can be included automatically on every page of the website. This will allow me to show the same content in the footer section of every page and post, and the same navigation on every page thanks to the header area.
If the site has multiple different headers and footers, we can use the area definitions “header” and “footer”, but the full benefits are a little complex for this article. I use them anyway for clarity, even if this isn’t essential for most of my projects.
I do my best to use Core Blocks as much as possible and I spend enough time getting to know them and keeping my knowledge up-to-date so that I know what I can achieve, and where I’ll need to use my own custom blocks or custom CSS and JavaScript.
The header of the Mühle Rytz website can be achieved with a regular columns block and I use the Conditional Block Visibility Plugin on every site I build. This allows me to hide and show blocks according to the screen size (amongst other conditions). The header navigation will be hidden for visitors with tablet and mobile devices, whilst a custom “toggler” button will be shown at smaller screen sizes, which allows users to show and hide the mobile navigation at will. I have, until my most recent project, added background graphics using custom CSS, but I may reconsider this decision in upcoming projects thanks to newer possibilities in the Block Editor.
Because I’ve already added the sizing, spacing and colour units to theme.json, I select them instead of using custom values on all of the elements. The footer is a simpler matter than the header, given that all of the content appears at all screen sizes, and the projects I conceive usually comply with the usual breakpoint behaviour for core blocks.
The navigation
WordPress core provides us with the Navigation Block, but it remains far too limited and complicated for all of the projects I’ve created over the past few years. For this reason, I use my own navigation block (or blocks, depending on the complexity of the site) which allow(s) me to use wp_nav_menu to render the HTML using PHP and to add my own CSS and JavaScript specifically for each block. By using the classic WordPress menu editor, users can also adjust simpler menus much more easily.
For projects where the navigation is more complex and where the navigation is better created using blocks, I use a very similar approach to my friend Silvan, which he’s explained in loads of detail in his latest blog post “WordPress Mega Menu with Blocks”. (Also available as a walk-through on YouTube.) I’ve used my own code until now instead of a third-party plugin, but I may revise that decision for future projects.
Version control
Now that I have the basic setup in the Site Editor, I check the output of the site in the frontend. Assuming that I’ve set up the essential configuration in theme.json (which I usually edit by hand), the site and the dummy content should be looking fairly good already. It may be that I need to add some custom CSS or JavaScript, but this will be an enhancement and so I’ll be adding it in a later step.
I use version control (Git), so I want to save out the changes to my theme so far and create a commit. In order to do so, I use the Create Block Theme plugin to save out all of the changes I’ve made in the editor to files in the theme. This will store the current state of the theme and I can start with the next stage: custom blocks.
Custom blocks
Assuming that I’ve been able to create the main page layout using the Site Editor, I’ll now create as much of the content as possible using the Block Editor in (for example) the regular page editor. (This experience may change, as work is being carried out to bring the content editing and site editing experiences closer together.)
I’ll have reviewed the site content from the design and site map, and made sure that I know (in general terms) what content sections I will need. Many of them are achievable using the core blocks, but most projects need one or more custom blocks. I add a simple bright yellow placeholder (paragraph block) throughout the site where a custom block will need to be added.
Back in 2021, I created a lot of custom blocks but the great majority of the site content for Mühle Rytz can now be created by using core blocks: columns and cover blocks, for example. However, some content (like the timeline on this page) requires the use of a custom block.
I prefer to make custom blocks myself; although the use of popular plugins to add custom blocks makes things easier, this can add a lot of unnecessary code or interface controls to the site. Whatever your decision, it’s essential to use a plugin which is both maintained regularly and of high quality. Using a low-quality plugin is a quick way to introduce performance and usability problems, and using more than one block plugin in the same project may quickly lead to conflicts and errors.
The topic of creating custom blocks will follow in a later post in this series.
Block patterns
Once I have all of the blocks available, then I decide, based on the needs of the project, whether to create block patterns or not. (Block patterns are like templates, but will be inserted in the page or post content editorially and either fully or partially kept in sync across the website.)
If block patterns are needed—perhaps editors want to create lots of pages and posts based on pre-defined layouts—then I’ll add these block patterns to the Theme and define whether they remain fully or partially synchronised, or whether they need to be editable at content level only. Often, a layout which first appears to be a collection of blocks can be much more easily edited by creating a custom block, so I use that option quite often.
Once the block patterns are added to the theme, then I’ll commit a new version using Git and begin work on any custom code which is needed. This will be the subject of a future blog post.
Next time…
In the next post in this series, I’ll explain how and when I build custom blocks, what the pitfalls and advantages are, and which technology makes most sense in different circumstances.
Leave a Reply