February Team Learning: Domains & File Structures

The Reclaim Hosting team has started approaching professional development with a little more intention and as a group. We’ve decided to make each month as its own unit, and February is the month of Domains and File Structures. Obviously there’s a lot of ways to take this topic, so Meredith broke it down for us into three separate sections. The first third of the month was for Domains (i.e. Add-on, Sub, Alias, and general management in cPanel). The second third of the month was centered around File Structures, so think types of directories, understanding .htaccess and error logging, etc. For the final third of the month, we devoted our time to file structures for specific applications to make sure we were familiar with the the standard Scalar files that are installed vs. the standard Drupal files that are installed vs. WordPress vs. Omeka, etc.

Over the course of the month, all Reclaim staff were expected to read about these concepts, write about what they’re learning, apply their knowledge in their work, and update/create support documentation on the subject.

For me, this month led to the following blog posts on these topics:
How to redirect a top-level domain without impacting subfolders; self-taught moment based off of a support ticket I received
What to consider when organizing faculty sites and coursework in cPanel; a conversation that I have with virtually every new DoOO admin during onboarding, and something I’ve been meaning to document for a while
Creating different versions of cPanel for different user groups in WHM; a video tutorial that was desperately needed in our DoOO documentation

Yesterday we met to discuss our findings over the course of the past month and also prepare for March’s topic. Not only did I find this meeting to be helpful for the above listed reasons, but also it was nice to connect for a bit of team bonding. The larger Reclaim Hosting gets, the harder it becomes for us to all be in the same (virtual) room together.

Taking a moment to learn about symlinks from Tim. (Which then led me to realize that I’ve actually worked with symlinks before on my Drupal Multisite post!

Over the month of March we’ll be focusing solely on WordPress. Which should come as no surprise, as over 30% of web is run by WordPress, and as Jim noted during the meeting, about 85-90% of our client base. The itinerary for this month is still evolving, but is meant to be more exploratory and speculative. With a little more freedom on where/how to learn this month, I hope to be blogging even more about where I’m taking it.

One of the immediate areas that comes to mind would be the main Domain of One’s Own homepage design (stateu.org) that we hand out to new DoOO schools as the starting point for end users to log in with SSO and sign up for an account. This site is built on (you guessed it) WordPress, and is currently used as a wrapper for which we have embedded cPanel. There’s no doubt that I love this model for Domain of One’s Own, but I’m constantly wanting to find ways to improve it. Just recently, I sent out a survey to all DoOO admins about this very topic and the responses I received were fascinating. I’ll use a future blog post to go into this further, but there’s plenty of work to be done here, and its already been super cool to watch Jim, Tim and Chris run with it.

Creating Different Versions of cPanel for different User Groups in WHM

cPanel Packages work great in Domain of One’s Own or Managed Hosting environments where an administrator wants to offer different versions of cPanel to the end user. (i.e. Student vs. Faculty accounts; Beginner vs. Advanced accounts; 1GB vs. 5GB accounts… you get the picture.) Watch the video tutorial below to get a sense of what’s possible, and how you would go about creating your own cPanel packages in WHM.

Introduction: 0:20
Overview: 2:23
Package Settings: 5:15
Feature List: 7:28
Installatron Apps: 9:22
Changing Packages: 14:42

A written guide on cPanel Packages can also be found here.

What to Consider When Organizing Faculty Sites and Coursework in cPanel

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!

How to redirect a top-level domain without impacting subfolders

So I got a ticket this morning (thank you Skidmore Domains!) regarding domain redirection and ending up teaching myself the fix thanks to my bff Google! Now I’m not sure if this solution is “best practice” since it involves tweaking the .htaccess file, but it worked and I’m proud of it nonetheless. :)

Support Scenario:

Can I redirect a top-level domain without impacting subdirectories of that domain?

For instance, let’s say I have a subdomain called bigpicture.labrumfield.com that I want to redirect to my main domain at labrumfield.com. Easy enough– all I would need to do is add the redirect in my cPanel account following this guide.

But let’s say that in addition to the above redirect, I also have an Omeka instance at bigpicture.labrumfield.com/omeka that I need to keep in tact. If I were to proceed with setting up a redirect in cPanel, all subdirectories, including my Omeka instance, would redirect to labrumfield.com as well.

To set up a redirect for the top-level domain only (or in this case my top level subdomain) we need to add a few conditions to the .htaccess file for the site that needs to be redirected, bigpicture.labrumfield.com.

If you’re not all too familiar with .htaccess files, you’ll need to know that this is a hidden file in your File Manager. To make sure hidden files are visible, click on Settings in the top right of your window and check Show Hidden Files:

(Psst, if you’re interested in learning more about .htaccess files in general,
I have an entire blog post dedicated to that here: Understanding .htaccess)

Next, navigate to the site directory that you’re redirecting, select .htaccess, and click edit:

In the next .htaccess window, add the following lines:

RewriteEngine On 
RewriteCond %{HTTP_HOST} ^(www.)?bigpicture.labrumfield.com
RewriteRule (.*) https://labrumfield.com [R=301,L]

Here’s a screenshot of my .htaccess file:

And if you’ve got conflicting redirect rules like:

RewriteOptions inherit

that are currently listed, those need to be commented out or removed as well.

Press save changes. The proper redirects should start happening pretty immediately! (Also worth noting that you may need to clear your browser cache to see the changes.)

Quick Actions: Converting .HEIC to .jpg

I just moved to Jacksonville, FL and this will be the new office! Excited to transform this space over time, but for now I’m just really content with enjoying the morning light.

This post is completely out of the norm of what I usually write about, but wanted to document a workflow that I use fairly regularly when uploading photos to my computer.

With the rollout of iOS 11, I’ve noticed that if I airdrop photos from my iPhone to my Mac, the photos will drop in on my desktop as .HEIC files. It’s not all the time, so I’m not sure if its a random setting on my phone that I could change, and I’ve honestly been too lazy to dig into it. But at the point that it hits my desktop as an .HEIC file, I know I won’t be able to upload it to my blog, for example, since this is the error that’s returned:

If you Google how to covert files from .HEIC to .jpg or .png, there are all these online, free ‘conversion tools’ which makes me irrationally annoyed. I want to convert these myself, dammit! So I figured out how to set up a Quick Action on my Mac that will do the converting without having to pop my photos into any sort of online conversion thing.

1.Search for the Automator on your computer. Open it up and click New Document.

2. Select Quick Action, then select Choose.

3. Search Copy in the top left search bar, then select and drag Copy Finder Items to the empty space on the right:

4. You’ll now have the option to choose where you want converted images to be saved. I’m usually working right on my desktop and like to file them later, so for now I’ll leave mine as the Desktop folder. I’m also going to check the box called Replacing Existing Files because I don’t want to create a copy of the .HEIC file, I just want to replace it with the .jpg file.

5. Next, we’re going to search for another action on the left-hand search bar. Search Change Type, then select and drag Change Type of Images over to the right blank space (beneath Copy Finder Items):

6. In the Change Type of Images box that appears, click the dropdown menu and select JPEG.

7. Finally, we want to name our Quick Action and save it as a workflow. From the Automator window, click FileSave, and name your action to something like Convert to JPG. Then click Save.

Boom! Now let’s test it out. Right click on your .HEIC image, hover your mouse over Quick Actions, and then select your newly created Action:

Voilà!

Activating Installatron Apps on a per User/Group Basis

I’ve seen a little confusion surrounding the ability to enable/disable applications on a per user/group basis within a Domain of One’s Own environment, so I thought I’d follow up with a little tutorial:

We should already know that it’s possible to set different user groups for cPanel accounts via Hosting Packages, and then customize the cPanel features that are accessible to each user group (i.e. Hosting Package) via Feature Manager. But is it also possible to customize which installatron applications are available to each user group?

In short, this is 100% possible. Follow the steps below to read more about this:

Pretend Scenario

Domain of One’s Own administrators have determined two user groups within their hosting environment: Beginner and Advanced users. All users will receive the ‘Beginner’ or ‘default’ cPanel package upon sign up, and then administrators can switch to the Advanced hosting package for one-off users as needed. Now, our administrators want to make sure that our Advanced cPanel accounts have access to more installatron apps while the Beginner cPanel Accounts only have access to, say, WordPress, Omeka, and Scalar.

How To Create Groups of Users in Installatron

Installatron > Groups > Create a New Group:

If you’ve got existing hosting packages already set up, I recommend naming these Installatron groups with corresponding titles. From there, you can assign individual cPanel usernames or entire cPanel packages to that Installatron group:

Click Save.

Now navigate to Installatron > Access Control and select the newly created group in the top right hand corner:

Proceed to enable/disable applications like normal. (Steps on this can be found here.) Click save.

Now, any cPanel username or cPanel package that was added to the Installatron group list will see those changes immediately:

Simple as that!

Community Highlight – coventry.domains

I can’t believe that my last blog post was roughly a month ago! There’s so much that I need to share in this little space and the work at Reclaim is far from slowing down any time soon. But what better way to jump back into blogging than to start a new series of posts showcasing work done in the Reclaim Community? This sort of thing is long overdue, frankly, but there’s no time like the present. On a semi-regular basis, I want to start featuring more work from the DoOO community on my website under the community category because 1) cool sh*t deserves recognition and 2) being able to point to this space for schools that are considering similar projects would be awesome. So, without further ado, everyone check out the new website for coventry.domains!

The coventry.domains team, Daniel Villar-Onrubia, Lauren Heywood, and Noah Mitchell, did a wonderful job in making the homepage both inviting and informative. They tailored sections for both students and educators, followed by easy step-by-step instructions for getting set up in a web hosting environment. Web Hosting can quickly feel intimidating, so ‘getting started’ steps are immediately followed by links to the coventry.domains knowledge base.

Sitting at coventry.domains/learn, the knowledge base is arguably my favorite part of the project. The icons feel like literal stepping stones to navigate the waters of a new web space. More than just documentation with screenshots, this page thoughtfully answers questions like: Why is this important? How do I design a space that’s accessible for everyone? How should I be sourcing images I find on the web? How do I create a privacy policy? How should I structure and organize my various projects? This knowledge base takes on more than just the ‘what-to-do’s’– it tackles the ‘why’s’ and ‘how-should-I’s’, which is equally just as important in a space of newfound digital literacy.

I often get questions from prospective DoOO institutions about how other schools handle Terms of Service and Code of Conducts in this digital space. Having examples is a critical part of that answer, and I really love Coventry’s take on this. They’ve linked to their Terms & Conditions and Code of Conduct right on the footer of their home page, as most institutions end up doing, but Coventry has taken it a step further. They’ve added a Sign Up Notice, written in plain English, in an effort to be completely transparent about how user data is being processed and how it can later be removed. Users have to agree to this before even authenticating with Single Sign On to begin signing up.

If you’re interested in chatting further with Coventry’s Domain of One’s Own team, they can be reached at dooo@coventry.ac.uk. And as always, feel free to check out other DoOO projects at reclaimhosting.com/institutions.

Email Notification Template for Zendesk Support Tickets

Last week I had a bit of free time and started looking for a way to add the Reclaim Hosting brand to the support ticket notifications that are sent out to users when they put in a request. If you have no idea what I’m talking about, here’s what the support notification used to look like when a user put in a ticket to support@reclaimhosting.com:

Before:

In short, my goals were to:

  • Make sure the Reclaim Hosting logo was visible
  • Remove the ‘Powered by Zendesk’ branding at the bottom
  • Add in extra Reclaim Hosting documentation resources
  • Keep the integrity of the ticket content

After doing a bit of reading in the Zendesk Community forums I went down a rabbit hole and found a .html file that was basically a skeleton of the template design I was looking for. I added in the Reclaim logo, business hours and documentation helpful links, then changed the spacing, font size and link color. The final template now looks something like this:

Once including the ticket content from the ‘Before’ screenshot, here’s the final product:

After:

The template also embeds responses back to the user so Reclaim branding & helpful links stick around as the conversation continues:

Overall, this was a fun & quick little project that adds to the full Reclaim Hosting customer experience and I’m proud of how it turned out!

If you’re interested in taking a look at the code I used, click this downloadable link to get access to the file.

Removing Email Section from cPanel

It is a common request for institutions to want to remove the Email section from cPanel for end users of Domain of One’s Own or even Managed Hosting setups. To remove Email globally across all accounts, you’ll need to log into WHM and navigate to Feature Manager:

Click on the main cPanel package that end users receive. In the above case, the package is called default. If there are multiple packages listed and you’re unsure of which one is the main cPanel package that is given to users automatically when they sign up, navigate to List Accountsand look for the Packagecolumn. Hopefully that should clue you in!

Ok, back to Feature Manager. Select the cPanel package from the Feature list where changes need to be made and then click Edit. In the next window, search Emailand uncheck every item that comes up:

The list of items is shared in the screenshot above, I’ll also list them out below:

  • Email Accounts
  • Email Deliverability (Authentication)
  • Email Disk Usage
  • Email Filtering Manager
  • JetBackup :: Email Backups
  • Email Archiving
  • Email Delivery Route (deprecated)
  • Email Domain Forwarding
  • Email Trace

Cool, we’re halfway there! There’s actually a few more items we’ll need to uncheck that don’t have ‘Email’ in the name. I still find the search bar to be helpful for this. Search for and uncheck these additional items:

  • Forwarder Manager
  • Autoresponders
  • Webmail
  • Mailing Lists
  • Address Importer
  • Default Address
  • PGP/GPG
  • Calendars and Contacts
  • BoxTrapper
  • Apache SpamAssassin™
  • MX Entry

Once you’ve unchecked all of the above, scroll down and click Save:

Now when you navigate to a cPanel account on the server (using the package that you edited) you will no longer see the Email Section:

Updated Refund Policy for Reclaim Hosting

Hey there, all three of you who found your way to this post to read about Reclaim Hosting’s fine print! We’ve updated to our Refund Policy because we now have more products and support scenarios than when Reclaim Hosting began 6 years ago, and we felt that it was time to refine how we handle things.

In short, our 24-hour “No Regrets” Policy and 14-Day Refund Policy have not changed. So if that’s all you care about, you can stop reading here. :) That said, we’ve expanded upon certain scenarios in which there has been confusion about whether or not a refund is applicable.

The main additions / clarifications to the Refund Policy are listed below:

  • Refunds are not issued for purchased products or services that are unused.
  • Service-based costs (Migrations, Professional Services) are only refunded when the request is made within 14 days, and only if the service has not been executed.
  • Upgrading plans and services are prorated based on your billing cycle, however downgrading a plan/service is not eligible for a refund for unused time.
  • Contracts for Managed Hosting and Domain of One’s Own are annual contracts that are not eligible for any refund.
  • Renewals of all products and services are non-refundable.
  • One refund or account change, per customer, per calendar year.
  • All other sales are final. 

To read Reclaim Hosting’s Refund Policy in full, click here: reclaimhosting.com/refund-policy