I get asked all the time how to best organize work, specifically for Faculty course sites, within cPanel.
Should Faculty put everything in one cPanel, or multiple, separate cPanels? Should they use single application installs or a multisite? Should they use subdomains or subfolders?
My small preface here is that there’s no one “right” way to do all of the above. At the end of the day it really comes down to user preference and what you as the administrator are approving and supporting. This post also doesn’t claim to list all options, but simply the ones that have worked well in my experience:
One cPanel vs. Multiple cPanels
^screenshot pulled from my Multiple cPanels Guide
First and foremost, Domain of One’s Own is priced on a per cPanel basis. In an entry-level package, an institution is given up to 500 cPanels on their server. Those cPanels can be owned by 500 users or by 50 users, and will ultimately be determined by DoOO admins as to whether or not they want end users to have the option of owning more than one cPanel account.
Nine times out of 10 I’ll say that the majority of work can be done within a single cPanel account (with perhaps a bump in storage quota & site resources as needed). cPanel allows for an unlimited number of sites/domains/applications to be added to a single dashboard, which means that a Faculty member could be managing multiple projects, course sites, etc. within their one account.
One exception to the above might be if a Faculty member is the liaison for an institutional club, organization, or event that changes ownership quite frequently. For example: it would be a real pain for the Professor X to leave the university, take their personal portfolio with them, and accidentally remove the website for the school newspaper. In these instances where it is crucial for coursework and personal work to remain completely separate a club or event, a separate cPanel account does make sense.
Single Application Installs or a Multisite?
Again, this really comes down to user preference and the project in mind. There are some obvious benefits to a WordPress Multisite over single WordPress installs– the main one being that management happens within a single application dashboard. If you want to install new themes, update software, configure site settings, etc. you’d really only be doing it once with the knowledge that your work is applied to multiple locations.
Multisites are also great for maintaining previous course sites. For example: Professor X might want to install a WordPress Multisite for their Photography 101 class on professorX.stateu.org/photo101, and then have subsites for each semester:
professorX.stateu.org/photo101/spring19
professorX.stateu.org/photo101/fall19
professorX.stateu.org/photo101/spring20
professorX.stateu.org/photo101/fall20
In the above example, Professor X might not be concerned with having separate site designs for each semester, but still wants to keep an archive of previous student work.
Even still, I tend to find myself working with applications as single installs as I need them since I don’t usually have the foresight to think through future projects and set up a multisite in advance. (Now it is possible to convert a single WordPress install to a WordPress Multisite after the fact, but the process is not simple.) I also personally like having separate dashboards for each project because I like keeping projects completely separate, even if it means a little more management on my end. Not entirely rational but there you have it.
There’s plenty of reading out there on the pros & cons of each, so I definitely recommend doing your homework when trying to nail down what will work for you.
Extra Reading:
• WordPress Multisite vs a Single Site vs Multiple Websites [Infographic]
• WordPress Multisite vs. A Management Tool: Which Do You Need?
• Managing Multiple Sites: WordPress Multisite vs Separate Installations
Subdomains vs. Subfolders
Subfolder examples:
• professorX.stateu.org/portfolio
• professorX.stateu.org/blog
Subdomain examples:
• portfolio.professorX.stateu.org
• blog.professorX.stateu.org
With this one I won’t try to recreate what was already brilliantly said by Tim in this guide, but I will reiterate the following:
Subdomains are generally a cleaner, more elegant solution to organizing your site. You’re less likely to get conflicts or errors. However, when using subdomains there is an extra step involved: you must first create the subdomains before you can install anything on them.
Conflict Example for Subfolders:
Professor X installs a WordPress instance on professorX.stateu.org, and then creates a page that sits at /blog. Fine. But then Professor X could technically go and install another WordPress instance on the subfolder called professorX.stateu.org/blog. Yikes. Now Professor X has two separate application installs and both are using /blog. #conflict. If that second WordPress instance was installed on the subdomain blog.professorX.stateu.org, all issues would have been avoided.
Hoping this overview helps clarify some of the options out there for site organization, but I’d be interested to hear in the comments if there’s something working for you that I didn’t mention above!
