WordPress is an incredibly powerful content management system, but it wasn’t always like that. Originally started as a simple blogging platform it has grown and become increasingly complex over the years, worked on by thousands of dedicated volunteers.
The beauty of WordPress is that if it can be imagined, it can be made, and so now it’s the most prolific website content management system in the world, running nearly 30% of all websites.
The feature list is extensive and ever growing, and it doesn’t matter if you’re an end user at a content publishing house or an experienced web designer or developer, you can use it however you wish and change it at will.
WordPress is all about the data – and to understand the principles behind how it works, you have to get a handle on the data, how it’s stored, and how it’s used.
Loosely speaking the main data categories are Posts, Comments, Users, and Terms; and each of those is broken down into core data and metadata. Without going too deep into the ins and outs of it, this basically means that managing WordPress and WordPress websites is very easy, and this layer of abstraction makes plugins that extend WordPress and utilise that data very straightforward, without having to break into the core system of the platform.
If you’ve looked at a WordPress dashboard before, you’ll have seen that there are various types of items you can create such as Posts, Pages, and Attachments. The thing is, these are in fact all pretty much the same thing, just used by WordPress in different ways. They are hooked into the core of the system like any other Custom Post Type (CPT) because they are, in essence, pre-defined CPTs.
A CPT is basically any post-type in WordPress. It doesn’t matter what you post, whether it’s a page, attachment, or something else defined such as “Staff Details” or “Book Reviews”, they are all CPTs, just defined by you as the user.
All of these CPTs have options that are always available, these might include things such as the title of the post, the content, the slug (the URL for the page), the template you wish to use, and so on. Again, because of the abstracted nature of the data mentioned earlier, each of these can be turned off at will, or other fields can just as easily be added. The system is highly extendable.
As an example, imagine you’re running the website for a training course. After each lecture or seminar, you create a number of documents outlining the points you’ve made during the session. On the website, you would create a CPT called “Course Notes”. This then appears on the left-hand menu in the admin dashboard. You would click “Course Notes”, add a new item, upload your PowerPoint presentation, PDF, or any other document required and put it in the content area. Once you click Save, those files are accessible through the front-end of the website just like a normal blog post.
The primary difference between the different post types is the slug. This is part of the URL that takes users to each post. In its default setting, WordPress uses what’s known as “ugly” slugs, where the post is accessed simply through its database ID e.g. domain.com/?p=4567. If you enable more user-friendly slugs in your settings, everything starts to make more sense.
Using the example above, to access the higher-level “Course Notes” CPT you would just look at domain.com/course-notes/, and each post would then have its own slug as a subsidiary of that. Let’s say the documents you uploaded previously were all about Shakespeare’s Sonnets. The title of that post would be Shakespeare’s Sonnets, the slug would be “shakespeares-sonnets”, meaning the final URL would be domain.com/course-notes/shakespeares-sonnets.
So – that’s the basics of posts – you can use them or avoid them completely, but you just need to be sure that you use them in the right way. Best practice is to use them when you’re publishing content regularly such as in the example above, or you’re running an online portfolio. It’s not such a good idea to use posts if you’re planning to sell through your website though, an eCommerce system with a greater number of options is likely to work better in that scenario.
Comments are rather more straightforward, and pretty much two-dimensional. There’s no need to define anything, and they only really contain six essential pieces of information. They always relate to a specific post and so contain data relating to the post they’re attached to, the author’s name, email address, and website, and then the comment itself.
Unless you particularly want to extend the functionality of the comments section, this will remain constant.
In WordPress, Terms are your method of categorising your posts and are either hierarchical or non-hierarchical. The easiest way to understand this is to look at the main options on a normal “Post” (regular blog article): Tags and Categories
A post could have many tags associated. Let’s say you’re running a blog about the motoring industry. A post about a new people-carrier or SUV might be tagged with “family”, “economical”, “spacious”, “reliable” and “safe”, but it should only have one or two categories which may or may not be nested. For example, you might have a category of “Family Vehicles” within which you have subcategories of “Saloon” and “MPV”.
Categories should really be seen as overall sections within the blog, where posts on this subject (Family Vehicles) are in this area, whereas posts on other subjects (say, “Sports Cars”) are somewhere else. Tags are more about word association, so you might find a review of a sports car, a saloon car, and a little town runabout in separate categories, but all sharing the tag “economical”.
The terms are complicated further once you get into the realm of Taxonomies. These work similarly to Categories and Tags but are applicable more to Custom Post Types. A taxonomy is a collection of custom terms for CPTs. Running with the previous example, to categorise your vehicles correctly, you define a custom taxonomy called “Vehicles”. “Vehicles” is the taxonomy (or overall collection) and the individual vehicles such as “Cars”, “Vans”, and “Motorbikes” are the terms contained within it. In short, terms link to taxonomies, and taxonomies link to CPTs.
Last, but by no means least, we come to the users. While on one level they’re quite similar to comments insofar as they only contain a few bits of key information, they do have an additional layer of complexity which is required for correct operation of a Content Management System. The users are accounts which are used to log in to the website and perform various operations.
As a website owner, you would log in using a user account that has been defined with the Role of Administrator. However, if you’re running a website which has multiple authors such as an online magazine, you don’t want every person who can log in to your system to be able to do anything with the site that they want: install plugins, create other users, or change the website theme. It’s simply not secure.
By default, WordPress has roles such as Administrator, Editor, Author, Contributor, and Subscriber.
Roles, not unlike Posts, have layers of complexity beneath them, as each Role is made up of Capabilities.
Capabilities are the individual permissions that allow a person to add a new post, edit a post, edit a comment, or delete another user. A specific collection of Capabilities is in turn assigned to a role (such as Editor) and that role is then assigned to a user. To make things even more interesting, a user can be assigned multiple roles.
To go back to the example of an online magazine, you might create a role of “columnist”. The user with this role can add and publish new posts, edit their own posts, and upload relevant images. Another role would be “sub-editor” who can do the same, but in addition, they are able to edit the articles not just that they have written, but the articles of those other users for whom they are responsible. While you could replicate the role of “columnist” and then add the extra permissions for “sub-editor”, what if you need to change permissions for everyone who is able to add a new post? You’d have to go through every single role that has any of those permissions. By building incrementally you can make global changes very easily but without losing control of who is doing what on your site.
The ability to have multiple roles with multiple capabilities which can be assigned to single or multiple users makes delegating tasks, without compromising security, that much easier.
WordPress In A Nutshell
WordPress is such a vast system to write on, with so many variables to explore, that without delving deeper into the code and all the whys and wherefores this is where this piece ends. Like so many guides, reading it in isolation may seem complicated, but if you pair it with a root around your dashboard, it should make a lot more sense. We recommend having another look through and just having a play with your site, exploring the concepts that we’ve introduced here.
It’s come a long way since its early days and is now a very advanced, extensive, extensible, and comprehensive product – and that’s why it’s had such a huge uptake for both amateur bloggers and big businesses alike.
Understanding how this data works and links together should give you an idea of just how and why it’s so powerful and help you to make the most out of your system. Without this level of complexity, the system wouldn’t be anywhere near as good as it is today.
We hope you’ve found this article useful, but if you’re struggling with a WordPress site and need some help getting to some of the nuts and bolts of it; or if you’re having trouble with any other aspect whether it be layout & design, imagery, copywriting, or getting your site to rank on search engines, Big Red Rocket is here to help. Call us today on 01625 359010 or click here to send us a confidential email.