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.
WordPress is a CMS.
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.
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.
The default Post Type in WordPress is called ‘Posts’. As WordPress began as a blogging platform, we predominantly use this for news.
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’!
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.
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’).
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
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:
|Administrator||Can create, edit and delete any piece of content.|
Can add users, assign user roles, delete users.
|Course Editor||Can create, edit and delete course content only.|
|Event Participant||Can add comments to event posts only.|
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.