ACT I: Domains and Hosting
In Site Setup Journal: Prologue, I set the scene for an ordinary website setup project. The plan: re-up a hosting account gone dormant, make sure the registrar is a domain pointing there, install WordPress, add a few miscellaneous plugins, install BuddyPress, do some configuration and maybe a little theme tweaking, and then have a nice private group site for the students of a class I’m in. Simple, right? I figured maybe an hour or two. Boy, was I wrong.
Once I removed the option to ping knowledgeable friends and get a fast, accurate answer to any question (a privilege I appreciate even more after this experience) and had to rely on public documentation and support services, I re-discovered just how woeful they are. I’ll try to describe each of the steps I took.
Step 1. Getting a Domain
An average person creating a new site would need to buy a domain, but I knew I had an unused domain sitting around from when I used to freelance, so figured I’d save the money and the addition of another domain (because the class site might get moved to the school site eventually). I had hosting accounts on both Bluehost and Dreamhost, but wasn’t sure where I had hosted the domain I had in mind.
First I logged in at Bluehost. The hosting account had been deleted in July, which I hadn’t realized because the email address was one I no longer check, tied to an old business. The domain listed wasn’t the one I was looking for, though, so I went over to Dreamhost. I had to do some login gymnastics there also, because I’d had two accounts there, and as it requires login to be an email address/customer ID rather than a self-chosen username, I had to try a LOT of times to get the right combination of email and password and domains (I’d had accounts under 2 email addresses because one was for helping non-profits get sites set up). Finally after resetting passwords on the emails still in use, I got in. The non-profit account was still active, but I wanted the paid account for this project. In retrospect that was unnecessary, since the school is a non-profit, but oh well. The paid account had also expired over the busy summer. This one I did vaguely remember seeing emails about, but had never taken the time to go and do the login hoop-jumping to pay for the coming year because I was busy with work. I paid to re-up the hosting account, and it was back in business.
The domain was still listed there, so I wanted to make sure the registrar was still pointing at the Dreamhost nameservers. I went to Namecheap first, but it wasn’t listed there, so I had to check GoDaddy. I have a couple of domains there still that I hadn’t transferred yet due to timing around expirations. I couldn’t log in because I didn’t remember my password (hey, lots of people don’t use password managers). I went through the reset process, and got access. A domain I’d been registering for my brother had apparently expired (oops, another victim of my changed-email status), but the domain I wanted to use for the class was still there, and it was still pointing at Dreamhost.
I wasn’t keeping track of time, but I’d guess this all took about 30-45 minutes of going back and forth between sites and emails (often not instant but instead a few minutes later, or later, or later.
Summary: Requiring email address and/or customer number as login instead of allowing user-selected username does not result in a good user experience. Only doing password resets via sending to the email on the account does not address the reason why a lot of people need help resetting a password, which is lost access to the email address on the account. User-selected security access phrases or questions are a more user-friendly path to password reclamation.
Stay tuned for Act II, Setting Up WordPress. This is when we get into the fun stuff.