Reclaiming Archiving

I’m headed to Stanford University’s campus tomorrow morning to begin a two-day chat with a variety of authors, digital preservationists, and technologists to strategize and formulate tangible gameplans for preserving and archiving digital projects. Everyone in attendance will be bringing a different perspective to the table, and I’m very much looking forward to the conversations that will flourish. I thought I might take a quick moment to blog a summary of my perspective, as I’ll be sharing it briefly tomorrow afternoon.

Reclaim Hosting was founded in 2013 as a way to provide affordable web hosting space for individuals and educational institutions alike. We’re set apart from the Wix’s and Squarespace’s because we encourage digital literacy and growth both in and outside of the classroom. Our support tickets go deeper than resetting passwords; we teach, advise, and converse with our customers about the tools available to them. In addition to fixing the problem at hand, we use these support tickets as a learning experience for the inquirer and provide the steps we took towards the solution so they might be able to do fix it themselves it in the future. For the last five years, supporting customers has been the very top priority for Reclaim Hosting. We keep out reply times lightning fast, our satisfactory ratings high, and regularly put answering support tickets before all other projects.

It’s important I share Reclaim Hosting’s priorities from the very beginning in order to show how they have adapted, changed, and grown, even in the last three years since I joined Reclaim Hosting in 2015. While we still place the utmost importance on our support, our growing team and comfortability with the infrastructure have allowed us to shift focus towards the future, but also towards preserving the past. Will we use cPanel forever? What will be the next ‘WordPress’? These are just a few of the many questions that have been floating through my mind, at least, especially over the last year or so. What’s more, Jim and Tim recently gave a talk at OER18 about Cloudron as a potential path for our future beyond the LAMP environment.

Technologies and softwares are always updating and advancing, and Reclaim Hosting obviously wants to provide the most relevant, up-to-date tools for users. But how do we do that while also hosting and preserving work that has been created on tools that are maybe no longer supporting themselves? Here’s another scenario: Reclaim now has institutions that have been with us for a couple of years and are racking up quite a bit of content from their community. How do they preserve the work of students and faculty members that are no longer institution?  These are the golden questions, I suppose, and likely ones that will be thrown around quite a bit in some form or another over the next few days.

While the answers are hardly black and white, we’ve already begun to address some of this in the form of migration strategies and site archive utilities. At the root, however, we believe that in order to make digital projects sustainable, we must make them portable and transferable so they are not restricted to the platform where they were created.

As an example, Tim began creating a Site Archive Utility plugin in cPanel that would allow the user to input their site URL, click import, and archive their site as static HTML on the server (essentially doing the work of something like SiteSucker.) The idea here is that you could do things like schedule archives, store them on a third-party service like Amazon S3, save them locally in a specific folder of your choosing.

But in the spirit of strategizing with others at the workshop, I think it would be incredibly fascinating to have the ^above feature on our Migration Assistance page for Domain of One’s Own schools, for instance. A student would be able to import their site as static HTML, but instead of saving locally or on S3, the files went to an actual archiving service. And, hypothetically, that archiving service would have a small corner of the internet dedicated specifically to specific institutions. Those schools would then be able to use that as a resource for work that they’re interested in keeping long-term in addition to the tools provided at Reclaim Hosting. But that’s just an idea. :)


Cleaning up Domains 17 with Sitesucker

It’s hardly news at this point, but Reclaim Hosting isn’t doing a Domains conference this year. We loved Domains 17 (and are currently mulling over a Domains 19) but we deemed 2018 as a gap year a couple months back. This has meant that the conference website,, was just sort of sitting there with content that is now close to a year old. I was also growing rather tired of logging in every now and then and making sure all plugins, themes, and softwares were up to date. What’s even more, the Domains17 site was sitting on, meaning if we were having a Domains19, things would obviously need to be shuffled around.

On an unrelated (or is it?) note, I’m headed to California in a couple of weeks to take part in Stanford University’s Preservation Workshop to chat about archiving digital projects and possible strategic partnerships with preservationists and technologists. So to say the least, I’ve had archiving on the brain over the last week or so. As part of my preparation for the workshop, I’ve been wanting to play around with and explore some of the digital archiving tools that are already out there. Though I’ve recommended SiteSucker to many Reclaim users in the past, I’ve never given myself the chance to play it. So between this workshop and the Domains17 site, I thought there would be no better time than the present to get going:

I started first by making the subdomain,, and then added it as an AddOn domain to the cPanel account where the current conference site resided.

^I then cloned the original conference website from to using this method.

After confirming that the site was completely up to date and loading securely on the new domain, I opened up the SiteSucker MacOS app that I had previously downloaded. (It’s $4.99 in the App Store, fyi. Kind of a bummer, but I imagine if you do some serious archiving you’d make your money back rather quickly with the amount of time you save. It’s lightning fast.)

^Screenshot of what the SiteSucker window looked like while it was working.

I simply entered the URL and pressed enter. Within two minutes it was done! I pressed the folder icon (top bar, middle) and could immediately see all the WordPress site files that had been translated to Static HTML. Once having the files on my local hard drive, I closed out of SiteSucker and opened up my FTP client. (My personal favorite is Cyberduck.)

I navigated to the directory, removed the existing cloned WordPress files, and uploaded my new static HTML files.

I refreshed my browser and boom! The site now loads beautifully (and quickly!) over HTML only. I had an issue with one of my visual builder buttons still linking back to the old domain, but that was an easy fix. I used Chrome’s inspect feature to figure out where the link was located in the code and then used the command+find tool to fix it in my File Manager.

As my final step of maintenance cleaning, I created a redirect so that all visits to be redirected to for time being. This way I can begin to alter the content that currently sits at, while simultaneously familiarizing visitors with the new domain.

From start to finish, this took less than ten minutes complete.  Not a bad for a little afternoon project. I’m excited to continue playing around with Sitesucker, but very impressed so far.