WordPress Glossary

At SMILE, we sometimes find ourselves excitedly sharing ideas in a language which is unique to people who build websites. However, we realise that this can sound alien to those who don’t spend all day doing the same! Here, we’ve tried to break down some of the terms we use regularly to hopefully make them more comprehensible to normal human folk.


CMS stands for Content Management System.
WordPress is a CMS.
A shorthand for your ‘main’ or ‘lead’ website.
This is the public-facing view of your website.
This is the administrative view of your CMS.

WordPress Architecture

WordPress Core
This is what we refer to as the self-installable WordPress CMS, unmodified.
Instances & Networks
Most websites utilise a single ‘instance’ of WordPress, where all of the pages, posts and settings for that website are contained and managed.

However, more complex websites will sometimes use multiple ‘instances’ of WordPress, which collectively form a ‘Network’ of WordPress instances.

To a website user, a single instance of WordPress and a network of WordPress sites will both appear as a single website – having a network simply allows large sites to be better organised behind-the-scenes.

For example, a university website will appear to be one single website with multiple sections. However, the ‘courses’, ‘jobs’ and ‘knowledgebase’ sections of the website could each be individual instances of WordPress, which together form a network. In this case, your single website is actually a network of WordPress instances behind-the-scenes.

Instances of WordPress within a larger network can share resources including themes, plugins, styles and even users, but may have individual features and functionality that can be managed independently. This makes each subsection of the site much easier to use and increases the overall website’s performance significantly.
Information Architecture
This refers to the organisational structure that contains your content. This can be at a Network or Instance level. It’s essentially how the website is structured in the backend. Importantly, this is different from your Menu Architecture.
Menu Architecture
A Menu Architecture defines the available Menus and what items and subitems are available within your Instance or Network. This is the frontend setup, which people use to navigate around the website.
This term is often used as a prefix to another term to suggest that it applies throughout an Instance/Network.
WordPress uses Plugins to add extra chunks of functionality to its core install. We try not to use too many of them (they can slow things down!) but we have found some to be indispensable. Plugins can handle a variety of things from SEO optimisation to Search and form building.
You can activate Plugins on a per Instance basis or at Network level. Activating plugins at Network level means that every instance within the Network will have the functionality activated.


A page is a single static entry to a website. It has no timestamp and so is not contingent on anything outside itself. It is for content which is not intended to move anywhere. Content typically appearing as pages includes the Homepage, About Us page and campaign landing pages.
Technically, everything in WordPress is a Post. Post is the default term for a content item.

The default Post Type in WordPress is called ‘Posts’. As WordPress began as a blogging platform, we predominantly use this for news.
While WordPress core ships with only the default ‘Posts’ post-type detailed above, we can create as many custom post-types as we need in order to organise the various content which needs to live on a website.

Users will generally see different menu items for post types in the administrative backend. More advanced uses include setting user permissions to access specific post types.

Common custom post-types include Staff Profiles, Events and even Courses. This means that a staff profile, an event and a course are actually single ‘posts’!
Largely an organisational device, Taxonomies allow you to identify groups of related content within a Post Type. ‘Categories’ and ‘tags’ are examples of taxonomies.



WordPress uses Themes to dictate how a website is styled. Most of our development work is involved in creating your websites’ custom theme. The theme is ‘applied’ to your site in its backend and is what makes it look different to any other website.

Parent Theme

Behind the scenes, a website may consist of several sub-sites (or ‘instances’). The reason they appear to frontend users as a consistent whole is theme hierarchy.

A parent theme contains the most consistent and pervasive styling and components for the website as a whole. They usually contain important overarching elements such as the site’s main typeface, brand colours, and menu styling, all of which are passed down to its children (‘child themes’).

Child Theme

In the hierarchy of themes, a child theme is closely related to its parent theme. It inherits all the components and aesthetics of its parent theme but has bespoke features on top of this which are unique to itself.

A good example of a child theme would be a news blog attached to a main website. The blog (child) may automatically inherit the typeface and brand colours from the main site (parent) but have its own header styles and layout structure. Parent/child themes help a site maintain its cohesiveness while allowing some of its subsections to maintain a sense of individual identity.

Users and Credentials

User Roles

In order for someone to operate on a WordPress site, they need to be added as a user on that site.

When added to a site, users are assigned a User Role. Each User Role has its own permissions and capabilities based on the scope of their activity on the site. A user can be reassigned to a different User Role at any time

For example, let’s say a typical site has three User Roles, ‘Administrators’, ‘ Course Editors’ and ‘Event Participants’. Their scope might be defined as below:

User RoleCapabilities
AdministratorCan create, edit and delete any piece of content.
Can add users, assign user roles, delete users.
Course EditorCan create, edit and delete course content only.
Event ParticipantCan add comments to event posts only.

Single Sign-On

Interchangeably referenced as ‘SAML’, Single Sign-On refers to the protocol whereby a user logs in with a single username and password in order to gain access to several related systems during one session.

Because we use Networks, basic Single Sign On is achieved within a WordPress Network as default.

However, Single Sign-On can also reference further extensions to this. SAML is a protocol whereby you can log into WordPress with credentials from your organisation. Typically this comes from Microsoft Active Directory. This means that when a new user is added at your organisation, they are instantly available on WordPress. Likewise, when they are removed from your organisation, they can no longer access and WordPress dashboards.

Updated on August 7, 2020

Was this article helpful?

Related Articles

Not the solution you were looking for?
Can’t find the answer you’re looking for? Don’t worry we’re here to help!
Contact Support