This is a blog post intended for anyone looking to get started with building websites with WordPress. It is more or less a collection of links to the official documentation which is great. However it can be somewhat daunting, so hopefully this is handy to get into the nitty gritty a little faster.
Note: as you will see below. There is no reference to the Block editor in this article. While we appreciate the hard work that has gone in to that editor, our own workflow does not include it at this point.
First things first, if you are all new to WordPress, it is always good to start with some semantics. Many of the concepts in the this article will be repeated further down; https://wordpress.org/documentation/article/wordpress-semantics/
Let’s get ready to start building. First of all you need WordPress running, either on a web server or locally. If you are going to develop on a server, many web hosts have very easy guides to installing WordPress, some even have 1-click installations.
If you are installing WordPress yourself on a server, this is how you do it: https://wordpress.org/documentation/article/how-to-install-wordpress/
As developers, we often like to work locally in order to avoid latency or just keep things to ourselves. There are many different ways of running a server locally and installing WordPress on that, but we highly recommend using the software Local for your local WordPress environment: https://localwp.com/help-docs/getting-started/installing-local/
If you are working as a team, you need to define a workflow for your collaboration. There are more or less complicated solutions for this, all with pro’s and con’s. We usually favor a fairly simplistic approach using GitHub to share theme (and/or plugin) code between us. If we work on a server, the environment is already shared by default, which is helpful since any content created or plugin installed is there for everyone, however working in tandem in a “live” environment (even a staging one) can easily cause some temporary conflicts. In cases where more than one developer will be working on a site at the same time, we recommend using local environments and only push completed features, templates et c, to any shared environment.
More about setting up GitHub and Local: https://localwp.com/help-docs/advanced/developing-with-local-and-github/
In it’s essence, a WordPress only need to be two files, style.css and index.php
In order to work as a theme, the Index template would need to include a WordPress concept called “The Loop”, which is a function to display whatever content has been retrieved through the WordPress Query. Here is more information about The Loop: https://codex.wordpress.org/The_Loop
With a style.css and an index.php in place, the possibilities are endless. If you want more information about structuring your code when developing your theme further, the official Theme Handbook is a thorough documentation of all things theme-related: https://developer.wordpress.org/themes/getting-started/
If you do not feel like reading the whole Handbook here are some shortcuts to the most important features in our opinion.
WordPress has two (public) post types built-in, which is Posts or Pages. The main difference between the two is that Pages are hierarchical, posts are not. Learn about the basics here: https://developer.wordpress.org/themes/basics/post-types/
One of the most important features of WordPress is the ability to create more post types, named anything you like. You can for instance create a type of content like “Case Studies”, which would appear in the right-hand side menu, making the UI much easier to grasp for editors. By extending Custom Post Type with custom Meta Data (more below), you can create very bespoke admin interfaces for editors. Here is a guide to registering your own custom post types: https://developer.wordpress.org/plugins/post-types/registering-custom-post-types/
Tip: We normally delete the “Hello world” post that ships with WordPress and then hide the “Posts” post-type, as bots have a tendency to try and hammer that post with comments if it’s left public with comments activated (you can easily find references to hiding things in the Dashboard and Menu or disabling comments completely by googling)
In short, WordPress takes care of routing in your website by reading the URL and querying the database for the content that URL should display.
If you want to really dig in to the WordPress Query, be our guest: https://developer.wordpress.org/reference/classes/wp_query/
The TL;DR is that WordPress does a lot of magic under the hood and it is quite complex. Start by figuring out the difference between the “Plain” and “Post name” options in the Permalink’s under Settings and you have come a long way: https://wordpress.org/documentation/article/settings-permalinks-screen/
Once you have a few pages, posts and possibly some other types of content as well, it is time to dig deeper into the WordPress theme architecture. Based on the Query, WordPress will try to apply an applicable template. The template hierarchy explained and visualized below shows how WordPress will first look for templates that are more clearly defined and then work “backwards” to the more general templates, all ending in index.php

Understanding the template hierarchy is key to structuring your theme code in a readable and manageable way: https://developer.wordpress.org/themes/basics/template-hierarchy/
So you have learned the basics and are looking to evolve your WordPress website to the next level? First of all, there are a more or less endless plugins to help you fix just about anything in a WordPress site. As a general rule, we avoid plugins that we do not know really well. While plugins can be a very quick way to solve things, they can also introduce more code to your site that needed. We want to stress that plugins are just additional code, which you can often add to your own theme code without a plugin.
If you want to add custom code, functions.php is where you start: https://developer.wordpress.org/themes/basics/theme-functions/ — however we suggest splitting your custom code in to multiple files that you include from functions.php instead of adding all code there.
While separating content in different post types is enough for many websites, as the amount of content grows, there is often a need for grouping content that some how relates. For this purpose, WordPress use taxonomies. Taxonomies are like glue, they piece content together. That means if two entries, which may or may not have different post types, are related, you can create a “link”, by giving them the same taxonomy. WordPress has two taxonomies built-in, tags and categories. Just like posts and pages, the difference is that categories are hierarchical and tags are not. Learn the basic about taxonomies here: https://developer.wordpress.org/themes/basics/categories-tags-custom-taxonomies/
Creating your own custom taxonomies, just like creating your own post types, can really benefit the editor in the back-end. For instance, if you want all entries to have a reference to a city, rather than adding a custom field (more below) which would be a plain text input field (running the risk of editors spelling names differently), you can instead create a taxonomy for cities. Then any city added will be stored in the database and other posts can use the same taxonomy, which both avoids any problems with the data input as well as create a reference between the posts in the database. Here is a reference to adding your own custom taxonomies: https://developer.wordpress.org/plugins/taxonomies/working-with-custom-taxonomies/
A really powerful feature of WordPress is the post Meta data. At it is core, it is a key value pair setup where you define key’s and add fields for the editor to edit the values. In a larger site with multiple different types of content, Meta data is more or less mandatory to make the editing experience user friendly. Learn about WordPress Met data here: https://developer.wordpress.org/plugins/metadata/
In recent years, adding custom Meta Boxes is what you want, rather than the traditional key value pairs. While there are many great plugins to help you setup more complex meta box structures (Advanced Custom Fields to name our own favorite), you can definitely solve it on your own as well. We recommend using a plugin like ACF if you are looking to create more complex data structures. Here is a reference to adding your own custom meta boxes: https://developer.wordpress.org/plugins/metadata/custom-meta-boxes/
While the Options API was in WordPress 1.0, WordPress 2.7 introduced the new Settings API. The idea is the same, and can be explained like post Meta data but for your whole site rather than a specific post. Here is an introduction to the Settings API: https://developer.wordpress.org/plugins/settings/settings-api/
It is a great way to add a page in the admin interface for global values like company details such as a phone number or an address that should go in the header or footer. Here is a reference to registering your own Settings page: https://developer.wordpress.org/plugins/settings/custom-settings-page/
TheDock is free for self-hosted WordPress-sites. Sign up, download and get started.
If you do not have a server, you can test on ours; no credit card required. Build, publish and inspect the result, from front-end to back-end to source code. It is all yours and free to edit as you like.