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:

1. Planning your knowledge base, in particular planning how your content will fit with WordPress's content types. Identifying what the structure of the site will need to be and what custom template files you'll need to create, if any.
2. Structuring your knowledge base. Creating the relevant template files and writing any custom queries.
3. Creating your knowledge base's front-end. Creating the template files, styling them, and adding additional navigation, search and help.
4. Making your knowledge base live. Looking at the constraints you might face here, how you'll allow access to the site, and how it will be maintained and managed.

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.

Identifying Your Knowledge Base's Content

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:

• FAQs
• Quick Tips
• Tutorials
• Snippets
• Links
• Videos

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:

• users
• developers

For developers, the high-level topics are:

• Theme Development
• Plugin Development
• Functions
• Action and Filter Hooks
• Queries and the Database

For users, the high level topics are:

• The Dashboard
• Adding and Editing Content
• The Media Library
• Installing, Customizing and Activating Themes
• Installing, Customizing and Activating Plugins
• Settings
• Site Management

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.

Matching Your Requirements to WordPress

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.

WordPress Content Types

Out of the box, WordPress comes with three content types:

• posts
• pages
• attachments

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 Taxonomies

WordPress has two taxonomies built in, which you can use with your posts, pages, and custom post types:

• category 
• tag

In addition, you can register extra taxonomies to allow for better sorting and querying of your data.

Identifying What You Need

If your knowledge base has multiple content types, you can deal with this in one of three ways:

• Use one content type (such as posts) and use categories to identify what content type each is.
• Use one content type (such as posts) and use a custom taxonomy to identify the content type.
• Register a post type for each of your content types.

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:

• posts
• pages
• tags
• three custom taxonomies: user topic, developer topic, and content type

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.

Planning Your Knowledge Base's Structure

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.

Page Structure

So, my site will include:

• a home page with the latest posts from all topics
• a static page for each of the two user groups and for content types
• an archive page for each content type
• an archive page for each taxonomy term
• single pages for each post

Sidebar and Footer

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:

• On all pages there will be a search box at the top.
• On the home page, search page, and 404 pages there will be links to each of the user and developer pages, with a list of relevant taxonomy terms under each with links, and a list of content types with links to their archive pages.
• On the users page and archive pages for the user topic taxonomy there will be links to the user topic taxonomy terms archives.
• On the developers page and archive pages for the developer topic taxonomy, there will be links to the developer topic taxonomy terms archives.
• On the content type page and archive pages for the content type taxonomy, there will be a list of content types with links to their archive pages.
• On a single page we will have links to the archives for the user topic and developer taxonomies.

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.

Template Files

This means I'll need the following template files:

• index.php
• page.php
• archive.php
  
• single.php
• sidebar.php

Hooks and Functions

I'll add one action hook, which will help me to populate the sidebars: a tutsplus_sidebar action hook in sidebar.php.

I'll create one function attached to this hook, which will contain the following lists:

• links to the archive pages for the user topic taxonomy terms
• links to the archive pages for the developer topic taxonomy terms
• links to the archives for the content type taxonomy terms.

Each of these will include conditional tags so they're added to the sidebar on the right pages.

Summary

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.