WordPress’ popularity and success stems from its simplicity. A simplicity that grew from the humble nature of its origin; designed originally to allow users to easily manage their own blogging websites. The WordPress site today offers both a hosted version of the WordPress open source software on their own platform, and allows anyone to download the software in a single neat zipped up package. Unpacking this bundle and setting it up on a web server will provide the front and back end areas necessary to run a blog. The front end being the website that visitors see, and the back-end refers to the hidden, password protected admin area that only the administrator or trusted team can see. From this area, content is created, pages are managed and most aspects of the front end of the site are controlled and altered.
There are and have always been a range of online services and platforms that offer this, ranging from things that may not be so obviously comparable, and are strictly hosted by the creating company like MySpace and Facebook, through to more extensible platforms like Joomla and Drupal. It was WordPress’ simple blog based origins though that have helped it become the web staple that it is today. It has developed into an incredibly powerful tool, whilst not becoming overly complicated to use at a beginner level, but still being very extensible for advanced users. Running on widely used PHP and MySQL technology has helped this, as these languages are among the most common used in all modern web development. Setting up WordPress is simple and easy to follow, with built-in setup screens to help begin the initial set-up. All users need to be able to do is set up a database and a database user; something that is simplified in many modern hosting dashboards or local web servers.
When to Use WordPress
WordPress is a useful way for people to set up their own site or small blog, but it’s also the major platform for many large media groups like the TIME Media Group, who run sites for their brands like NME, Time, InStyle on large scale, bespoke setups. Using the WooCommerce plugin and its extensions, it’s possible to build large, feature rich, fully self contained functional e-commerce stores using WordPress. But a far more common use of WordPress is to build visually impressive sites, serving lots of media and content.
Adding e-commerce to a site is one of the main feature requirements that should influence the decision to use WordPress or not. If the site is a relatively small e-commerce store with less than 100 products, then something like Shopify should be considered as this will give you a hassle free shop with categories, products, basket, cart and payment gateways all easily set up. WooCommerce is a great commerce platform for WordPress, but unless you are using a theme that includes WooCommere styling, this is an area that can quickly begin soaking up time. As features get more advanced and bespoke, personal judgement needs to be made regarding whether a different platform will offer a particular advantage over the simplicity of WordPress.
When developing just one WP site, or a few now and then, there is always a phase at the start where the layout of the site must be considered and planned, within the context WordPress. This means mapping the entire site out and defining all pages, specific functionality and pieces of content in terms of custom posts, taxonomies, custom fields, plugins and shortcodes. These are then wrapped up in themes, child themes, existing and custom plugins.
In order to build a WordPress site structure in this manner, it is important to properly understand the terms used to define the different aspects of WordPress.
Custom Post Types
WordPress has a single base content unit called a post. A post is way of separating content on a site. One way of separating content is by putting it on different pages, so pages in WP are essentially a category or ‘type’ of post. Pages are one of the two default post types, the other simply being base, unaltered or grouped ‘posts’. Posts are typically used for the blog, and pages (that are still just posts at heart) are used for everything else. This can become slightly confusing, as we add more different types of content, .e.g. ‘Clients’ or ‘Team Members’, where each would clearly have their own specific relevant content. Clients, team members and pages would then be different ‘types’ of the base, post content unit. They are all saved in the same table in the database (even called wp_posts) and are differentiated only by a database table column called ‘post_type’.
Creating a new custom post type will add a new section in the admin area, and a new wp_posts value that a post can be defined as. This is a useful way to structure content throughout the site, as it allows for a series of built-in WP functions that edit, create and manipulate posts to all relevant to post types and be used in all sections of the site. This means that a page template that collects and displays posts of one type can be re-used in another place to list posts of a different type, with only the name of the post needing to be changed. Although posts can be thought of as the most basic unit to hold content in WP, not all individual items fall under the same definition. Several individualised aspects including users, categories and comments are not posts, will have their own database table and will not work with any of the same WP post functions.
There are numerous advantages to having all of a sites content divided into individual post types. It means that there is a section in the admin area to view, filter and edit the content by post type. Extra fields, and a lot of customisation can also be added to these individual admin areas. For example a ‘clients’ area may need an option to upload a logo for the company, but a ‘case studies’ section may not require a logo upload. So we avoid any confusion for the admin user by having the logo uploader appear only in the client area. Structuring the content in this way also makes it simpler to gather it on the front end. There are built-in WordPress functions and queries that will get all posts of type X and or Y. It also allows for more advanced features to be built in, like the adding the ability for different posts types to be linked. An example of this would be having on every client page the ability to select a relevant case study demonstrating the work done for that client. This would show a list of case study post types and allow the admin user to create and manage this relationship themselves, all via the clean and clear WordPress UI.
View the creating custom post types guide here.
WordPress’ default post type called posts can be created, edited, deleted and displayed, and in the same way, the default taxonomy called ‘categories’ that groups the posts, shows how taxonomies in WP work. Taxonomies in this sense should not be confused with the grouping of posts by post type, and are instead a way to group posts within their defined post type. An example of this would be grouping a Clients post type into two taxonomies called ‘Domestic’ and ‘International’. In this circumstance the taxonomy would be called something like ‘Region’, which has two options; domestic and international. This does not stop each post being a client, but just serves as a way to group them further. The name ‘category’ is the default name for the default taxonomy, used to group the default post type; posts. A taxonomy for a different post type would need a different name. It is possible for one taxonomy to span multiple post types, but this is unusual outside of complex site structures.
Post types and taxonomies allow for large amounts of content and media to be structured within a site into types and categories, but by default do not allow for a lot of complex data to be entered. By default, posts and taxonomies have a few different input fields such as a title, a content area, and an image uploader. But a single page can require a lot more individual fields for different pieces of information. It is possible to enter all of this into the WYSIWYG text-area content field, and even get some level of customisation and layout control, but there are numerous advantages to splitting content out into additional fields.
The custom fields that are used can be unique for each custom post or taxonomy can be unique to that post / taxonomy, or can be shown on multiple different types. A custom field is an individual field, a unique entry in the database that adds a new piece of user-defined text that is saved against that specific post / taxonomy. For example, I can set the field ‘Client Location’ to appear as a new text box whenever a client is added in the WP admin area. This will allow a different location to be set for each client. Then on the front end of the site, the location can be retrieved and displayed individually for each client.
Complex, or in any way interesting designs beyond simple blog pages will usually involve content and images being aligned in unique layouts. Content will often be broken up by sections or banners that are not a part of the individual content. For example having a newsletter sign up form or advert half way through some content is not unusual. It is possible to split content using PHP, but it’s a lot simpler and more reliable to divide the content up into sections and just output one above and one below our form or advert. Another example is a design that may have text and image content sections arranged next to each other or in a non-linear layout. Breaking the content into easier to manipulate, smaller chunks allows for the complex layouts to be defined in the template code, and not attempted by the user in a WYSIWYG field, which even in the best case scenario can never achieve the same results. Having the content in smaller chunks like this allows for the template to display it in a way that will make the page responsive and make content easier to read on smaller devices.
It is possible to set up custom fields using either built in WordPress hooks and functions to build new admin UI elements, or to use a very popular plugin called Advanced Custom Fields. This plugin creates another UI area in the admin that allows simple management of these custom fields. While some may argue that a built in solution is favourable, as it relies less upon a third party plugin, it is important to remember that using WordPress is supposed to make some of this easier and quicker for developers. The risk of using a not completely original piece of software is somewhat dulled when considering that the platform being used is WordPress in the first place and not a bespoke Symfony or Rails based system. This particular plugin is so widely used that it is a full product within itself and will not be going anywhere anytime soon.
Custom fields can also be used in a more advanced way, to allow an admin user to dynamically add unlimited content to and remove from pages, still within the extra, custom fields already described. These are called repeaters and flexible content repeaters. A repeater will allow the addition, removal and editing of an input within a custom field. The field added to a post will look and work the same as a regular custom field, but with the option to press a little plus button and create another copy of the extra field. This is useful for something like bullet point content, where the amount of bullets may be different for each post. Using a repeater, as many fields (bullet point rows) as desired can be added, edited and deleted as necessary. This is further extensible by using flexible content repeaters. These work in the same way as repeaters, but when adding a new field, give options of different inputs, or even collections of inputs to be added. Adding different fields like this allows for example, a content block with an image on the left and text on the right to be added, then another block with the order reversed. Then as many of these two blocks, in whatever order can be added, edited, deleted and re-ordered. This gives great control as it allows the user to not only control the content on the page, but the layout too, whilst staying within a predetermined list of blocks, each which are styled and ready to be repeated in the front end template.
ACF is an example of a plugin, but the scale and application of it warranted its own section to discuss it. There are a great many other plugins that will do things like creating post types, taxonomies and custom fields (not using ACF) that can be of great use. Often these plugins introduce a lot of custom settings and options to really allow an admin user to customise the site thoroughly. This is achievable by using the methods discussed above, but often unnecessary, as someone has spent a lot of time building a plugin that has far more options and far fewer bugs. Often plugins will be based around offering total control over a particular section or function. Like an events plugin will allow the creation and removal of events, with all relevant fields for location, start and finish time & date etc. Plugins can also be a useful way to introduce custom tools to the WordPress admin arsenal, such as rebuilding image sizes, generating short links or managing SEO.
Almost everything most people will want is achievable using the above methods in the correct way, but there are ways to improve upon how these are implemented. It is possible to build a site using custom posts, taxonomies etc using the template files inside of a theme or child theme. But often it can be beneficial to break specific feature sets and areas into individual groups, which become plugins. It is very quick and simple to create a custom plugin in WordPress, which will in turn make it easier to re-use sections in other projects, instead of sifting through a single file for the snippets of code that are applicable to a particular section.
For the majority of development cases, all code for that project will be contained within the theme. Complexity can arise when attempting to decide whether and what aspects of a site build should be in the theme, and what is worth splitting out into individual plugins. Often if this code is not going to be repeated in other projects, or broken down and worked on by different developers, then there isn’t much point in bothering with separating a projects features out into plugins. But if the functionality might be useful in other projects, or will be maintained over time by different dev’s or teams, then it can be beneficial to have the code segregated out in this way.
Developers will often use a base theme to begin development, either from a pre-existing theme, or a newly downloaded theme. A child theme is a sub-theme of the parent theme, and inherits all of the styles and functions from the parent theme. This allows for a child theme to be developed, altered, improved and tested without breaking the code in the main theme or inadvertently over-writing things that are required. Using a child theme also means that a parent theme can be updated if needed or if the theme creator adds an update. Child themes work by essentially creating a priority hierarchy. They start by looking in the child themes theme folder for styles, templates etc and will use that one if they find it in there. If WordPress can’t find what it is looking for in the child theme, it will fall back to looking into the parent theme.
Shortcodes can be useful to add larger or more complicated HTML elements into a page. A shortcode is a keyword or phrase in square brackets that WP identifies (by unique term and the brackets) and replaces with some other, predefined content. This block of code can also contain other parameters that alter the outcome. For example, in a post or page content section won’t print that out as text, but will look up what it has been told to print in place of that text. Parameters are set as with any other HTML element, but the particular shortcode must be expecting the parameters. E.g.
[shortcode-name id="123" size="medium"]