This post is part of a series I will be cranking out over the next 5 days or so as Reclaim Hosting prepares to run its first “Workshop of One’s Own.” What is that you ask? Well, next week Reclaim is hosting an event at its offices wherein system administrators and support folk at various schools running Domains will come together for two days in order to get in-depth, hands-on experience of how to manage and support Domain of One’s Own.
When we provide an introduction for new schools one of the things I’ve started doing is to provide a conceptual overview of how the various pieces of a Domain of One’s Own work together. There are three application that work together to make Domain of One’s Own setup work, and below I’ll try and detail each hopes of better explaining how they work together.
The venerable WordPress is in many ways the face of a Domain of One’s Own installation. We describe WordPress as a wrapper in which we embed cPanel. In fact, that is literally what is happening, we are using various functions and API calls in WordPress to both create and embed cPanel within the Dashboard page of WordPress.
Why WordPress? Two reasons: 1) often times folks are familiar with it so it makes it easy for administrators of Domain of One’s Own to get up and running given they often have used it before. 2) Given the robust open source development community around WordPress, it provides us all kinds of pre-written code to integrate features such as single sign-on, ghosting as another user, and more. Fact is, rather than trying to integrate with a campus instance of Shibboleth directly, we can use plugins for Shibboleth others have written and vetted to do this far more seamlessly.
In this regard, WordPress is the place users will login with their school credentials, which will be checked against the single sign-on system, and then they are passed into the Dashboard that is embedding pages from both WHMCS and cPanel. And this might be a good moment to jump to the next application we use….
If WordPress is the face of the project, and the wrapper for cPanel, then WHMCS is the almost invisible gateway between WordPress and the cPanel server (known as WHM). As a user you only see WHMCS for a brief time while you are signing up for your web hosting account.
The three screens above are the only time a user will be “within” WHMCS. While you are still technically in WordPress, these order forms are being pulled from WHMCS, which is a client management software that sits on top of WHM and creates new accounts and sets up invoices, renewals, etc. In many ways it is simply a bridge to WHM that creates and manages the business end of accounts.
Finally, we have WHM (which stands for WebHost Manager) and this is the cPanel software that you use for creating a shared web hosting server. CPanel is the web hosting industry standard, which provides a lot of continuity for folks who want to take their work elsewhere. Where WHM fits in is it is actually the software wherein you manage the shared hosting accounts. WHM is where WHMCS creates those cPanel accounts that are associated with the various users at a school. It is where you can change storage quotas, checked the firewall for blocked IP addresses, manage Installatron settings, manage the email queue, and much more.
We will get into the various tasks you can perform through WHM, but for now it is important to understand that WHM is the software that manages the shared hosting accounts, and we are pulling those individual accounts back into the WordPress site’s Dashboard page using various functions and API calls to WHM to get this:
And that is the way in which the three major systems we use at Reclaim Hosting to build Domain of One’s Own operates. There are many other details and specifics that we will elaborate on throughout the workshop, but this session is meant to serve as a more general technical overview to explain the various pieces before we dive into each of them in depth.