Many years ago, I used to write technical manuals for clients. These would generally take the form of paper documents, with hundreds of pages of technical information printed off and probably used as a handy place to rest a coffee mug by most of the people they were produced for. If the client was exceptionally advanced, there might have been a PDF version, but it was rarely used.
Times have moved on, and most manuals, or knowledge bases as they are often known, are in a digital form. They may take the form of an app or website, or some kind of simulation, but they will always have data at their core. Knowledge bases must be easy for users to search and navigate around, and they must be easy for writers to add content to or edit content, without having to work on any piece of data more than once.
This is why any system that's driven by a database will be the most appropriate. I've been using WordPress to drive this kind of internal website for a while now and I find the flexibility WordPress gives you over how you display and query data, combined with the admin interface that's familiar to a lot of people, make it an ideal tool.
In this series, I'll show you know to build a knowledge base using WordPress. I'll take you through the following steps:
The first part of this is planning, which I'll cover here. Throughout this series I'm going to work on an imaginary knowledge base and I'll provide any code so you can use it yourself.
The first step is to identify what types of content your knowledge base will contain. My knowledge base is going to be a resource for WordPress users and developers.
It will contain the following types of content:
This content will then be sorted according to the target audience and the high level topics. It will also make use of tags for more detailed sorting.
My audience is split into two groups:
For developers, the high-level topics are:
For users, the high level topics are:
As already mentioned, the site will also use tags which will be added by contributors. These won't be specific to users or developers.
The site will be managed by an imaginary team of WordPress experts who are all busy with other work so need to be able to add content quickly. Some of them will be using the WordPress mobile app to add content.
Having identified what my content will need to be, I need to match it to WordPress content types.
As with so many aspects of developing with WordPress, there isn't necessarily just one way to match your content to the way WordPress is organised. So to identify the most appropriate one for you, you need to start by understanding how WordPress organises content.
Out of the box, WordPress comes with three content types:
Note that there are other content types in WordPress such as links, comments, and navigation menu items, but the three above are the ones which are most relevant here.
You can also add your own content types, creating as many as you need, using custom post types. These can behave like posts or pages, the main difference being that pages are hierarchical and posts aren't. In this case, hierarchy isn't an issue for my main content types.
WordPress has two taxonomies built in, which you can use with your posts, pages, and custom post types:
In addition, you can register extra taxonomies to allow for better sorting and querying of your data.
If your knowledge base has multiple content types, you can deal with this in one of three ways:
The first option is the easiest for beginners, as you don't have to write any custom code and can work with WordPress as it comes. The second option gives you more flexibility and is an efficient approach if you want to list all of your content types together rather than always splitting them up. It's also useful if a piece of content might come under more than one content type. The third option gives you the most flexibility as long as your content types will always be separate.
In the case of my knowledge base, some of my content might be of more than one content type (for example a quick tip might take the form of a video or include a link), so I'm not going to register separate post types. Instead, I'll create a custom taxonomy for my content types.
As well as the content types, I need to think about how my data is categorized. Each post will be in one or more topics with one or more audience. As the topics are clearly matched to the two audience groups, I'm going to register two taxonomies: one for user topics and one for developer topics. This means I can list the topics for each audience on the relevant pages of the site.
This means my knowledge base will use the following:
So I'll need to register those three taxonomies but won't need to register any post types. In addition, as I won't be using built-in categories, I'm going to turn those off so that my authors don't accidentally assign items to categories.
Now that I know what content my knowledge base will include and how the data will be stored, I need to think about the structure of my knowledge base's pages. The site will use a combination of archives and static pages, with a home page including the latest posts from all topics.
I also need to think about my navigation—as well as navigation in the menu, I'm going to include topic navigation in the sidebar, and also a search box.
So, my site will include:
I'll include a sidebar and footer on all pages of my site, but I'm going to vary it slightly according to which area of the site the user is in.
Here's what will be in the sidebar:
This all sounds a bit complicated, but it will start to make sense when we start building it. I'll create each of these elements with a function and then use conditional tags to attach the functions to an action hook which I'll add to the sidebar template. I'll also add a widget area to the sidebar just in case.
The footer will include lists of the taxonomy terms for all three of my topics plus a list of the latest posts.
This means I'll need the following template files:
I'll add one action hook, which will help me to populate the sidebars: a
tutsplus_sidebar action hook in
I'll create one function attached to this hook, which will contain the following lists:
Each of these will include conditional tags so they're added to the sidebar on the right pages.
I now have a plan for the content and structure of my knowledge base and I've matched that to WordPress capabilities. So I've identified exactly what I'll need to create in WordPress to make this knowledge base work.
While it's tempting to dive in and start coding, it's a good idea to spend some time planning your knowledge base in this way so you know exactly what template files and functions you'll need. That way when you come to write the code, it will be much quicker.
In the next part of this series, I'll show you how to register post types and taxonomies for your knowledge base's data and remove any you don't need.